[edited] from the HHC email list, what is the proper answer to 8 ENTER 3 divide 2 divide on 10 digit calc



#2

[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


#3

it's 2.000000000 ;)

for a working unit


Edited: 28 Sept 2011, 4:15 p.m.

#4

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

#5

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.


#6

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


#7

Wow! I did not know about those options. I never cease to be amazed by what the WP34S can do.

#8

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


#9

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


#10

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.


#11

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


#12

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 4,327 12-05-2013, 02:44 PM
Last Post: James Williams
  HP-Prime : Extracting elements from a list in RPN Miguel Toro 0 1,630 11-15-2013, 06:44 PM
Last Post: Miguel Toro
  [HP-Prime] Picking elements from a List in a program Jean-Michel 3 2,031 11-15-2013, 04:16 AM
Last Post: dg1969
  Hp PRIME - how to send a list to the connectivity Kit giancarlo 1 1,349 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 2,066 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 3,928 11-05-2013, 01:26 PM
Last Post: Han
  HP-Prime/Xcas: vector/list indexing fhub 6 2,945 10-27-2013, 04:52 PM
Last Post: fhub
  Proper location for files on the PC for Connectivity Kit ,etc. Harold A Climer 8 2,909 10-23-2013, 02:43 AM
Last Post: Marcus von Cube, Germany
  HHC 2013 RPN Programming Challenge - Final Thought Jeff O. 7 2,428 10-17-2013, 11:02 AM
Last Post: Jeff O.
  PRIME Lockup after pressing Enter key in Solver. Harold A Climer 13 3,875 10-14-2013, 12:05 PM
Last Post: Tim Wessman

Forum Jump: