When is exact mode not so exact?



#2

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.


#3

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


#4

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.


#5

Is this always going to produce the more accurate result?


#6

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.


#7

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

#8

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

#9

Quote:
I usually don't post.

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

Possibly Related Threads...
Thread Author Replies Views Last Post
  [HP Prime] "Error while checking exact value with approximate value, returning both!" Chris Pem10 13 789 12-06-2013, 05:12 AM
Last Post: parisse
  Integration question and "RPN" mode comment Craig Thomas 16 908 12-05-2013, 02:32 AM
Last Post: Nick_S
  HP Prime: Recommendation for future RPN Program Mode BruceTTT 3 267 11-13-2013, 10:03 PM
Last Post: BruceTTT
  Program to change entry mode on Prime Michael de Estrada 3 276 10-28-2013, 10:13 AM
Last Post: Han
  Prime: Exam mode (possible duplicate after funny response first time) Paul Townsend (UK) 1 191 10-24-2013, 03:09 PM
Last Post: Tim Wessman
  Does RPN entry mode cause the Prime keyboard to lock up ? Michael de Estrada 14 691 10-22-2013, 06:27 PM
Last Post: John Colvin
  HP Prime: Edit integer in RPN mode plivesey 15 633 10-18-2013, 04:34 PM
Last Post: kris223
  Temporary User Mode Key Programs not working in RPN BruceTTT 7 397 10-14-2013, 01:46 PM
Last Post: BruceTTT
  HP Prime: MAKELIST in RPN mode? toml_12953 2 216 10-13-2013, 07:40 PM
Last Post: BruceH
  Low battery slow mode Marcel Samek 4 249 09-18-2013, 02:02 PM
Last Post: Harald

Forum Jump: