[edited] from the HHC email list, what is the proper answer to 8 ENTER 3 divide 2 divide on 10 digit calc « Next Oldest | Next Newest »

 ▼ Gene Wright Posting Freak Posts: 1,545 Threads: 168 Joined: Jul 2005 09-28-2011, 04:08 PM [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 ▼ Olivier De Smet Senior Member Posts: 275 Threads: 41 Joined: Mar 2010 09-28-2011, 04:14 PM it's 2.000000000 ;) for a working unit Edited: 28 Sept 2011, 4:15 p.m. Werner Member Posts: 163 Threads: 7 Joined: Jul 2007 09-28-2011, 04:36 PM 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 Steve Simpkin Member Posts: 225 Threads: 9 Joined: Jul 2008 09-28-2011, 04:50 PM 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. ▼ Dieter Senior Member Posts: 653 Threads: 26 Joined: Aug 2010 09-28-2011, 05:05 PM 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 ▼ Steve Simpkin Member Posts: 225 Threads: 9 Joined: Jul 2008 09-28-2011, 05:30 PM Wow! I did not know about those options. I never cease to be amazed by what the WP34S can do. Dieter Senior Member Posts: 653 Threads: 26 Joined: Aug 2010 09-28-2011, 04:55 PM 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 ▼ C.Ret Senior Member Posts: 260 Threads: 0 Joined: Oct 2008 09-29-2011, 05:59 PM 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 ▼ Dieter Senior Member Posts: 653 Threads: 26 Joined: Aug 2010 09-29-2011, 06:45 PM 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. ▼ Jake Schwartz Senior Member Posts: 349 Threads: 66 Joined: Apr 2007 09-30-2011, 03:21 PM 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 ▼ Dieter Senior Member Posts: 653 Threads: 26 Joined: Aug 2010 10-02-2011, 01:07 PM 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.

 Possibly Related Threads... Thread Author Replies Views Last Post HP Prime: Proper Use of Home View and CAS View James Williams 9 1,879 12-05-2013, 02:44 PM Last Post: James Williams HP-Prime : Extracting elements from a list in RPN Miguel Toro 0 680 11-15-2013, 06:44 PM Last Post: Miguel Toro [HP-Prime] Picking elements from a List in a program Jean-Michel 3 857 11-15-2013, 04:16 AM Last Post: dg1969 Hp PRIME - how to send a list to the connectivity Kit giancarlo 1 614 11-10-2013, 11:50 AM Last Post: Tim Wessman How do I decompose a list with the HP Prime. Hal Bitton in Boise 4 907 11-08-2013, 02:07 PM Last Post: Patrice Shutdown with the Apps key and more than 10 variables in a program. Davi Ribeiro de Oliveira 10 1,763 11-05-2013, 01:26 PM Last Post: Han HP-Prime/Xcas: vector/list indexing fhub 6 1,237 10-27-2013, 04:52 PM Last Post: fhub Proper location for files on the PC for Connectivity Kit ,etc. Harold A Climer 8 1,426 10-23-2013, 02:43 AM Last Post: Marcus von Cube, Germany HHC 2013 RPN Programming Challenge - Final Thought Jeff O. 7 1,246 10-17-2013, 11:02 AM Last Post: Jeff O. PRIME Lockup after pressing Enter key in Solver. Harold A Climer 13 1,890 10-14-2013, 12:05 PM Last Post: Tim Wessman

Forum Jump: