The Museum of HP Calculators

HP Forum Archive 20

 When is exact mode not so exact?Message #1 Posted by hugh steers on 22 Feb 2012, 3:44 p.m. so, sqrt(99) = 9.949874371066199547344798... however, on the Hp50g in approx mode, 99 SQRT = 9.94987437107 so far, so good. But in "exact" mode... 99 SQRT ->NUM = 9.94987437108 how embarrassing :-) [discovery credit to BruceH] Edited: 22 Feb 2012, 3:46 p.m.

 Re: When is exact mode not so exact?Message #2 Posted by Marcus von Cube, Germany on 22 Feb 2012, 3:53 p.m.,in response to message #1 by hugh steers The result is 3 * sqrt(11), computed to 12 digits. Exact mode seems to simplify the expression before evaluating it.

 Re: When is exact mode not so exact?Message #3 Posted by Ronald Williams on 22 Feb 2012, 6:21 p.m.,in response to message #2 by Marcus von Cube, Germany FYI - If one is looking for a numeric result in exact mode then make sure flag -03 is set or using the mode key and menus check numeric and uncheck approx from the cas menu. Both results will agree.

 Re: When is exact mode not so exact?Message #4 Posted by Bart (UK) on 23 Feb 2012, 6:14 a.m.,in response to message #3 by Ronald Williams Is this always going to produce the more accurate result?

 Re: When is exact mode not so exact?Message #5 Posted by Ronald Williams on 23 Feb 2012, 2:14 p.m.,in response to message #4 by Bart (UK) The exact result is 3 * sqrt(11). However, numeric (floating point) results are usually approximations. For this case sqrt(99) = sqrt(9*11) = sqrt(9)*sqrt(11) = 3*sqrt(11). 11's sqrt does not have a an simple exact floating point representation. This brings up the topic of accuracy or in this case I would say consistency of results. If accuracy is desired then I suggest reading this article http://h20331.www2.hp.com/hpsub/downloads/HP_Calculator_eNL_01_January_2012.pdf pages 21-25 and pages 50-51. Here is another http://groups.google.com/group/comp.sys.hp48/browse_thread/thread/16ea6ddfb49e34eb/a53d3ab60541838d?lnk=gst&q=accuracy#a53d3ab60541838d Does the 12th digit really matter or is it more important to know the capability and limitations of the tool you are using to solve the problem at hand? Hopefully, the links are not broken, I usually don't post.

 Re: When is exact mode not so exact?Message #6 Posted by Bart (UK) on 24 Feb 2012, 5:30 a.m.,in response to message #5 by Ronald Williams Quote: Does the 12th digit really matter or is it more important to know the capability and limitations of the tool you are using to solve the problem at hand? This is where I was heading Quote: 11's sqrt does not have a an simple exact floating point representation. Neither does 99's sqrt. There is a natural loss of information in rounding. The difference here is that when converted to a numerical answer immediately, there is one rounding. However when simplified symbolically first, the loss of information from the rounding gets multiplied by 3.Looking at another example (very simplistic, but it shows the point):RPN: 1 ENTER pi SQUARED / SQRT (& -> NUM as required).Hugh's first setting (symbolic approx.): 0.318309886183Hugh's second setting (symbolic exact): 0.318309886184Your setting (numeric exact): 0.318309886183Something with more significant digits (Wolfram Alpha, windows calculator, Hugh's ExactCalc) etc.: 0.318309886183790671....So in this case the symbolic simplification gives a better answer.The example of the original post is very good in that it shows how the loss of accuracy accumulates. Anyone doing a series of calculations (e.g. a formula or program) and thinks they are getting an answer "correct to the last digit of the calculator's display capability" is fooling themselves. It is therefore always important to assess the influence of the elements of a formula on rounding & accuracy. Computers have made too easy to just put in numbers and take a result. Too often I see people using a result to many digits when they have not even considered the order of magnitude (and I can see the old slide-rulists jumping in here "we had to work that out, so you always had a sense of what order of magnitude to expect" :-) ) .Another interesting read is Prof. Kahan's A Logarithm Too Clever by Half, and many other articles he wrote (available on his webpage http://www.cs.berkeley.edu/~wkahan/).So, my point in this is: Hugh's implication that the 50g is "not so accurate in accurate mode" is A BIG RED HERRING, which I am sure he knows as he is well versed in computer mathematics (Hugh, did you post this just to see where it would go? :-) ).

 Re: When is exact mode not so exact?Message #7 Posted by Ronald Williams on 24 Feb 2012, 10:42 a.m.,in response to message #6 by Bart (UK) Not that I want to beat this issue to death but does the fact you used pi in your simple example stack the deck so to speak. [/quote] "Looking at another example (very simplistic, but it shows the point): RPN: 1 ENTER pi SQUARED / SQRT (& -> NUM as required). Hugh's first setting (symbolic approx.): 0.318309886183 Hugh's second setting (symbolic exact): 0.318309886184 Your setting (numeric exact): 0.318309886183 Something with more significant digits (Wolfram Alpha, windows calculator, Hugh's ExactCalc) etc.: 0.318309886183790671.... So in this case the symbolic simplification gives a better answer." [/quote] Would the same result be obtained if you selected a simple integer or 'e' or one of the internal constants from the Constants Library? PS - Wasn't life much simpler when we only had 3 significant digits to worry about? My slide rule(s) all work today as they did when purchased. The only noticeable change is that it's harder for me to read them now :-)

 Re: When is exact mode not so exact?Message #8 Posted by Bart (UK) on 24 Feb 2012, 5:37 a.m.,in response to message #5 by Ronald Williams Quote: I usually don't post. You should do so more often, it helps to get the grey matter working (well, mine anyway :-) ).

Go back to the main exhibit hall