The Museum of HP Calculators

HP Forum Archive 17

[ Return to Index | Top of Index ]

The trigonometric bug is spreading !?
Message #1 Posted by Lyuka on 31 Aug 2007, 6:25 a.m.

One of the hp calculator dealer informed me about the calculation results of cos(1.57079632) on varius calculators.

Quote:
hp 50g:   6.79489661923e-9
hp 48gII: 6.79489661923e-9
hp 39gs:  6.79489661923e-9
hp 9g:    6.794896619e-9
hp 35s:   6.79489e-9
hp 33s:   6.79489e-9
hp 30s:   6.794896619e-9
hp 10s:   6.794897343e-9
hp 9s:    6.79489e-9
hp 8s:    6.795e-9

Some calculation results on the calculators at hand.

hp 50g:   6.794899661923e-9
hp 35s:   6.79489e-9
hp 32sII: 6.79489661923e-9
hp 15C:   6.795000000e-9

The new calculators except the graphing model may be getting to be hopeless. That's too bad.

      
Re: The trigonometric bug is spreading !?
Message #2 Posted by hugh steers on 31 Aug 2007, 8:26 a.m.,
in response to message #1 by Lyuka

looks like all the new models that are't emulating the old code are in trouble here - oops!

lyuka has shown some good trig implementation from scratch, but it got me wondering if there's a way to "patch up" the existing stuff by transforming the input to part of the domain that doesnt suffer the defects, eg half or double angle formulae or somesuch?

      
Re: The trigonometric bug is spreading !?
Message #3 Posted by Peter Niessen on 31 Aug 2007, 10:28 a.m.,
in response to message #1 by Lyuka

Quote:

cos(1.57079632)

Some calculation results on the calculators at hand.

hp 35s:   6.79489e-9
hp 32sII: 6.79489661923e-9


Quite natural. Since the quoted value 1.57079632 is 6.8e-9 away from pi/2 (or HPs representation of it), and since there

cos (pi/2 +/- x) ~ -/+ x

I would say everything is fine.

Cheers, Peter.

Edited: 31 Aug 2007, 10:31 a.m.

      
Re: The trigonometric bug is spreading !?
Message #4 Posted by Gerson W. Barbosa on 31 Aug 2007, 12:10 p.m.,
in response to message #1 by Lyuka

Quote:
That's too bad.

Even worse, it appears "Don't tell" is the rule now. (http://www.hpmuseum.org/hp35.htm)

      
Re: The trigonometric bug is spreading !?
Message #5 Posted by John Noble on 31 Aug 2007, 12:19 p.m.,
in response to message #1 by Lyuka

My 12C with Valentin's "Tried & Tricky" trig program yields:

0.000037417 :-)

Values near pi/2 are known to be a problem, though.

Mac OS X's included Calculator.app gives:

0.0000000067948967

XCalc gives:

6.794896e-09

Google Calculator sez:

6.79489671 10-9

They agree to six decimal places, which is good enough for me

      
Re: The trigonometric bug is spreading !?
Message #6 Posted by Hal Bitton in Boise on 31 Aug 2007, 3:00 p.m.,
in response to message #1 by Lyuka

Quote:
Some calculation results on the calculators at hand.

hp 50g: 6.794899661923e-9 hp 35s: 6.79489e-9 hp 32sII: 6.79489661923e-9 hp 15C: 6.795000000e-9


I guess I don't understand why you would not use the full accuracy provided by the calc...on my 15c, 29c, 41cx, 67 and 34c, if I key pi, then divide by 2, then take the cos, I get -205.00e-12, which is much closer to zero. I get the results you posted if I truncate pi/2 to 8 decimal places, but I don't understand why you do that and then evaluate the resultant lack of accuracy.
Best regards, Hal
            
Re: The trigonometric bug is spreading !? -> BCD arith. with Python
Message #7 Posted by Alain Mellan on 31 Aug 2007, 3:24 p.m.,
in response to message #6 by Hal Bitton in Boise

This discussion reminded me that some time ago I toyed with Python and its 'decimal' library, which implements, well, true decimal arithmetic (after IBM's BCD library).

I have the beginning of an RPL interpreter (just basic arithmetic, SIN/COS/TAN and few stack functions), but it's fun to play with. The default precision is 28 digits.

Anbody interested, send me an email, I'll email back the code.

            
Re: The trigonometric bug is spreading !?
Message #8 Posted by Lyuka on 31 Aug 2007, 4:34 p.m.,
in response to message #6 by Hal Bitton in Boise

I'm not talking about cos(pi/2) but cos(1.57079632000) which should be 6.79489661923e-9 in 12 digits accuracy.

35s's builtin trigonometric functions tend to lose its accuracy around pi/2 and so on, however, it shows accurate result for the value just next to pi/2 as follows.

  cos(1.57079632679)= 4.89661923132e-12
  cos(1.57079632680)=-5.10338076868e-12
it seems strange to me.

regards,

Lyuka

Edited: 31 Aug 2007, 4:38 p.m.

                  
Re: The trigonometric bug is spreading !?
Message #9 Posted by Eric Smith on 31 Aug 2007, 7:04 p.m.,
in response to message #8 by Lyuka

Transcendental functions are very difficult to get right. HP has had errors in them in nearly every generation of their calculator math routines.

1st gen: HP-35 log/exp bug

2nd gen: HP-67/97 arcsin/arccos bug (also in early 19C/29C, not sure about 91)

3rd gen: HP-41C sin/cos of small angles bug

The bugs in the 67/97 and 41C trig crept in even though the algorithms by that time were well-understood. That was back when HP's calculator division had a large number of engineers and mathematicians on staff. Now they have only a few (perhaps only one?), so it is not surprising that recent HP calculators have more bugs. The high-end calculators such as the 49G+ and 50G use flash memory to facilitate firmware upgrades for bug fixes, but the current low-cost calculators (e.g. 33s, 35s) use masked ROM to reduce the manufacturing cost. It would not take very many product recalls of masked-ROM calculators for HP management to realize that the use of masked ROM may be a false economy.

Many people don't realize that even something as seemingly simple as argument range reduction can introduce large errors if it is done in a naive manner.

The best survey I've found of algorithms for elementary functions is Elementary Functions: Algorithms and Implementation by Jean-Michel Muller. The book gives detailed explanations of polynomial and rational approximations, shift-and-add algorithms (e.g., CORDIC), range reduction, correct rounding, etc.

      
Re: The trigonometric bug is spreading !?
Message #10 Posted by Jesse Dodd on 1 Sept 2007, 1:28 a.m.,
in response to message #1 by Lyuka

It appears that the HP calculator dealer may have given you some incomplete information. The hp 9g and the much maligned hp 30s calculates the cos(1.57079632) to 6.794896619231321e-9. This is the correct answer to 16 significant figures making these the most accurate calculators to bear the HP logo.

            
HP-30S and HP-9S accuracy
Message #11 Posted by Karl Schneider on 1 Sept 2007, 2:16 a.m.,
in response to message #10 by Jesse Dodd

Quote:
The hp 9g and the much maligned hp 30s calculates the cos(1.57079632) to 6.794896619231321e-9. This is the correct answer to 16 significant figures making these the most accurate calculators to bear the HP logo.

These models are able to do that because they use 80-bit extended-precision floating-point representations (good for 24 digits), not 12-digit binary-coded decimal (BCD). However, the number of correct digits in the result can vary, and these models will also round values extremely close to an integer to that integer, negating the extra accuracy in the interest of eliminating possible floating-point errors.

Try this: Enter pi using the marked button on an HP-30S, then reveal digits by subtracting the integer portion and multiplying by 10. You'll keep getting digits, but after a while, they'll be essentially random...

I'd rather get only 12 digits that I know I can trust.

-- KS

            
Re: The trigonometric bug is spreading !?
Message #12 Posted by Rodger Rosenbaum on 1 Sept 2007, 4:56 a.m.,
in response to message #10 by Jesse Dodd

Quote:
It appears that the HP calculator dealer may have given you some incomplete information. The hp 9g and the much maligned hp 30s calculates the cos(1.57079632) to 6.794896619231321e-9. This is the correct answer to 16 significant figures making these the most accurate calculators to bear the HP logo.
Exactly what did you do to get this result?

I don't get this on my HP30S. If I type:

COS(1.57079632)*1E17-679489661 ENTER

I get .923035657 which is the result with the leading digits 679489661 missing.

So the actual result of COS(1.57079632) is:

6.79489661923035657E-9, only 12 accurate digits.

                  
Re: The trigonometric bug is spreading !?
Message #13 Posted by Jesse Dodd on 1 Sept 2007, 1:37 p.m.,
in response to message #12 by Rodger Rosenbaum

Quote:
Exactly what did you do to get this result? I don't get this on my HP30S. If I type: COS(1.57079632)*1E17-679489661 ENTER I get .923035657 which is the result with the leading digits 679489661 missing. So the actual result of COS(1.57079632) is: 6.79489661923035657E-9, only 12 accurate digits.

It appears that your getting a rounding error by multipyling by 10e17. If you instead type:

COS(1.57079632)*1E5*1E5*1E7-679489661

You will get the result of .92313212

This gives the correct answer to 16 significant figures

Quote:
I'd rather get only 12 digits that I know I can trust.

This is a valid concern, and yes the 9g and 30s calculate in binary --not that there's anything wrong with that : ) -- but it does not change the fact that these cheap chinese machines are more accurate than the hp 50g.

                        
Accuracy and calculating in binary
Message #14 Posted by Karl Schneider on 1 Sept 2007, 3:27 p.m.,
in response to message #13 by Jesse Dodd

Quote:
...the 9g and 30s calculate in binary --not that there's anything wrong with that -- but it does not change the fact that these cheap chinese machines are more accurate than the hp 50g.

"Accurate" in that they can carry more digits (up to 24), but the user never knows how many can be trusted, so what's the point?

Exceprts from the following link illustrates some pitfalls of floating-point math. It's definitely faster than BCD, but that advantage is best suited for computer programs.

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv009.cgi?read=24977

"...but try this in Excel: enter the equation =100-99.99-0.01 into a cell and hit Enter. Instead of ZERO, you should see 5.1156995306556E-15 ... As you can imagine, this can ruin a perfectly good test for ZERO..."

"Your "100-99.99-0.01" example shows exactly why HP and other calculators use BCD floating-point math and not binary floating-point math. It is also why many financial software packages use BCD math, and why BCD math libraries are available for some compilers (and BCD support is built into COBOL, for example).

Negative powers of 10 (.1, .01, .001...) are not exactly representable as a finite series of binary digits and are in fact the binary equivalent of 'repeating decimals' (like 1/3=0.33333333333...) "

BTW, I got your result, even with multiplying by 1E17 instead of 1E5*1E5*1E7. Rodger may have made a mistake. Still, either way should always produce the same result in an accurate calculator.

-- KS

                              
Re: Accuracy and calculating in binary
Message #15 Posted by Rodger Rosenbaum on 1 Sept 2007, 4:23 p.m.,
in response to message #14 by Karl Schneider

Quote:
BTW, I got your result, even with multiplying by 1E17 instead of 1E5*1E5*1E7. Rodger may have made a mistake. Still, either way should always produce the same result in an accurate calculator.

-- KS


This is very strange. I typed in, very carefully:

COS(1.57079632)*1E5*1E5*1E7-679489661

and I see in the display:

.923035657

I made sure the calculator is in radians mode. Can anyone think of a setting that might make this difference? Is it possible that a later version of the HP30S came out with improved firmware?

The serial number of my unit is CN0019.

                                    
Re: Accuracy and calculating in binary
Message #16 Posted by Jesse Dodd on 1 Sept 2007, 6:33 p.m.,
in response to message #15 by Rodger Rosenbaum

my 30s serial number is:

CNA 63400675. Purchased June of this year from hp.

                              
Re: Accuracy and calculating in binary
Message #17 Posted by Rodger Rosenbaum on 1 Sept 2007, 4:46 p.m.,
in response to message #14 by Karl Schneider

Karl,

There was a thread: http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv009.cgi?read=24977

a while ago where we were playing around with the HP30S, and after your discussion of digit-revealing, I said:

Quote:
I wonder why you got the decimal digits corresponding to a 77 bit approximation to PI, and I got those for a 70 bit approximation. What I did to "retrieve pi" was to press the PI button just to the left of the "enter" button. That was my starting number for the process. Did you do something different?

Quote:The digit-revealing procedure after computing e^(1) on the HP-30S produces 2.7182 8182 8459 0452 018...

If I carry the process further, I get: 2.7182 8182 8459 0452 0181 7900 7609... which is the correct decimal re-conversion of a properly rounded 55-bit representation of e. Don't ask me why 55 bits instead of 80 bits. Or why the 77 bits and 70 bits for PI above. I've noticed this behavior before when investigating the internals of the HP30S.


I think there may indeed be more than one firmware in the HP30S. I must have a very early one. This could explain the different results we got in the earlier thread.

                                    
HP-30S threads?
Message #18 Posted by Karl Schneider on 1 Sept 2007, 11:30 p.m.,
in response to message #17 by Rodger Rosenbaum

Roger --

I remember that discussion, but it's not in the thread from 2002 that you posted. I thought I had bookmarks to the HP-30S threads.

BTW, my HP-30S has a serial # of CN0303.

-- KS

                                          
Re: HP-30S threads?
Message #19 Posted by Rodger Rosenbaum on 2 Sept 2007, 1:48 a.m.,
in response to message #18 by Karl Schneider

Boy, I don't know how that URL got FUBAR'd.

Try:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv016.cgi?read=103499#103499

Jesse, would you try the digit-revealing process Karl described in the above thread, and see if you get what Karl got, or what I got.

I think we have discovered a change in firmware for the HP30S.

                                                
Re: HP-30S threads?
Message #20 Posted by Jesse Dodd on 2 Sept 2007, 2:43 a.m.,
in response to message #19 by Rodger Rosenbaum

Quote:
Jesse, would you try the digit-revealing process Karl described in the above thread, and see if you get what Karl got, or what I got.

I got the same results with my 30s that Karl got.

3.14159....264 8727

                              
Re: Accuracy and calculating in binary
Message #21 Posted by Jesse Dodd on 1 Sept 2007, 5:49 p.m.,
in response to message #14 by Karl Schneider

Quote:
"Accurate" in that they can carry more digits (up to 24), but the user never knows how many can be trusted, so what's the point?

I really agree with you, but I enjoy playing devils advocate because the best part about these forums is they make people think. All good calculators have guard digits beyond the digits that can be displayed. These guard digits can produce non-zero (but very close to zero) errors similar to the Excel example you showed even with BCD, because not all decimal numbers can be represented exactly. In the original post on this thread Lyuka was lamenting the fact that the hp 33s and hp 35s were not accurate in the displayed digits, and as you pointed out, this is a well know and uncorrected bug with these models. But at the end of the post he noted that:

"The new calculators except the graphing model may be getting to be hopeless."

Since the numbers he presented showed fewer digits for the 9g and 30s I assumed that he meant these (newer) machines were less accurate. I now realize that this is the total number of digits that these machines will display. I think the hp 9g and hp 30s use twenty-four digits internally to make sure that the displayed digits are always accurate. If you want to set an arbitrary limit of, say, 13 significant digits, then the 30s will be more accurate than the 50g and you don't have to worry about any digits that appear after the 13th. Using the popular calculator forensic test of

Arcsin(Arccos(Arctan(tan(cos(sin(9 degrees)))))),

the 9g and 30s are two of the very few calculators that return an exact answer of 9. I assume that the reason that they do so is because of the 24 digit internal calculations. Of course 13 digit accuracy is mostly academic because, for example, you can calculate the earths orbit to within a single meter with 13 digits and this is far more accurate that the actual measured values.

                                    
HP-30S accuracy?
Message #22 Posted by Karl Schneider on 1 Sept 2007, 11:45 p.m.,
in response to message #21 by Jesse Dodd

Quote:
Using the popular calculator forensic test of

Arcsin(Arccos(Arctan(tan(cos(sin(9 degrees)))))),

the 9g and 30s are two of the very few calculators that return an exact answer of 9. I assume that the reason that they do so is because of the 24 digit internal calculations.


I consider the forensic to be quite overrated in its actual value. The "perfect" results HP-30S were discussed in a thread several years ago that I didn't bookmark. The HP-30S' performance is also attributable to its rounding of values extremely close to an integer to that integer. This helps to eliminate the floating-point computational errors, but can also provide results that are not strictly correct.

Please try a few of the "sin(pi - x)" and "cos(pi/2 - x)" calculations I tabulated, using your HP-30S. Enter enough digits of the input argument, and the result will always be zero, instead of the correct "missing digits" result.

-- KS

                                    
Re: Accuracy and calculating in binary
Message #23 Posted by Rodger Rosenbaum on 2 Sept 2007, 1:52 a.m.,
in response to message #21 by Jesse Dodd

Jesse,

Have a look at:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=85973#85973

                                          
Re: Accuracy and calculating in binary
Message #24 Posted by Jesse Dodd on 2 Sept 2007, 3:33 a.m.,
in response to message #23 by Rodger Rosenbaum

Quote:
Please try a few of the "sin(pi - x)" and "cos(pi/2 - x)" calculations I tabulated, using your HP-30S. Enter enough digits of the input argument, and the result will always be zero, instead of the correct "missing digits" result.

I did as you suggested and entered sin(3.14159265358) into the 30s and obtained the incorrect value of 0. Because I didn't read the posts from 2006, I never knew that the 30s played this slight of hand with near integers. Interestingly, the 9g give the correct answer to sin(3.14159265358) even though I thought that it used the same algorithms as the 30s.

Just out of curiosity I tried

arcsin(arccos(arctan(tan(cos(sin(8.999999999 deg))))) and arcsin(arccos(arctan(tan(cos(sin(9.000000001 deg)))))

on the 9g and both answers were accurate to 18 figures as opposed to 12 on the 30s.

                                                
Re: Accuracy and calculating in binary
Message #25 Posted by DaveJ on 2 Sept 2007, 8:47 a.m.,
in response to message #24 by Jesse Dodd

Quote:

I did as you suggested and entered sin(3.14159265358) into the 30s and obtained the incorrect value of 0. Because I didn't read the posts from 2006, I never knew that the 30s played this slight of hand with near integers. Interestingly, the 9g give the correct answer to sin(3.14159265358) even though I thought that it used the same algorithms as the 30s.


For sin(3.14159265358) on my Casio FX-992s I get 9.8e-12, but I get 0 if I use the inbuilt PI function.

Dave.

                                                
Re: Accuracy and calculating in binary
Message #26 Posted by Rodger Rosenbaum on 6 Sept 2007, 12:28 a.m.,
in response to message #24 by Jesse Dodd

Well, I went out and bought another HP30S.

My old unit has a serial no. of CN0019 and the new one has a serial of CN0143 .

The new one behaves differently. I get the same result as Karl and Jesse on the various tests we've been discussing.

I notice that on the old one, SIN(3.14159265358) returns 9.793238461E-12, whereas the new unit returns exactly zero.

I experimented around and found that they have done some more of that "purification" of certain results.

The HP30S can only accept 13 digits as keyboard input, so to perform calculations on 24 digit inputs, one must do arithmetic in the input string.

So, if I type:

sin(3.1415926535+7391741495627E-23)*1E17-1587582 enter

I get:

.3506383

which is more or less consistent with internal 80 bit (24 decimal digit) arithmetic.

But, if I type:

sin(3.1415926535+7391741495628E-23) enter

I get exactly zero. So, if you get close enough to PI on input, they return a result as if the input was exactly PI. The older unit doesn't do this for this particular calculation.

Also, I notice that the new unit returns a correct 24 digit square root. Joe Horn had noticed that the HP30S didn't return a result accurate to 24 digits when the calc was first released, but that has been fixed now.

So, the firmware has definitely been changed since the initial introduction of the HP30S. Whether it's an improvement or not depends on your point of view.

      
HP-33s/35s trigonometric bug tabulated
Message #27 Posted by Karl Schneider on 1 Sept 2007, 1:58 a.m.,
in response to message #1 by Lyuka

As you correctly point out in a subsequent post in this thread,

cosine of 1.57079632000 radians is 6.79489661923e-9 with 12 digits of accuracy.

This is easy to show:

cos (y - x) = cos(y)*cos(x) + sin(y)*sin(x)

So,

cos (pi/2 - x) = cos(pi/2)*cos(x) + sin(pi/2)*sin(x)

= 0 * cos(x) + 1 * sin(x)

= sin(x)

Let x represent the "missing" digits of pi/2. The calculation of cosine (pi/2 - x) in radians will yield sine (x), which will be extremely close to x for very small values of x. Hence, cosine "fills in" the missing digits of pi/2.

This calculation is very similar to sin (pi - x) for small x, where sine "fills in" the missing digits of pi. I've discussed that one a few times as a good example of the algorithmic accuracy introduced with the Saturn processor for 1984 in the HP-71B.

Here's a discussion of the "cosine bug" in the HP-33s and HP-35s, in which the accuracy of cosine for arguments near 90 degrees is erratic -- losing significant digits one by one as the input gets closer to 90 (e.g., 89.9999), then suddenly becoming more accurate as x gets to almost 90 degrees:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv016.cgi?read=103989#103989

(See Bill Platt's post -- message #14 in that thread.)

Given those findings, it's reasonable that the calculation of cosine in radians mode also loses significant digits on these models as the argument nears zero, because an argument in degrees must be converted to radians. There's definitely a flaw in the algorithm; it seems to be terminating prematurely in some cases.

HP calculators with pre-Saturn microprocessors (e.g., HP-15C) and many modern calculators from other manufacturers (e.g, TI-82) sometimes give only two significant digits for the sine and cosine calculations described. I suspect that they calculate out to their internal precision of three guard digits, round the answer to the second guard digit and "call it good", without recognizing that even more digits could be calculated due to the small magnitude of the result. Example:

       input    |guard|  extra
                \     /   
sin 3.14159265358|000|
=   0.00000000000|979|323846264
                 |   |

On any Pioneer-series model and some descendants, you get 9.79323846264e-12 as the result. On some newer 12-digit non-HP's, you might get 9.8e-12 as the result.

Here's a table of results for sin(pi - x) and cos(pi/2 - x) in radians:

pi - x                      sin(pi - x)  ~= x
                      HP-32SII          HP-33s/HP-35s     ULP error

3.1 4.15806624333E-02 4.15806624333E-02 0 3.14 1.59265291649E-03 1.59265291648E-03 1 3.141 5.92653555099E-04 5.92653555096E-04 3 3.1415 9.26535896607E-05 9.26535896582E-05 25 3.14159 2.65358979324E-06 2.65358979000E-06 324 3.141592 6.53589793238E-07 6.53589790000E-07 3238 3.1415926 5.35897932384E-08 5.35897900000E-08 32384 3.14159265 3.58979323846E-09 3.58979000000E-09 323846 3.141592653 5.89793238463E-10 5.89793238463E-10 0 3.1415926535 8.97932384626E-11 8.97932384626E-11 0 3.14159265358 9.79323846264E-12 9.79323846264E-12 0

pi/2 - x cos(pi/2 - x) ~= x HP-32SII HP-33s/HP-35s ULP error

1.5 7.07372016677E-02 7.07372016677E-02 0 1.57 7.96326710733E-04 7.96326710728E-04 5 1.570 7.96326710733E-04 7.96326710728E-04 5 1.5707 9.63267947477E-05 9.63267947464E-05 13 1.57079 6.32679489658E-06 6.32679488998E-06 660 1.570796 3.26794896619E-07 3.26794890000E-07 6619 1.5707963 2.67948966192E-08 2.67948900000E-08 66192 1.57079632 6.79489661923E-09 6.79489000000E-09 661923 1.570796326 7.94896619231E-10 7.94896619231E-10 0 1.5707963267 9.48966192313E-11 9.48966192313E-11 0 1.57079632679 4.89661923132E-12 4.89661923132E-12 0

The patterns are remarkably similar: As the number of digits in the input increases, small errors in the lowest-order digits of the results occur and grow, then significant digits are lost, then finally the answers become correct.

Note that, for each result of less than 12 significant digits, the input and result combine for 15 digits that are not trailing zeroes. This probably stems from the 12 digits of the returned result and the three guard digits.

-- KS

Edited: 7 Sept 2007, 12:54 a.m. after one or more responses were posted

            
Re: The trigonometric bug is spreading !?
Message #28 Posted by gteague on 1 Sept 2007, 3:08 a.m.,
in response to message #27 by Karl Schneider

hey! i thought we'd all agreed, no math on the calc forum. (and no fighting in the warroom)

[g]

seriously, what keystrokes are you guys using? i'm not afraid to ask stupid questions.

< edited for idiocy ... someone snuck around and set all my calculator to degrees mode. hey, no one until karl mentioned radians ... move along ... nothing to see here ... >

/guy

Edited: 1 Sept 2007, 3:15 a.m.

      
Re: The trigonometric bug is spreading !?
Message #29 Posted by Garth Wilson on 6 Sept 2007, 2:21 a.m.,
in response to message #1 by Lyuka

Quote:
One of the hp calculator dealer informed me about the calculation results of cos(1.57079632) on varius calculators.

<snip>

The new calculators except the graphing model may be getting to be hopeless. That's too bad.


It's not reasonable to want the same number of significant figures for everything, so there's no need to blame the calculator. As long as you're not putting a bunch of zeroes after the 1.57079632 input number, in real-life practical use you are saying the input could be anywhere from 1.570796315 to 1.570796325, so correct outputs of that range could go all the way from about 1.79E-9 to 1.18E-8, a ratio of more than 6:1. It's not hopeless, but rather the nature of the function. So if COS(1.57079632) gives you something around 7E-9 (yes, one significant digit), that's as good as you're going to get, regardless of how many digits the calculator has. Try it. My HP-71 says ACOS(5E-9)=1.57079632179 and ACOS(6E-9)=1.57079632079. From a 20% change in input, the output stays the same for the first 9 digits, 1.57079632. If you want 12 digits of the COS, how many digits does that correspond to in the angle in this part of the circle? Maybe 40? (That's only a wild guess. I don't have an easy way to find out, so I'll leave it for someone else who has the computational resources.)

Edited: 6 Sept 2007, 2:26 a.m.

            
Re: The trigonometric bug is spreading !?
Message #30 Posted by Lyuka on 6 Sept 2007, 8:27 a.m.,
in response to message #29 by Garth Wilson

As far as it's specified, the accuracy itself is not a problem. But the lack of quality-control to pass through such kind of trivial bugs, which make me feel it's not reliable, at least as a tool for professionals.

regards, Lyuka

            
Re: The trigonometric bug is spreading !?
Message #31 Posted by Karl Schneider on 6 Sept 2007, 11:47 p.m.,
in response to message #29 by Garth Wilson

Hi, Garth --

Quote:
It's not reasonable to want the same number of significant figures for everything...

And just why not?? :-)

Seriously, an obvious design objective of the Saturn-processor mathematics microcode was to provide a result correct to 12 significant digits with three-digit exponent for every transcedental function, using any valid input argument. As far as I know, that objective was met -- not considering any bugs that might have been present in the earliest versions (e.g., HP-71B). Clearly, that objective has not been fully met for the HP-33s and HP-35s.

Granted, it is usually quite difficult to put 12 significant digits to effective practical use in "real-world" physical applications. However, it's all about the mathematics.

Quote:
As long as you're not putting a bunch of zeroes after the 1.57079632 input number, in real-life practical use you are saying the input could be anywhere from 1.570796315 to 1.570796325, so correct outputs of that range could go all the way from about 1.79E-9 to 1.18E-8, a ratio of more than 6:1.

How many significant digits the user intends or claims for the input is not considered by the calculator (with the notable exception of integrand-function uncertainty for numerical integration). The calculator treats each input argument as an exact value to its supported number of significant digits -- 10 or 12 for most HP's. 1.57079632 is treated as 1.57079632000 by any Pioneer-series or RPL-based model, HP-71B, HP-75, HP-33s or HP-35s.

The user may select a display specification that rounds the result to the justified number of significant digits, but the calculation is always "full rank", to borrow a term from linear algebra.

(Come to think of it, your example suggests a good application for "FIX/SCI/ENG I" and "delta-%" in a short RPN program: Accept a value and a number of decimal digits as input to a programmed function, then calculate the percentage difference between the extrema of possible output values for the display setting.)

The results for cos(pi/2 - x) for very small x are nearly zero, so a ratio of two close values can be very large indeed. Also,
|d(cos y)/dy| and |d(sec y)/dy| are at maximum for y near pi/2, so the results are sensitive to small changes in y and must be used with care. That's the user's responsibility, not the calculator's...

-- KS

Edited: 14 Sept 2007, 12:36 a.m. after one or more responses were posted

                  
Re: The trigonometric bug is spreading !?
Message #32 Posted by Garth Wilson on 7 Sept 2007, 2:15 a.m.,
in response to message #31 by Karl Schneider

Quote:
However, it's all about the mathematics.
Mathematics is not an end in itself. Its value only extends to its application in real-world engineering, finance, etc.. I fear that math teachers forget that, getting too fascinated with math for math's sake.

If you take the COS of a number A near PI/2 that has 12 significant figures and get an answer B with only 2 significant figures correct, and then take the ACOS of B and get the original input A back again with all 12 significant figures identical, you must consider further digits in the intermediate answer to be unimportant, maybe even dangerous. Otherwise, your gizmo design can run into trouble because an uncontrollably small variation in input will mean a very low yield in production, or maybe great expense or even human deaths in the field. The concept cannot be sterilized for math enthusiasts. It's all about the application.

Being a circuit designer, I'm much, much stronger in math than most technicians, mechanics, etc.; but I'm not a mathematician like some of you guys are. I have however seen, too many times, where for example someone depended on certain precision for their design, only to forget that temperature variations in the field would throw that precision out the window and result in a constant string of expensive malfunctions in the field. In that one, I was given the job of redesigning the product. I looked over what had been done and saw the many things that all had to be accurate for the thing to work, and then took an entirely different design approach. With thousands of the new units in the field for the last 18 months, there have been zero reports of malfunction.

Slide rules had a precision limitation that was a big problem for some applications; but the slide rule did graphically illustrate the comparative value of various operations' precisions. What finally lured me away from the slide rule to the calculator was that I needed something programmable.

                        
Says who ?
Message #33 Posted by Valentin Albillo on 7 Sept 2007, 4:12 a.m.,
in response to message #32 by Garth Wilson

Hi, Garth:

Garth posted [the underlining is mine]:

    "Mathematics is not an end in itself. Its value only extends to its application in real-world engineering, finance, etc.."

      ROTFL ! Good joke. Try another, you seem pretty inspired today.

Best regards from V.

                        
Re: The trigonometric bug is spreading !?
Message #34 Posted by DaveJ on 7 Sept 2007, 4:57 a.m.,
in response to message #32 by Garth Wilson

Quote:
Mathematics is not an end in itself. Its value only extends to its application in real-world engineering, finance, etc.. I fear that math teachers forget that, getting too fascinated with math for math's sake.

Calculators are not an end in themselves, their value only extends to their application in real-world engineering, finance etc. I fear that calculator enthusiasts forget that, getting too fascinated with calculators for the sake of calculators!

Hence this forum should close immediately, there is no purpose to it!

:-)

Dave.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall