 The Museum of HP Calculators

HP Forum Archive 20

 [edited] from the HHC email list, what is the proper answer to 8 ENTER 3 divide 2 divide on 10 digit calcMessage #1 Posted by gene wright on 28 Sept 2011, 4:08 p.m. [EDITED] The email thread is going wild, but consider this: 8 ENTER 3 divide shows 2.666666667 in the X register. Now do a 2 divide. What should be shown in FIX 9? 1.333333334 or 1.333333333 ? Older generation calculators such as the 15c, 41c, etc. and calculators without guard digits give a 4 at the end. Isn't that as it should be? After all, the calculator does not know you are really trying to get 1/3 --- all it knows is it has 2.666666667 in X and you divide by 2. Thoughts? Edited: 28 Sept 2011, 4:40 p.m. after one or more responses were posted

 Re: Ok, from the HHC email list, what is the proper answer to 8 ENTER 2 divide 2 divide on 10 digit calcMessage #2 Posted by Olivier De Smet on 28 Sept 2011, 4:14 p.m.,in response to message #1 by gene wright it's 2.000000000 ;) for a working unit Edited: 28 Sept 2011, 4:15 p.m.

 Re: Ok, from the HHC email list, what is the proper answer to 8 ENTER 2 divide 2 divide on 10 digit calcMessage #3 Posted by Werner on 28 Sept 2011, 4:36 p.m.,in response to message #1 by gene wright On a 10-digit calc without guard digits, (1) 2.666666667 divided by 2 should yield 1.333333334 (2) as should 2.666666669 divided by 2 ... round to even, and no 'cosmetic rounding', please. of course, the 41C does not do (2). But the 42S does (with 12 digits) Cheers, Werner

 Re: [edited] from the HHC email list, what is the proper answer to 8 ENTER 2 divide 2 divide on 10 digit calcMessage #4 Posted by Steve Simpkin on 28 Sept 2011, 4:50 p.m.,in response to message #1 by gene wright Gene, As you stated in the HHC Digest emails, 1.333333334 is the correct answer "given the architecture being used". Other calculators have used guard digits to reduce this limitation but HP chose not to, at least in their typical classic BCD designs. The WP34S displays a 12 digit answer of 1.33333333333. Pressing "SHOW" displays the full 16 digit internal answer of 1333333333333334.

 Re: [edited] from the HHC email list, what is the proper answer to 8 ENTER 2 divide 2 divide on 10 digit calcMessage #5 Posted by Dieter on 28 Sept 2011, 5:05 p.m.,in response to message #4 by Steve Simpkin The result returned by the 34s depends from which of the seven rounding modes you chose. ;-) Its default setting (RM 0) is "round 0.5 to even", so 1/3 divided by 2 will return 0,16...666, like most newer HP calculators. Set it to "round 0.5 up" (RM 1) and it will return 0,16...667 like most classic HPs. Dieter

 Re: [edited] from the HHC email list, what is the proper answer to 8 ENTER 2 divide 2 divide on 10 digit calcMessage #6 Posted by Steve Simpkin on 28 Sept 2011, 5:30 p.m.,in response to message #5 by Dieter Wow! I did not know about those options. I never cease to be amazed by what the WP34S can do.

 Re: Ok, from the HHC email list, what is the proper answer to 8 ENTER 2 divide 2 divide on 10 digit calcMessage #7 Posted by Dieter on 28 Sept 2011, 4:55 p.m.,in response to message #1 by gene wright Let's assume you first want to divide 8 by 3, not 2. ;-) First of all, the calculator does not return 8/3 - instead it displays the rounded first ten digits of this result. This is what you said in your last sentence - the result is not 8/3 but 2,6666 66667 - the last digit is correctly rounded up. So the next step does not divide 8/3 by 2. It divides 2,6666 66667 by two. The correct answer here is 1,3333 33333 5. Whether this result is rounded up or down depends on the rounding method implemented in the calculator. If it rounds to the closest digit, the usual approach is to round a 5 up to the next digit, i.e. ...334. However, there are also strategies like "round to even" or "round to odd" for cases like this where the digits following the displayed result are exactly ...500. In this case the calculator rounds to the next even resp. next odd digit, resulting in ...334 resp. ...333. The idea behind this is to avoid error accumulation. Anyway, I prefer the "classic" rounding strategy: 0 to 4 are rounded down, 5 to 9 are rounded up. At least that's what I would expect. I admit I was a bit puzzled when I found out that my (then) brand new 35s seemed to round to even: divide 1/3 by 2 and you'll see it round down to 0,16666 66666 66 instead of ...67. Dieter

 Re: Ok, from the HHC email list, what is the proper answer to 8 ENTER 2 divide 2 divide on 10 digit calcMessage #8 Posted by C.Ret on 29 Sept 2011, 5:59 p.m.,in response to message #7 by Dieter Hello, I don't know any things about internal mecanics of the calculators. What really surprise me is that I get on my old 10-digits HP-41C different numeric approximations for the same computation. The quantity 8/3/2 or ( 8/3 )/2 or (8/2)/3 or 8/6 are all exactly 4/3. What is really surprising is that the way we drive the computation on your calculator give different numeric résults. I don't know any think about calculators internal macanis. I only understand that cascading numeric approximation (due to a limited number of digits used) lead to the different round-off results. ```8[ENTER^] 3 [ / ] 2 [ / ] returns 1.333333334 2[ENTER^] 3 [ x ][1/x] 8 [ x ] returns 1.333333334 8[ENTER^] 3 [1/x][ x ] 2 [ / ] returns 1.333333333 8[ENTER^] 3 [1/x][ x ] 2 [1/x][ x ] returns 1.333333333 8[ENTER^] 2 [ / ] 3 [ / ] returns 1.333333333 8[ENTER^] 3 [ENTER^] 2 [ x ][ / ] returns 1.333333333 3[ENTER^] 8 [ / ] 2 [ x ][1/x] returns 1.333333333 Etc. ``` So the correct answer for a 10-digits calculator is 1.333...; It is the same for 12- 14- 24- 500-digits calculators. Edited: 30 Sept 2011, 4:40 p.m. after one or more responses were posted

 Re: Ok, from the HHC email list, what is the proper answer to 8 ENTER 2 divide 2 divide on 10 digit calcMessage #9 Posted by Dieter on 29 Sept 2011, 6:45 p.m.,in response to message #8 by C.Ret The results you get are completely correct and that's also what I would have expected here: ```8 [ENTER^] 3 [ / ] 2 [ / ] returns 1.333333334 ``` Sure. The first result is 2,6666666667, and 1/2 of that is 1,3333 33333 5 which is correctly rounded to ...334. ```2 [ENTER^] 3 [ x ][1/8] 8 [ x ] returns 1.333333334 ``` I assume that's [1/x]. ;-) Again, the result after this operation is 0,16666 66667 (correct) and 8x that is 1,3333 33333 6 which again is rounded correctly to ...334. ```8 [ENTER^] 3 [1/x][ x ] 2 [ / ] returns 1.333333333 ``` Here you are multiplying 8 with 0,33333 33333 giving 2,6666 66666 4. Which then is correctly rounded to ..666, resp. ...333 after the final division by 2. There is always the same basic idea: 8 [ENTER] 3 [÷] does not return 8/3. It returns the first ten rounded digits of this value. Every result of a single operation is correct (in its first ten significant digits), but in a series of numeric operations the rounding error will accumulate. You may also try this: ```2 [sqrt] 2 [÷] => 0,7071067810 2 [sqrt] [1/x] => 0,7071067814 0,5 [sqrt] => 0,7071067812 [DEG] 45 [sin] => 0,7071067812 45 [cos] => 0,7071067812 [RAD] [Pi] 4 [÷] [sin] => 0,7071067813 [Pi] 4 [÷] [cos] => 0,7071067811 ``` Only the three results ending in ...812 show the expected value of sqrt(2)/2. In these three cases the exact argument is given. It is exactly 0,5 resp. exactly 45 degrees. In all other cases, however, the argument was only an approximation - Pi/4 is not exactly 0,7853981635 and sqrt(2) is not exactly 1,414213562. That's where the different (yet correct) results come from. And that's why there are guard digits - but not for us users who only see the rounded 10-digit result. ;-) Dieter Edited: 30 Sept 2011, 9:06 a.m.

 Re: Ok, from the HHC email list, what is the proper answer to 8 ENTER 2 divide 2 divide on 10 digit calcMessage #10 Posted by Jake Schwartz on 30 Sept 2011, 3:21 p.m.,in response to message #9 by Dieter Quote: You may also try this: 2 [sqrt] 2 [÷] => 0,7071067810 2 [sqrt] [1/x] => 0,7071067814 0,5 [sqrt] => 0,7071067812 [DEG] 45 [sin] => 0,7071067812 45 [cos] => 0,7071067812 [RAD] [Pi] 4 [÷] [sin] => 0,7071067813 [Pi] 4 [÷] [cos] => 0,7071067811 Just as an added "celebration" of the 34S, for what it is worth, I wanted to report that 2 [sqrt] 2 [÷] => 0.70710678119, with SHOW yielding 0.7071067811865475 2 [sqrt] [1/x] => 0.70710678119, with SHOW yielding 0.7071067811865475 0,5 [sqrt] => 0.70710678119, with SHOW yielding 0.7071067811865475 [DEG] 45 [sin] => 0.70710678119, with SHOW yielding 0.7071067811865475 45 [cos] => 0.70710678119, with SHOW yielding 0.7071067811865475 [RAD] [Pi] 4 [÷] [sin] => 0.70710678119, with SHOW yielding 0.7071067811865474 [Pi] 4 [÷] [cos] => 0.70710678119, with SHOW yielding 0.7071067811865476 .....with only the final two computations differing from the others by one count in the 16th place. I am impressed. Jake

 Re: Ok, from the HHC email list, what is the proper answer to 8 ENTER 2 divide 2 divide on 10 digit calcMessage #11 Posted by Dieter on 2 Oct 2011, 1:07 p.m.,in response to message #10 by Jake Schwartz Jake, Quote: Just as an added "celebration" of the 34S, for what it is worth, I wanted to report that... (...) ...only the final two computations differing from the others by one count in the 16th place. I am impressed I am afraid I have to pour some water into the wine. ;-) While I really appreciate the accuracy of the results returned by the WP34s, the reason for its good results here (and the differences in the 10-digit results) mainly is the input value itself: Both sqrt(2), Pi and by the way also e happen to round very well to 16 digits, while on the other hand the error is quite large in 10 digit precision. Simply take a look at the correct values (blanks inserted after 10th, 12th and 16th significant digit): ``` sqrt(2) = 1,414213562 37 3095 048... Pi = 3,141592653 58 9793 238... e = 2,718281828 45 9045 235... ``` You see, rounding to 10 digits always causes an error of roughly 0,4 ULP, that's almost the worst case possible. On the other hand the rounded 16 digit value is only half that (roughly 0,2 ULP) or even merely 0,05 ULP for sqrt(2). Rounding to 12 digits also gives good results, especially for Pi and e (less than 0,1 ULP). It even gets better: Set the 34s rounding mode to RM 1 (i.e. round 0.5 up, like most classic HPs), and this happens: ``` [Pi] 4 [÷] = 1/4 of 3,1415926535897932 = 0,78539 81633 97448 25 exactly = 0,78539 81633 97448 2 in RM 0 (newer HPs) = 0,78539 81633 97448 3 in RM 1 (classic HPs) ``` which agrees to the exact value... ``` Pi/4 = 0,78539 81633 97448 309... ``` ...with an error of less than 0,1 ULP, i.e. less than 1 unit in the 17th (!) digit. In other words, setting RM 1 (like the classic HPs) will even remove that last "inconsistency" in the (radians) trig functions: ``` [rad] [Pi] 4 [÷] [sin] => 0,70710 67811 86547 5 [Pi] 4 [÷] [cos] => 0,70710 67811 86547 5 ``` By the way - as shown above, Pi/4 rounds very well to 10 digits (error less than 0,03 ULP). So you can do this in a classic 10-digit machine: ``` [rad] 45 [D->R] [sin] => 0,70710 67812 45 [D->R] [cos] => 0,70710 67812 ``` q.e.d. ;-) Dieter Edited: 2 Oct 2011, 1:18 p.m. Go back to the main exhibit hall