▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
[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
▼
Posts: 275
Threads: 41
Joined: Mar 2010
it's 2.000000000 ;)
for a working unit
Edited: 28 Sept 2011, 4:15 p.m.
Posts: 163
Threads: 7
Joined: Jul 2007
On a 10digit 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
Posts: 225
Threads: 9
Joined: Jul 2008
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.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 225
Threads: 9
Joined: Jul 2008
Wow! I did not know about those options. I never cease to be amazed by what the WP34S can do.
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 260
Threads: 0
Joined: Oct 2008
Hello,
I don't know any things about internal mecanics of the calculators.
What really surprise me is that I get on my old 10digits HP41C 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 roundoff 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 10digits calculator is 1.333...; It is the same for 12 14 24 500digits calculators.
Edited: 30 Sept 2011, 4:40 p.m. after one or more responses were posted
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 10digit result. ;)
Dieter
Edited: 30 Sept 2011, 9:06 a.m.
▼
Posts: 349
Threads: 66
Joined: Apr 2007
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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 10digit 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 10digit 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.
