▼
Posts: 169
Threads: 12
Joined: Aug 2007
One of the hp calculator dealer informed me about the calculation results of cos(1.57079632) on varius calculators.
Quote:
hp 50g: 6.79489661923e9
hp 48gII: 6.79489661923e9
hp 39gs: 6.79489661923e9
hp 9g: 6.794896619e9
hp 35s: 6.79489e9
hp 33s: 6.79489e9
hp 30s: 6.794896619e9
hp 10s: 6.794897343e9
hp 9s: 6.79489e9
hp 8s: 6.795e9
Some calculation results on the calculators at hand.
hp 50g: 6.794899661923e9
hp 35s: 6.79489e9
hp 32sII: 6.79489661923e9
hp 15C: 6.795000000e9
The new calculators except the graphing model may be getting to be hopeless. That's too bad.
▼
Posts: 536
Threads: 56
Joined: Jul 2005
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?
Posts: 26
Threads: 9
Joined: Aug 2007
Quote:
cos(1.57079632)
Some calculation results on the calculators at hand.
hp 35s: 6.79489e9
hp 32sII: 6.79489661923e9
Quite natural. Since the quoted value 1.57079632 is 6.8e9 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.
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
That's too bad.
Even worse, it appears "Don't tell" is the rule now. (http://www.hpmuseum.org/hp35.htm)
Posts: 56
Threads: 1
Joined: Jan 2007
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.794896e09
Google Calculator sez:
6.79489671 × 109
They agree to six decimal places, which is good enough for me
Posts: 291
Threads: 43
Joined: Jun 2007
Quote:
Some calculation results on the calculators at hand.
hp 50g: 6.794899661923e9
hp 35s: 6.79489e9
hp 32sII: 6.79489661923e9
hp 15C: 6.795000000e9
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.00e12, 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
▼
Posts: 55
Threads: 5
Joined: Jul 2007
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.
Posts: 169
Threads: 12
Joined: Aug 2007
I'm not talking about cos(pi/2) but cos(1.57079632000) which should be
6.79489661923e9 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.89661923132e12
cos(1.57079632680)=5.10338076868e12
it seems strange to me.
regards,
Lyuka
Edited: 31 Aug 2007, 4:38 p.m.
▼
Posts: 2,309
Threads: 116
Joined: Jun 2005
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: HP35 log/exp bug
2nd gen: HP67/97 arcsin/arccos bug (also in early 19C/29C, not sure about 91)
3rd gen: HP41C 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 wellunderstood. 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 highend calculators such as the 49G+ and 50G use flash memory to facilitate firmware upgrades for bug fixes, but the current lowcost calculators (e.g. 33s, 35s) use masked ROM to reduce the manufacturing cost. It would not take very many product recalls of maskedROM 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 JeanMichel Muller. The book gives detailed explanations of polynomial and rational approximations, shiftandadd algorithms (e.g., CORDIC), range reduction, correct rounding, etc.
Posts: 18
Threads: 1
Joined: Sep 2007
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.794896619231321e9. This is the correct answer to 16 significant figures making these the most accurate calculators to bear the HP logo.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
The hp 9g and the much maligned hp 30s calculates the cos(1.57079632) to 6.794896619231321e9. 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 80bit extendedprecision floatingpoint representations (good for 24 digits), not 12digit binarycoded 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 floatingpoint errors.
Try this: Enter pi using the marked button on an HP30S, 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
Posts: 305
Threads: 17
Joined: Jun 2007
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.794896619231321e9. 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)*1E17679489661 ENTER
I get .923035657 which is the result with the leading digits 679489661 missing.
So the actual result of COS(1.57079632) is:
6.79489661923035657E9, only 12 accurate digits.
▼
Posts: 18
Threads: 1
Joined: Sep 2007
Quote:
Exactly what did you do to get this result?
I don't get this on my HP30S. If I type:
COS(1.57079632)*1E17679489661 ENTER
I get .923035657 which is the result with the leading digits 679489661 missing.
So the actual result of COS(1.57079632) is:
6.79489661923035657E9, 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*1E7679489661
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.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 floatingpoint math. It's definitely faster than BCD, but that advantage is best suited for computer programs.
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv009.cgi?read=24977
"...but try this in Excel: enter the equation =10099.990.01 into a cell and hit Enter. Instead of ZERO, you should see 5.1156995306556E15 ... As you can imagine, this can ruin a perfectly good test for ZERO..."
"Your "10099.990.01" example shows exactly why HP and other calculators use BCD floatingpoint math and not binary floatingpoint 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
▼
Posts: 305
Threads: 17
Joined: Jun 2007
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*1E7679489661
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.
▼
Posts: 18
Threads: 1
Joined: Sep 2007
my 30s serial number is:
CNA 63400675. Purchased June of this year from hp.
Posts: 305
Threads: 17
Joined: Jun 2007
Karl,
There was a thread:
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv009.cgi?read=24977
a while ago where we were playing around with the HP30S, and after your discussion of digitrevealing, 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 digitrevealing procedure after computing e^(1) on the HP30S 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 reconversion of a properly rounded 55bit 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.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Roger 
I remember that discussion, but it's not in the thread from 2002 that you posted. I thought I had bookmarks to the HP30S threads.
BTW, my HP30S has a serial # of CN0303.
 KS
▼
Posts: 305
Threads: 17
Joined: Jun 2007
Boy, I don't know how that URL got FUBAR'd.
Try:
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv016.cgi?read=103499#103499
Jesse, would you try the digitrevealing 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.
▼
Posts: 18
Threads: 1
Joined: Sep 2007
Quote:
Jesse, would you try the digitrevealing 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
Posts: 18
Threads: 1
Joined: Sep 2007
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 nonzero (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 twentyfour 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.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 HP30S were discussed in a thread several years ago that I didn't bookmark. The HP30S' performance is also attributable to its rounding of values extremely close to an integer to that integer. This helps to eliminate the floatingpoint 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 HP30S. Enter enough digits of the input argument, and the result will always be zero, instead of the correct "missing digits" result.
 KS
Posts: 305
Threads: 17
Joined: Jun 2007
▼
Posts: 18
Threads: 1
Joined: Sep 2007
Quote:
Please try a few of the "sin(pi  x)" and "cos(pi/2  x)" calculations I tabulated, using your HP30S. 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.
▼
Posts: 1,092
Threads: 57
Joined: May 2007
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 FX992s I get 9.8e12, but I get 0 if I use the inbuilt PI function.
Dave.
Posts: 305
Threads: 17
Joined: Jun 2007
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.793238461E12, 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+7391741495627E23)*1E171587582 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+7391741495628E23) 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.
Posts: 1,792
Threads: 62
Joined: Jan 2005
As you correctly point out in a subsequent post in this thread,
cosine of 1.57079632000 radians is 6.79489661923e9 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 HP71B.
Here's a discussion of the "cosine bug" in the HP33s and HP35s, 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/cgisys/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 preSaturn microprocessors (e.g., HP15C) and many modern calculators from other manufacturers (e.g, TI82) 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.14159265358000
= 0.00000000000979323846264
 
On any Pioneerseries model and some descendants, you get 9.79323846264e12 as the result. On some newer 12digit nonHP's, you might get 9.8e12 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
HP32SII HP33s/HP35s ULP error
3.1 4.15806624333E02 4.15806624333E02 0
3.14 1.59265291649E03 1.59265291648E03 1
3.141 5.92653555099E04 5.92653555096E04 3
3.1415 9.26535896607E05 9.26535896582E05 25
3.14159 2.65358979324E06 2.65358979000E06 324
3.141592 6.53589793238E07 6.53589790000E07 3238
3.1415926 5.35897932384E08 5.35897900000E08 32384
3.14159265 3.58979323846E09 3.58979000000E09 323846
3.141592653 5.89793238463E10 5.89793238463E10 0
3.1415926535 8.97932384626E11 8.97932384626E11 0
3.14159265358 9.79323846264E12 9.79323846264E12 0
pi/2  x cos(pi/2  x) ~= x
HP32SII HP33s/HP35s ULP error
1.5 7.07372016677E02 7.07372016677E02 0
1.57 7.96326710733E04 7.96326710728E04 5
1.570 7.96326710733E04 7.96326710728E04 5
1.5707 9.63267947477E05 9.63267947464E05 13
1.57079 6.32679489658E06 6.32679488998E06 660
1.570796 3.26794896619E07 3.26794890000E07 6619
1.5707963 2.67948966192E08 2.67948900000E08 66192
1.57079632 6.79489661923E09 6.79489000000E09 661923
1.570796326 7.94896619231E10 7.94896619231E10 0
1.5707963267 9.48966192313E11 9.48966192313E11 0
1.57079632679 4.89661923132E12 4.89661923132E12 0
The patterns are remarkably similar: As the number of digits in the input increases, small errors in the lowestorder 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
▼
Posts: 21
Threads: 2
Joined: Aug 2007
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.
Posts: 887
Threads: 9
Joined: Jul 2007
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 reallife 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.79E9 to 1.18E8, 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 7E9 (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 HP71 says ACOS(5E9)=1.57079632179 and ACOS(6E9)=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.
▼
Posts: 169
Threads: 12
Joined: Aug 2007
As far as it's specified, the accuracy itself is not a problem.
But the lack of qualitycontrol 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
Posts: 1,792
Threads: 62
Joined: Jan 2005
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 Saturnprocessor mathematics microcode was to provide a result correct to 12 significant digits with threedigit 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., HP71B). Clearly, that objective has not been fully met for the HP33s and HP35s.
Granted, it is usually quite difficult to put 12 significant digits to effective practical use in "realworld" 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 reallife 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.79E9 to 1.18E8, 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 integrandfunction 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 Pioneerseries or RPLbased model, HP71B, HP75, HP33s or HP35s.
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
▼
Posts: 887
Threads: 9
Joined: Jul 2007
Quote:
However, it's all about the mathematics.
Mathematics is not an end in itself. Its value only extends to its application in realworld 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.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Garth:
Garth posted [the underlining is mine]:
"Mathematics is not an end in itself. Its value only extends to its application in realworld engineering, finance, etc.."
ROTFL ! Good joke. Try another, you seem pretty inspired today.
Best regards from V.
Posts: 1,092
Threads: 57
Joined: May 2007
Quote:
Mathematics is not an end in itself. Its value only extends to its application in realworld 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 realworld 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.
