▼
Posts: 16
Threads: 4
Joined: Nov 2009
I wonder how the 35s handles roundoff errors due to number truncation. I tried the following keystrokes on an hp15c(*) emulator (by Torsten Manz) to calculate ( 1/3 * 3  1 ) ^ (1/3)^3 :
3 1/x 3 x 1  3 1/x 3 y^x y^x
and it gave 0.3570 instead of 0.
Could someone please try this sequence on a 35s and report the result? I'm curious to know what results are produced by other hp models and which models avoided this "error".
(*) My hp15c was stolen 22 years ago. An hp35s is on its way to me now and would be my second hp calculator ever! I've been lost in a Casioinfested wilderness for those past 2 decades!
▼
Posts: 25
Threads: 9
Joined: Aug 2007
Hi Mohammed:
Your sequence of operations, 3 1/x 3 x 1  3 1/x 3 y^x y^x,
will produce an "INVALID y^x" error in a 35s, but will give
a valid (complex) result on a 42S, 50G etc. which have more consistent complex numbers support than the HP35S.
My real 15C, in complex mode, gives 0.4233339636 + 0.04948064389i.
If we change the test to avoid complex numbers to (1  1/3 * 3 ) ^ ((1/3)^3) :
1 3 1/x 3 *  3 1/x 3 y^x y^x
For this, the 35S gives 0.359381366382 which is the best possible
result when each step is computed to 12 digits of precision;
the same result can be obtained with a 42S, 50G, etc.
The 15C yields 0.4262158830 which again is the best result to 10 digits.
Note these calculators do not have hidden digits
and each operation uses the previous 12/10digit result.
e.g. after the second operation the number is 0.999999999999, not 1/3 so we should not expect a final result of 0. (but you could get it with a 50G in exact mode)
The 35S has the good arithmetic of the RPL 12 digits models, some functions, e.g. trinogometric, have worse precision.
Maybe you intended to compute ((1  1/3 * 3 ) ^ (1/3))^3
1 3 1/x 3 *  3 1/x y^x 3 y^x
Which is 1.00000000003E12 on the 35S and other 12digit models and 1.000000002E10 on the 15C.
Posts: 850
Threads: 10
Joined: Mar 2009
Hi Mohammed,
I just tried this on my 35s and got an "Invalid y^x" for the last y^x as the numbers are (1e12)^(3.70370370369e2).
However, doing a complex y^x, I get 3.56951358148e1 i 4.17216301054e2
Bart
edit: to do a complex y^x on the 35s, add 0i0 to both no.'s
Edited: 30 Nov 2009, 4:24 a.m.
▼
Posts: 16
Threads: 4
Joined: Nov 2009
Thank you all for your quick responses. By the way, Bart, it was my unsubstantiated guess that 0i0 addition or simply starting with 3i0 1/x ... will do to avoid the eventual INVALID y^x response. You seem to suggest that explicit complex"ing" is needed throughout the sequence.
In any case, my whole point was how to protect an unsuspecting student who's not wellversed in limited precision pitfalls from blindly accepting totally erroneous results when using hp calculators. In contrast, my Casio fx991ES will give a correct zero result for the original expression above.
Maybe I should prepare a onehour lecture about the dark side of calculators for my Introduction to Engineering course.
▼
Posts: 850
Threads: 10
Joined: Mar 2009
And therein lies the fallacy of calculators like the fx991es in that they artificially correct for rounding errors. What else is it "correcting" for that we don't know about? I think there are many of us here (older generation I guess) that are aware of the fact that calculators and computers cannot completely represent some numbers, and prefer calculators not to lie about rounding errors.
There have been threads about the fact that students seem to blindly accept calculator results nowadays. Some even referencing the use of slide rules where one has to figure out the order of the result oneself.
I think it is a good idea that all users of calculators (and computers used for calculating) have such a lecture that you're suggesting.
▼
Posts: 16
Threads: 4
Joined: Nov 2009
Wouldn't it be nice if along with the final result, a calculator would actually tell you (say, via a horizontal bar chart at the display bottom) to how many digits the result is accurate? "Hmmm... 3.176334798 but only 1 significant digit preserved... maybe I should rearrange my expression."
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
And therein lies the fallacy of calculators like the fx991es in that they artificially correct for rounding errors. What else is it "correcting" for that we don't know about?
How would CASIO fx991 ES evaluate ln ln(1618 + 10^{7}. e^{e}8/3)? I hope it doesn't try to correct the "rounding error". The HP15C gives the correct 10digit answer: 1.999999998.
Some interesting threads on calculator accuracy started by Rodger Rosenbaum:
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=85973#85973
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv016.cgi?read=103151
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv016.cgi?read=103356
▼
Posts: 16
Threads: 4
Joined: Nov 2009
Thank you Gerson for the links. I'll have a look at them later. My fx991ES by the way got the same 10digit answer.
I really dislike the 991ES now. After going through the 35s manual, I realized that calculating the equivalent of two parallel complex impedances will take twice the keystrokes on the Casio compared to the 35s (20 keystrokes vs. 10!).
▼
Posts: 758
Threads: 9
Joined: Jul 2007
I don't understand completely the process by which the Casio fx991ES (a.k.a. fx115ES) usually displays such impressive numerical accuracy, but in the example problem cited by Gerson, the actual 14digit result produced by the Casio, displayed only to 10 significant digits, (1.999999998), can readily be determined (by subtracting 1.99999) to be 1.9999999975828.
The HP Saturn series and later all yield (at 12 digits) 1.99999999758.
Whatever tricks the Casio folks are using, they seem pretty impressive for a US$17.48 calculator that also has rudimentary numerical integration, differentiation, and SOLVE functions and a pretty decent LCD for a calculator of this class.
I see no reason to dislike the fx991ES/115ES at all. It has outstanding features for a nonprogramable, nongraphing machine of its class and cost. I carry one to work along with my HP42S and HP50G.
▼
Posts: 536
Threads: 56
Joined: Jul 2005
Hi,
I think casio work to about 14 or 15 places and round to display. this is standard with most of their modern model. actually, i'd like to see HP extend their working precision too. issues regards guard digits etc are separate.
i did a write up of the casio 991es a while back here,
http://www.voidware.com/calcs/fx991es.htm
as i said in the article, it's pretty good for the money, although i didnt like the lack of key buffering on long expressions. i wonder if anyone else had the same problem.
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
...the actual 14digit result produced by the Casio, displayed only to 10 significant digits, (1.999999998), can readily be determined (by subtracting 1.99999) to be 1.9999999975828.
That's remarkably correct: on the HP200LX I get 1.999999997582797. So, if ln ln(1618 + 10^{7}. (e^{e}8/3+ 289)) returns 2 exactly that will be just the correct 10 digitresult (internally it should be 1.99999999999983). On the other hand, if 3/(7/10  307/439) returns 4390 exactly it is possible the calculator performs an algebraic simplification prior to giving the final answer. None of my HP calculators returns an exact numerical answer for this example. The HP200LX, for instance, returns 4,389.999999999788 and the HP50g returns 4390.0000026. However '3/(7/10  307/439)' EXPAN will return 4390.
Quote:
I see no reason to dislike the fx991ES/115ES at all. It has outstanding features for a nonprogramable, nongraphing machine of its class and cost.
It looks really nice, judging by this picture. Of course, the displayed result, which is equivalent to 1/2*(1 + e^{pi}), is correct:
http://www.wolframalpha.com/input/?i=12.07034632
Edited: 30 Nov 2009, 3:00 p.m.
▼
Posts: 758
Threads: 9
Joined: Jul 2007
Quote:
...if ln ln(1618 + 107(exp(exp(8/3))+289) returns 2 exactly that will be just the correct 10 digitresult (internally it should be 1.99999999999983).
The fx991ES/115ES gives 2 exactly, to the 14 digits of precision that it is capable.
My HP25 also gives 2, fwiw.
Quote:
On the other hand, if 3/(7/10  307/439) returns 4390 exactly it is possible the calculator performs an algebraic simplification prior to giving the final answer. None of my HP calculators returns an exact numerical answer for this example.
The fx991ES/115ES gives 4390 at 10 digits. It gives 4389.9999999966 to the 14 digits of precision that it is capable.
My HP25 gives 4389.999990, fwiw.
I'm pretty impressed with the accuracy of this inexpensive machine. As someone who paid the 2009 equivalent of US$670 in 1972 for a fourfunction Bomar 901, I'm simpleminded enough to be impressed by what today's machines can do at almost giveaway cost!
Edited: 30 Nov 2009, 11:14 p.m.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
My HP25 gives 4389.999990, fwiw.
Same on my HP15C. That's because intermediate results are rounded to 10 digits:
10digit guard
keystrokes mantissa digits exponent
.7
ENTER
307
ENTER
439
/ 6.993166287 015 E01 ;307/439
6.993166287 E01 ;rounded to 10 digits
 6.833713000 000 E04 ;0.76.993166287E01
6.833713000 E04 ;rounded to 10 digits
3
x<>y
/ 4.389999990 000 E+03 ;3/6.833713000E04
4.389999990 E+03 ;rounded to 10 digits
If a 10digit RPN calculator had five guard digits and did not round intermediate results to ten digits the final answer would be the same as those on CASIO fx991ES/11ES:
10digit guard
keystrokes mantissa digits exponent
.7
ENTER
307
ENTER
439
/ 6.993166287 01594 E01 ;307/439
6.993166287 E01 ;displayed result
 6.833712984 06000 E04 ;0.76.99316628701594E01
6.833712984 E04 ;displayed result
3
x<>y
/ 4.389999999 99657 E+03 ;3/6.83371298406000E04
4.390000000 E+03 ;displayed result
On one hand the HP method is consistent to what actually is on the display (considering the digits of the mantissa the user always has access to). On the other hand, CASIO's approach allows for greater accuracy during chain calculations, even though the displayed result sometimes is not what it appears to be (4389.9999999966 is different than 4890 albeit closer to it than 4389.999990).
Quote:
I'm pretty impressed with the accuracy of this inexpensive machine.
It performs quite well in the socalled Forensic Test. It passes Hugh Steer's Torture Test  Trigs magna cum laude and does very well on the other Torture Tests. Another problem I would put to it would be Kahan's Integral, that is, integrate sqrt(x)/(x1)1/ln(x) between 0 and 1:
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=83262 (messages #3 to #8)
The exact result is 2  ln(4)  EulerGamma or, numerically,
2  ln(4)  0.577215664901533 = 0.036489973978576
According to Hugh Steer's review, the fx991es is slow on integration, so this might not be a good idea...
Quote:
I'm simpleminded enough to be impressed by what today's machines can do at almost giveaway cost!
Same here. Perhaps because as late as 1979, soon after I had finished highschool, I still used a logarithm table to do my calculations :)
▼
Posts: 167
Threads: 13
Joined: Sep 2008
On a Casio FX9860G (slim): 0.0364899739857718 in 5 seconds: right to 9 sf. Not bad!
Nigel
Posts: 758
Threads: 9
Joined: Jul 2007
Quote:
Another problem I would put to it would be Kahan's Integral, that is, integrate sqrt(x)/(x1)1/ln(x) between 0 and 1:
The exact result is 2  ln(4)  EulerGamma or, numerically,
2  ln(4)  0.577215664901533 = 0.036489973978576
According to Hugh Steer's review, the fx991es is slow on integration, so this might not be a good idea...
On the fx991ES/115ES, naturally the expression sqrt(x)/(x1)1/ln(x) causes a "Math ERROR" at the boundaries of integration (0, 1). And apparently, the method of numerical integration used (GaussKronrod) evaluates the expression at the boundaries.
Integrating instead from 10^10 to 1+10^10, with the default integration tolerance of 10^5, the displayed 10digit result is entirely correct: 0.03648997398.
But, the full 15digit result is 0.0364899739808399.
It took 140 seconds to produce that result.
All things considered, that performance is not too bad for a US$17.48 machine.
Note: This post was edited to add the name of the integration method that the manual cites, and report a recalculation with slightly changed limits of integration, using the default integration tolerance value. A slightly shorter execution time resulted.
Edited: 2 Dec 2009, 12:32 a.m. after one or more responses were posted
▼
Posts: 18
Threads: 2
Joined: Oct 2009
Quote: Integrating instead from 10^6 to 1+10^6, with an integration tolerance of 10^10, the displayed 10digit result is entirely correct: 0.03648997398.
But, the full 15digit result is 0.0364899739808399.
It took 157 seconds to produce that result.
All things considered, that performance is not too bad for a US$17.48 machine.
That is impressive! I read that post thinking that the 33s (only slightly pricier) would be able to best that, but not even close. I tried with display set to "All", but I had to give up after about 20 minutes of integrating (can't risk the batteries with a physics final next week).
Thee 33s matched the Casio's time almost exactly when I set the display Fix6, but with far less accuracy. Sure the display result was fine  0.036490
But the 12 digit answer was poor  0.0364899763890
I wonder how the TI36X II would fare with this. I always though of it as the best bang foryourbuck calculator, but to be fair, I never really gave Casio a chance.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
I tried with display set to "All", but I had to give up after about 20 minutes of integrating (can't risk the batteries with a physics final next week).
That was the best thing to do. It takes about 2 hours and 45 minutes for the 33s to return 0.0364899739831 in level X and 3.64899739885e13 in level Y. This places the answer between 0.0364899739827 and 0.0364899739835, however the correct 12digit answer, 0.0364899739786, is out of these bounds.
In this article Prof. Kahan explains why this one is a difficult integral for numerical integrators. At page 30 he suggests a variable change:
Consider the original expression
(sqrt(x)/(x1)1/ln(x))*dx
by substituting x = y^2, the integrand becomes
(y/(y^21)1/ln(y^2))*2ydy =
(y/((y1)*(y+1))1/(2*ln(y)))*2ydy =
(2*y^2/((y1)*(y+1))y/ln(y))*dy
This improves the accuracy but it still takes too long when the calculator is set to FIX 10 and higher:
When integrating 2*SQ(Y)/((Y1)*(Y+1))Y/LN(Y) between 0 and 1 on the HP33s retuns 0.0364899739768 in 1 minute and 34 seconds (FIX 9), which is correct to 10 significant digits. If the display is set to FIX 10 it will take about 50 minutes before the calculators shows a worse answer: 0.0364899739936.
Edited: 2 Dec 2009, 12:06 p.m.
▼
Posts: 758
Threads: 9
Joined: Jul 2007
Quote:
Consider the original expression
(sqrt(x)/(x1)1/ln(x))*dx
by substituting x = y^2, the integrand becomes
(2*y^2/((y1)*(y+1))y/ln(y))*dy
This improves the accuracy...:
When integrating 2*SQ(Y)/((Y1)*(Y+1))Y/LN(Y) between 0 and 1 on the HP33s retuns 0.0364899739768 in 1 minute and 34 seconds (FIX 9), which is correct to 10 significant digits. If the display is set to FIX 10 it will take about 50 minutes before the calculators shows a worse answer: 0.0364899739936.
On the fx991ES/115ES, there is a significant speedup in results from integrating g(x)=2*x^2/((x1)*(x+1))x/ln(x) compared to integrating f(x)=(sqrt(x)/(x1)1/ln(x)).
Integrating g(x)=2*x^2/((x1)*(x+1))x/ln(x) from 10^10 to 1+10^10, with the default integration tolerance of 10^5, the displayed 10digit result is entirely correct: 0.03648997398.
The full 15digit result is 0.0364899739779277.
It took 66 seconds to produce that result.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
Integrating g(x)=2*x^2/((x1)*(x+1))x/ln(x) from 10^10 to 1+10^10, with the default integration tolerance of 10^5, the displayed 10digit result is entirely correct: 0.03648997398.
...
It took 66 seconds to produce that result.
43m14.25s for my HP50g to return 3.64899739837E2... It appears the GaussKronrod integration method you have mentioned, which are used on many modern calculators, is faster and more accurate than the Romberg method that have been being used on HP calculators since 1979, starting with the HP34C, if I am not wrong. That was the best option then given the HP34C memory constraints.
▼
Posts: 21
Threads: 1
Joined: Feb 2009
I didn't bother trying to integrate this on any of my calculators.
I went to WolframAlpha and pasted "integrate sqrt(x)/(x1)1/ln(x) between 0 and 1" into the box and it returned:
2gammalog(4) ~0.036489973978576520559023667001244432806840395339565892952872746128345029282945897851326282715415875401...
Plus a graph of the integral.
Instantly.
But I suppose that's cheating.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
2gammalog(4) ~0.036489973978576520559023667001244432806840395339565892952872746128345029282945897851326282715415875401...
Plus a graph of the integral.
The first 16 digits match the answer I got on my HP200LX, therefore chances are the WolframAlpha result is correct :)
The graph is somewhat misleading though, as you can see by copying and pasting "plot sqrt(x)/(x1)1/ln(x) between 0 and 0.015" to WolframAlpha.
A real XXIst century calculator would be able to solve this integral symbolically but it has yet to be released...
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
That is a holy mackerel project.
It is so big in its potential!
It also is rather amazing how many digits they accept into the buffer.
I tried this one for fun:
integrate 1/x+1 from 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
to .01
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
But then I did a mean thing and overtaxed the server:
integrate 1/x^9999+1 from 0.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 to .01
and got this:
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Just for fun, I asked "What is the meaning of life" and got this:
Perhaps I should have asked that BEFORE you ruined it :)
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Posts: 758
Threads: 9
Joined: Jul 2007
After adjusting the expression I used in the fx115ES to replace a multiplication by a reciprocal with a simple division, the speed was further improved to only 57.5 seconds. The full 15digit result very minimally changed to 0.0364899739779289. I also found in another experiment that the result was the same and the execution time only minimally increased after setting the "integration tolerance" to 10^10, compared to using the default value of 10^5.
I tried to get a 10digit result for integration of the original function f(x)=(sqrt(x)/(x1)1/ln(x)) on my HP42S with ACC set to 10^10. After more than two hours of run time, I gave up.
Although Hugh's review said that integration was slow in this Casio model, I believe that must be a comparison only to other Casio models. The evidence shows that fx991ES/115ES quadrature is blazingly fast (more than two orders of magnitude for this example!) compared to that of any HP handheld.
I don't know much about the GaussKronrod quadrature method, but it would be a most welcome replacement (or better, a selectable option) for the methodolgy traditionally implemented for the last third of a century on HP calculators.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Have you seen Hugh Steer's torture test: integration? The 48G overall score was 100% while fx991es got 92%. It appears the problem with HP calculators for this particular integral is not the integration method but the loss of accuracy at the extremes of the integration interval (because they round intermediate results to the number of digit of the display, as we know). This might explain why the performance of the 33s dramatically decreases when the display mode is changed from FIX 9 to FIX 10 (I would guess the HP42S would have no problem for ACC=1e9 but I haven't checked this yet).
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
The evidence shows that fx991ES/115ES quadrature is blazingly fast (more than two orders of magnitude for this example!) compared to that of any HP handheld.
I don't know much about the GaussKronrod quadrature method, but it would be a most welcome replacement (or better, a selectable option) for the methodolgy traditionally implemented for the last third of a century on HP calculators.
Ya learn something every day! I was puzzled about what you were doing in this thread, because I have the predecessor fx115MS, which looks almost identical. It uses Simpson's Rule for integration, just like the 1981 Casio fx3600P of mine.
A online review for the fx115ES confirms that the new model upgraded to GaussKronrod. Maybe there was more to the fx115 replacement than met the eye.
Upscale TI models have used GaussKronrod for many years. My 1993 TI82 generally outperforms my HP models on integration, other than that the user must ensure that the integrand function is defined at the endpoints:
fnInt(sqrt(X)/(X1)1/ln(X),X,1E12,11E12,1E12)
.036489974 (displayed in 54 seconds)
0.036489973978679 (revealed)
Quote:
I tried to get a 10digit result for integration of the original function f(x)=(sqrt(x)/(x1)1/ln(x)) (for 0 <= x <= 1) on my HP42S with ACC set to 10^10. After more than two hours of run time, I gave up.
It should be noted that the ACC parameter on the HP42S is not the same as FIX on the "lesser" RPN models (prior to the HP33s)  or even the accuracy factor on nonHP calcuators using GaussKronrod. ACC is a multiplicative (not absolute) uncertainty factor applied to the integrand function. With the value of the function f(x) well below 0.1 for 0 < x < 1, the uncertainty of the function at almost all points for ACC = 1E10 is well below 1E11. This tight tolerance drives a large number of function evalulations, in order to achieve calculated estimates of the integral that do not change by more than the small totalintegral uncertainty as evermore evaluations are taken.
On my  er, perhaps loathsome  HP32SII, I got 0.0364899740909 in 605 seconds with a FIX 9 setting. The deviation from the correct answer of 0.036489973978576 is 1.123E10  well within the maximum error of 0.5 * 1E9 * (10) = 5E10 estimated for FIX 9.
In order to get a corresponding answer on the HP42S, I set ACC to a value such that the mean value of the function times ACC approximately equaled the FIX 9 uncertainty: ACC = 5.00E10 / 0.0365 = 1.37E08. This yielded an integral of 0.036489974091, with an estimated error of 4.99963E10, in about 1000 seconds.
Please see my sole contribution to the HP Articles Forum (#556) for more information.
 KS
Edited: 5 Dec 2009, 11:54 p.m. after one or more responses were posted
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hello Karl,
Quote:
I was puzzled about what you were doing in this thread, because I have the predecessor fx115MS, which looks almost identical. It uses Simpson's Rule for integration, just like the 1981 Casio fx3600P of mine.
Have you checked that on your fx115MS? Simpson 3/8 is slightly better than the ordinary Simpson's Rule and yet the results are not good on TurboPascal:
Program Simpson_3_8;
var a, b, h, s1, s2, x: real;
n: integer;
function f(x: real): real;
begin
f:=Sqrt(x)/(x1)1/Ln(x)
end;
begin
ClrScr;
Write('A, B, N: ');
ReadLn(a, b, n);
n:=3*n;
h:=(ba)/n;
s1:=0;
s2:=0;
x:=a+h;
repeat
s1:=s1+f(x+2*h);
s2:=s2+f(x)+f(x+h);
x:=x+3*h
until x>a+(n3)*h;
s2:=s2+f(x)+f(x+h);
WriteLn(3*h/8*(f(a)+f(b)+2*s1+3*s2))
end.
A, B, N: 1e11 0.9999999 10000
3.6495766224E02
The second function doesn't give a better result:
f:=2*x*x/((x1)*(x+1))x/Ln(x)
A, B, N: 1e11 0.9999999 10000
3.6496234630E02
Quote:
Please see my HP Articles Forum contribution (#556) for more information.
That's an excellent reference! I looked it up when I was checking wheter the integrating methods were the same on all HP calculators. I ought to have provided the link myself as it might be useful to those who didn't know it yet.
Regards,
Gerson.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi, Gerson 
Quote:
Have you checked that on your fx115MS? Simpson 3/8 is slightly better than the ordinary Simpson's Rule
For the few estimations I did, the fx3600P result matched the fx115MS result, although the latter computed much faster. Basic Simpson's Rule requires that the number of subdivisions be even; both models allow the user to specify the number of subdivisions as 2 raised to an integer power k from 1 to 9.
Quote:
That's an excellent reference! I looked it up when I was checking wheter the integrating methods were the same on all HP calculators
Thanks. It may end up as my one and only article, as I have no topic in mind for another.
 KS
Edited: 5 Dec 2009, 2:15 p.m.
Posts: 727
Threads: 43
Joined: Jul 2005
Quote: I tried to get a 10digit result for integration of the original function f(x)=(sqrt(x)/(x1)1/ln(x)) on my HP42S with ACC set to 10^10. After more than two hours of run time, I gave up.
I tried this with Emu42 (with the "Authentic Calculator Speed" option turned off!), and it returned 3.64899740064e2, after evaluating the function 16383 times. Free42 returned 3.64899740835e2 after 4095 evaluations.
Running Emu42 with "Authentic Calculator Speed" turned on, I observed 224 evaluations in one minute, which suggests that the complete integral should take 73 minutes, but I didn't actually wait for it to finish, nor did I try this on my real 42S.
I wonder how many evaluations this takes with GaussKronrod quadrature. Is the Casio faster because of its quadrature algorithm, or because of faster hardware?
 Thomas
Edited: 7 Dec 2009, 12:41 a.m.
▼
Posts: 758
Threads: 9
Joined: Jul 2007
Quote:
I wonder how many evaluations this takes with GaussKronrod quadrature. Is the Casio faster because of its quadrature algorithm, or because of faster hardware?
I won't let ignorance keep me from speculating. I firmly believe the speed (and accuracy) of numerical integration on the Casio fx115ES/991ES stems from the GK algortithm.
The best HP hardware (HP50G) has been reported in this thread as requiring about fourty times longer than this cheap Casio for the problems we've been playing with in this thread.
Who, outside Casio, knows anything about the Casio hardware? Physically it appears to be just a single IC under goop (powered by a solar cell or one LR44). I've found no discussions of it anywhere on the web. It is an excellent performer for US$18, and it's the first nonRPN calculator in 35 years that I could use regularly if I had to.
Edited: 8 Dec 2009, 12:16 p.m.
Posts: 850
Threads: 10
Joined: Mar 2009
Quote:
You seem to suggest that explicit complex"ing" is needed throughout the sequence.
Yes, I think that if it had the capability to automatically look for complex results upon real result error, it would have slowed down the processing of the 35s even more. It is already heavily criticised for being one of the slowest HPs in recent years (most Pioneers & even Voyagers beat it). Although the same processor as the 33S, it is slower I guess due to more features and broader data type handling. From information gleaned on the web and processor data sheet, it seems HP is already running it at ~6MHz  33% above recommended for 3V (assuming the 2 batteries are in //). (I have NOT verified this with my own measurements, e.g. oscilloscope). I would only hope HP sees enough of a market to release an updated HP35s with a faster processor (perhaps emulated on an ARM like the new 12C) and fix a few more serious bugs (e.g. keyboard buffering, program size/checksum etc.).
Posts: 776
Threads: 25
Joined: Jun 2007
Quote: Maybe I should prepare a onehour lecture about the dark side of calculators for my Introduction to Engineering course.
Can't hurt!
Other things to point out to your classes (you probably do already, but some students need to be beaten over the head several times to get important points): significant figures (as others have already mentioned, some students tend to believe EVERY digit that the calculator produces). Also, the sensibility of answers (i.e. do they make sense). I once had a student in physics class determine that the stopping distance of a car going 50 mph was 0.3 mm! I asked him if he had ever stopped his car in so short a distance, and he had to agree that his answer didn't seem quite right.
▼
Posts: 16
Threads: 4
Joined: Nov 2009
Actually I do spend a fair amount of time on the topic in my Numerical Analysis course (300 level). Recently, however, my examples are becoming less and less relevant, what with MATLAB defaulting to double precision and Windows/Mac OS's now firmly moving into 64bit. It never occured to me to use calculators to highlight truncation effects, most probably due to my Casio's "You Can't Handle the Truth" attitude. This thread has pointed me to a treasure trove of intriguing examples for my students. Who knows... I might even be able to win a few of them over to the RPN camp.
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
I asked him if he had ever stopped his car in so short a distance, and he had to agree that his answer didn't seem quite right.
If he had calculated the corresponding negative acceleration he'd be quite amazed at the result...
▼
Posts: 776
Threads: 25
Joined: Jun 2007
Yeah  probably 10^4 or 10^5 g  you'd be flatter than the proverbial pancake!
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Yes, about 8.5*10^4 g, if I haven't made any mistake. Great magnitude estimation!
▼
Posts: 850
Threads: 10
Joined: Mar 2009
Quote:
Yes, about 8.5*10^4 g, if I haven't made any mistake. Great magnitude estimation!
Quote:
If he had calculated the corresponding negative acceleration he'd be quite amazed at the result...
Would this even be meaningful to the student if he didn't even catch on that 0.3mm was a miraculously short stopping distance for even just a person (let alone a car) travelling at 50mph?
▼
Posts: 776
Threads: 25
Joined: Jun 2007
Bart,
Your last sentence was my original point  the student hadn't bothered to think/realize that 0.3 mm was indeed awful short!
Posts: 8
Threads: 1
Joined: Feb 2009
Hi Mohammed,
The first term ( 1/3 * 3  1 ) calculates on my HP 35s to 1*10^12.
So if this term is raised to the power of (1/3)^3 it results in INVALID y^x
(it seems there is no complex number support for y^x)
On my HP 42s the end result is 0.356951358148 + i 0.0417216301054
You can find a test of calculator functions accuracy on this website:
http://www.voidware.com/calcs/torturetest.htm
Cheers,
Herbert
▼
Posts: 850
Threads: 10
Joined: Mar 2009
Hi Herbert,
Quote:
(it seems there is no complex number support for y^x)
See my psot just before yours. Although not as good as the 42S and the RPL (28/48/49/50) models, it does have some complex support. It's better than the 32S/SII/33S in my opnion and with some manipulation, the 35S can do quite a bit of complex stuff. Regards, Bart
edit: by the way: y^x is the way to get a sqrt for a neg number on the 35s
Edited: 30 Nov 2009, 4:41 a.m.
▼
Posts: 8
Threads: 1
Joined: Feb 2009
Hi Bart,
Thanks for the neat trick with adding 0i0.
I sent my post before I updated the messages page just to see that there were already 2 similar comments.
I saw your comment only after I had posted mine already.
But I agree, the HP 35s is in good hands a capable machine.
Herbert
