# HP Forums

Full Version: When is exact mode not so exact?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

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.

The result is 3 * sqrt(11), computed to 12 digits. Exact mode seems to simplify the expression before evaluating it.

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.

Is this always going to produce the more accurate result?

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

pages 21-25 and pages 50-51. Here is another

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.

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.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.

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? :-) ).

Quote:
I usually don't post.

You should do so more often, it helps to get the grey matter working (well, mine anyway :-) ).

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 :-)