Euler Identity in Home

[orcinus]

(04-05-2014 08:44 PM)ColinJDenman Wrote:  Plain and simple truth (to me): I expect better, not worse after 30 years.

The nature of a bit, floating point math and BCD encoding does not change with the passage of time.
(... and like most math and IT, they're fairly oblivious to one's expectations.)

[ColinJDenman]

(04-05-2014 10:56 PM)orcinus Wrote:  The nature of a bit, floating point math and BCD encoding does not change with the passage of time.
(... and like most math and IT, they're fairly oblivious to one's expectations.)

The nature of the hardware (speed, storage) has changed radically. Increased precision is entirely possible. I don't ask for the impossible, just better. It seems foolish not to place such expectations on manufacturers. Otherwise they'd have little incentive to innovate to satisfy demand.

The Prime so far disapoints me. I paid £120 to get a barely-Beta piece of software kit. I hope my criticism rather than sycophancy promotes more efort to improve it, not to abandon it as is, as "good enough". Such mentality seems rife these days.

[Joe Horn]

(04-05-2014 09:54 PM)ColinJDenman Wrote:  But let us never forget that the correct answer to sin(pi) is zero. Some bits of the Prime know this. Bits that don't, shouldn't be there.

Sorry for beating a dead horse, but you are assuming that Prime's Home mode is even CAPABLE of expressing sin(exact decimal value of pi). But it isn't, because it CAN'T, because NO digital calculator ever made is capable of expressing the exact decimal value of pi. The closest that Prime's Home mode can get is exactly 3.141592653590000000000.... And the CORRECT answer for the sin of THAT is NOT zero, because as you can see, the argument is not pi, but in fact differs from pi in an infinite number of its digits.

You might be thinking, "But I pressed sin(pi), so it should calculate sin(pi)." Wrong. You pressed sin(pi rounded to n decimal places). And that's very different. There is a difference between what you are intending to do, and what you are actually doing.

You say that you like the fact that the HP-65 returns zero for sin(exactly 3.1415926540000000000... radians), and since newer HP models don't return zero, we're going backwards? Ah, but you shouldn't like the HP-65's result, because zero is the wrong answer for THAT. The CORRECT answer for THAT is -4.102067615373566...E-10. So the HP-65 should return it rounded to 10 significant digits, namely, -4.102067615E-10. But it doesn't. The newer models do. So we're not going backwards at all.

[peacecalc]

Hello friends,

interesting discussion. But what is the point? I told my pupils calcs can never calculate exact (okay there are a lot of exceptions) floating point values. If a manufacturer of such a machine decided a very small number like 3.45..E-10 is zero (or 0.99999999992 is one), than this is a decision out of non-numerical reasons and let the user forget, that he has an approximativ results producing machine in his hand.

I think this non-replacing with "integer" numbers on newer calcs is for a reflecting user no problem, because he knows the "real" (sic!) result.

Greetings
peacecalc

[orcinus]

(04-05-2014 11:38 PM)ColinJDenman Wrote:  The nature of the hardware (speed, storage) has changed radically. Increased precision is entirely possible. I don't ask for the impossible, just better.

So you're saying you'd prefer it'd display 3.45E-20 to 3.45E-10 and consider that a valuable application of technological progress?

[jebem]

Thanks, Joe and Peacecalc for your explanations. It makes all the sense.

So, sin(Pi) can be displayed with a result <> Zero because it depends on two factors:
- Internal accuracy (how many digits it can handle for the calculations);
- How close to Zero has a result to be, in order to be displayed as Zero.

Apparently HP has followed a different route for their more recent top models, when comparing the behavior of what CASIO and TI are doing.

If I understand correctly, HP is not adjusting the results to Zero, no matter how small is the value (?), where CASIO and TI are doing that and also they use at least 14 digits of accuracy compared to 12 digits for HP (?).

Please have a look on my tests (on real calculators) below for details:

Calculator, SIN(Pi), SIN(Pi/2), COS(Pi), Remark#
-----------------------------------------------------
HP-65, 0, 1, -1
HP-25, 0, 1, -1
TI-57, 0, 1, -1
Texas TI-51-III, 0, 1, -1
Casio FX-39, 0, 1, -1
Casio FX-5000F, 0, 1, -1
HP-300S+, 0, 1, -1

Texas TI-85, 0, 1, -1, Remark1
Texas TI-89, 0, 1, -1, Remark2

Casio AFX 2.0+, 0, 1, -1, Remark3

HP-48G+, -2.06761537357E-13, 1, -1, Remark4
HP-35S, -2.06761537357E-13, 1, -1
HP-49G+, -2.06761537357E-13, 1, -1, Remark5
HP-48GII, -2.06761537357E-13, 1, -1, Remark5
HP-PRIME, -2.06761537357E-13, 1, -1, Remark6

Remarks:
(1) Texas TI-85: This is not a CAS capable calculator.
"SIN Pi" = 0 all the time, even when we convert the "Pi" value to a number by doing "Pi ENTER", and then "SIN 2nd ANS";
Despite the displayed "Pi" value only having 12 digits, internally it has 14 digits of accuracy;
To prove it, one needs to manually type 12 digits for "Pi" and do a "SIN 3.14159265359" to obtain this time a result of "-2E-13", very close to the recent HP top models result;
As stated in the user guide: Internally "Pi" is a constant = "3.1415926535898" with 14 digits of accuracy, but the calculator displays only up to 12 digits.

(2) Texas TI-89: It computes "sin(Pi)" = 0 all the time, even when we convert the "Pi" to a number by doing "Pi ENTER", and then "sin(2nd ANS)", sporting the 14 digits of accuracy internally;
Contrary to the older TI-85, the TI-89 can also display the "Pi" value with a full 14 digits;
Now, doing a "sin(3.1415926535898)" with 14 digits by manually typing this value for "Pi", we get a result = 0, so there is no symbolic calculation going on here.
And if we just use 12 digits for "Pi" and do a "sin(3.14159265359)" we obtain this time a result of "-2E-13" as with the TI-85, again very close to the recent HP top models result;

3) Casio Algebra FX 2.0 plus: It computes "sin Pi" = 0 in computing mode (non-CAS), even when we convert the "Pi" to a number by doing "Pi ENTER", and then "sin SHIFT Ans";
Also, doing a "sin 3.1415926535898" by manually typing 14 digits for "Pi", we get a result = 0, the same result as obtained for Texas TI-89, so the internal accuracy is at least 14 digits, and there is no symbolic calculation going on here as well.
And if we just use 12 digits for "Pi" and do a "sin 3.14159265359" we obtain this time a result of "-2E-13", again very close to the recent HP top models result.

(4) HP-48G+: Needs to convert "Pi" to a numeric value (with "-> Num"), otherwise it gives "SIN(Pi)" = 0;

(5) HP-49G+, HP-48GII, HP-50G: Needs "CAS Numeric" selected, otherwise it gives "SIN(Pi)" = 0;
Now, if we type "SIN(3.1415926535898) we get a result of 9.79323846264E-12 and the inputted command is just truncated in history to have only 12 digits: "SIN(3.14159265358)".

(6) HP-PRIME: Needs Home mode selected, otherwise in CAS mode it gives "sin(pi)" = 0;
Even if we type "SIN(3.1415926535898) we still get a result of -2.06761537357E-13, as the inputted command is rounded in history to have just 12 digits: "SIN(3.14159265359)".
So it seems that the PRIME shows a better behavior than the HP-50G in this regard.

[debrouxl]

Yeah, the TI-68k series computes with 14 digits accuracy and displays up to 12 digits. Using the core BCD float routines through native code, without pushing floats onto the EStack, gives access to the full 16-digit mantissa.

[ColinJDenman]

(04-06-2014 01:33 PM)orcinus Wrote:  

(04-05-2014 11:38 PM)ColinJDenman Wrote:  The nature of the hardware (speed, storage) has changed radically. Increased precision is entirely possible. I don't ask for the impossible, just better.

So you're saying you'd prefer it'd display 3.45E-20 to 3.45E-10 and consider that a valuable application of technological progress?

I'm sorry if I have offended you. My answer to the question is YES. But please feel free to ignore my ramblings in future

[ColinJDenman]

(04-06-2014 02:11 PM)jebem Wrote:  Thanks, Joe and Peacecalc for your explanations. It makes all the sense.

(6) HP-PRIME: Needs Home mode selected, otherwise in CAS mode it gives "sin(pi)" = 0;
Even if we type "SIN(3.1415926535898) we still get a result of -2.06761537357E-13, as the inputted command is rounded in history to have just 12 digits: "SIN(3.14159265359)".
So it seems that the PRIME shows a better behavior than the HP-50G in this regard.

Thanks for your informative post. This was the kind of info I was wondering about. My initial thought was to wonder why digit precision was not substantially superior on the Prime, given the hardware capability. I also note that CAS settings include an epsilon value, but not Home.

Others seem to feel I do not recognise the inevitability of approximation in digital computation. I do, but feel a simple calculation displaying these errors questions the reliability of much more involved calculations. The calculator does not offer an estimate of the size of the error in the result. If you see a 'very' small result and discard it as approximation error, what is the purpose in having a calculator that displays 9E-499?

Since I appear to have touched a few buttons here, I'll try to refrain from responding further in this thread.

[orcinus]

(04-06-2014 11:31 PM)ColinJDenman Wrote:  Since I appear to have touched a few buttons here, I'll try to refrain from responding further in this thread.

No buttons touched (on my part at least) and no need for refraining of any sort. Discussions in which all sides are in full agreement are not worthy of being called discussions

[Tim Wessman]

I think what you've discovered is that you've stepped into a very contentious and core issue that dates back to the great calculator wars between HP and TI.

The basic issue boils down to this: Should the result given at each step be the most accurate result to the displayed number of digits such that if a user executed each step one at a time the result would be identical, or should additional guard digits be used that potentially aid intermediate calculations but will result in a different result if executed one at a time?

Also, should results be "rounded" in special cases so that the "expected" result is returned even through numerically it is "wrong"? ( eg: sin(pi) )

[Han]

(04-06-2014 11:31 PM)ColinJDenman Wrote:  Others seem to feel I do not recognise the inevitability of approximation in digital computation. I do, but feel a simple calculation displaying these errors questions the reliability of much more involved calculations. The calculator does not offer an estimate of the size of the error in the result. If you see a 'very' small result and discard it as approximation error, what is the purpose in having a calculator that displays 9E-499?

I think you are confusing the ability to have numbers like 9E-499 with algorithms that are accurate to 499 decimal places. They are two very different concepts. Floating point-precision requires that the calculator be able to handle small numbers, but the ability to handle small numbers does not immediately imply fast and efficient floating point algorithms scale to such high precision in a nice way (esp. in terms of speed). High-precision floating point libraries tend to take up more space and more time for computations, and are usually provided through external libraries when such precision is needed. Most of the "typical" users of calculators will find that 10-12 decimal places provide enough accuracy.

[HP67]

I don't pick up from Colin's post that there is any confusion, just a general sense that accuracy and to a lesser extent precision haven't kept paces with advances in hardware. And that is certainly true. Gains in accuracy after you get the basic stuff right come at very high incremental cost and they don't come at the same rate as more powerful hardware. It could be argued cheap hardware is causally-related to the decreasing rate of progress in algorithms But that is another discussion.

A middle ground might be some kind of heuristic that deals with defined values of common functions so that sin(pi) is always returned as zero, etc. Then again, the addition of CAS and the options of various settings (exact vs. approx mode) often complicate getting the intended results unless documented clearly, etc. We are now past the point where anything is simple.

Tim's answer was very helpful giving food for thought about some of the issues and engineering tradeoffs involved in implementing math in hardware.

[orcinus]

(04-08-2014 07:41 AM)HP67 Wrote:  I don't pick up from Colin's post that there is any confusion, just a general sense that accuracy and to a lesser extent precision haven't kept paces with advances in hardware.

His response to my:

Quote:So you're saying you'd prefer it'd display 3.45E-20 to 3.45E-10 and consider that a valuable application of technological progress?

... pretty clearly identifies that's his primary concern/critique, yes, but with the caveat of being solely a question of precision, not accuracy.

Which begs the question - what exactly is "precise enough" and how can there be an absolute measure of precision that's in-line with current hardware? Required and/or significant precision changes according to application. And would 3.45E-20 really be a better answer than 3.45E-10 in this particular example?

[Manolo Sobrino]

There was a long version of this post with accuracy/precision tests, fun and excitement, but it's definitely overkill and you should always check this kind of claims anyway... Short version:

a) You can't justify using more significant digits for the answer than those of the argument. That's not how things work in the real world of measuring things. The answer you get from the Prime is really zero, as the consistent way of writing it is 0E-12.

b) The TI calculators perform consistently with it's 14 digit claimed accuracy. They get zero because that's the correct 14 significant digit result for their stored value of Pi. I can't find strange jumps in the neighbourhood of Pi. Actually they give you the meaningful answers. No tricks, no special values, go figure.

c) Digital garbage just gives you a lot of information about precision.

d) The Prime results likely correspond to calculations with at least 25-digit precision of the 12 digit rounded value of Pi.

e) They could make Colin happier by using a value of Pi with more digits, as probably this can be done he has a point. They should be rounded in a sensible way for the final accurate answer anyway.

f) Due to rounding numbers to 12 digits after every operation (this took a while) and then performing those at least 25-digit precision calculations, the TI results for SIN have actually more significant accurate digits in the neighbourhood of Pi.

[Joe Horn]

(04-08-2014 01:46 PM)Manolo Sobrino Wrote:  f) Due to rounding numbers to 12 digits after every operation (this took a while) and then performing those at least 25-digit precision calculations, the TI results for SIN have actually more significant accurate digits in the neighbourhood of Pi.

Whoa, help me out here. The closest that 12 significant digits can get to sin(exactly 3.14159265359 radians) is -2.06761537357E-13, which is exactly what HP returns. To verify its validity, I just cranked sin(pi rounded to 12 significant digits) to 100 decimal places and rounded the result. HP is correct. Are you saying that TI's 12 digits are somehow more correct? Since any 12-significant-digit result (from TI or anybody else) can only be as good or worse, I must be misunderstanding your point (for which, please don't flame me... I'm really trying to understand here, and not be a "sycophant"). Thanks in advance.

[Manolo Sobrino]

(04-08-2014 11:43 PM)Joe Horn Wrote:  Whoa, help me out here. The closest that 12 significant digits can get to sin(exactly 3.14159265359 radians) is -2.06761537357E-13, which is exactly what HP returns. To verify its validity, I just cranked sin(pi rounded to 12 significant digits) to 100 decimal places and rounded the result. HP is correct. Are you saying that TI's 12 digits are somehow more correct? Since any 12-significant-digit result (from TI or anybody else) can only be as good or worse, I must be misunderstanding your point (for which, please don't flame me... I'm really trying to understand here, and not be a "sycophant"). Thanks in advance.

Yeah, that's the closer a computer can get to calculate

Sin[3.14159265359000000000000000000000000000000000000000000000000000000]

But if your number has 11 decimal positions you can't get a more accurate answer than that with 11 decimal positions. We're talking about accuracy here, not precision. That's what happens when you calculate this in Wolfram Alpha:

http://www.wolframalpha.com/input/?i=Sin[3.14159265359]

They call the first thing Decimal approximation, and the second Result.

I've tested this rounding to 12 approach with Mathematica, which uses the GMP multiple precision library: I couldn't get the quoted results unless I worked with a precision of at least 25 digits and I couldn't get other results from the emulator unless I figured out that they were rounded to 12 significant digits first.


The TI 8X calculators give you the accurate values they can:

pi=3.1415926535898

sin(3.1415926535898) = 0


sin(1E-14)= 1E-14

sin(pi+1E-11)= -1E-11

(actually this is a flaw in the implementation of how to display this; it should be: -1.00E-11)

sin(pi+1E-12)= -1E-12 (idem, now -1.0E-12)


sin (pi*(1+1E-13))= -3E-13

sin (pi*(1+1E-12))= -3.1E-12

sin (pi*(1+1E-11))= -3.14E-11


Now try this in the Prime emulator:

pi= 3.14159265359

sin(pi*(1+1E-11))= -3.02067615374E-11

The only way you can get it is if you round the argument like this:

pi*(1+1E-11)= 3.14159265359 + 0.00000000003

And then perform your high precision calculation:

Sin[3.14159265359`25 + 0.00000000003`25]= -3.0206761537357*10^-11

(Standard Mathematica notation for numbers to `n precision)

Had you done for instance this:

3.14159265359`25*1.00000000001`25

then:

Sin[3.14159265359`25*1.00000000001`25]= -3.1622688073257*10^-11

Which would have given you the best available precision answer for its value of Pi. (BTW, for this value of Pi, the TI result is -3.16E-11).


The TI calculations (more significant digits of Pi) yield accurate results in the neighbourhood of Pi:

Compare: sin (3.1415926535898*(1+1E-12))= -3.1E-12, with:

Sin[3.1415926535898`14*(1`14 + 0.000000000001`14)]= -3.1*10^-12

Sin[3.1415926535898`32*(1`32 + 0.000000000001`32)] = -3.1483541909464167205*10^-12

the true value to ten significant digits:

N[Sin[Pi*(1 + 1*10^-12)], 10]= -3.141592654*10^-12

and the Prime results:

sin(pi*(1+1E-12) = -2.06761537357E-13


And the other result: sin(3.1415926535898*(1+1E-11))= -3.14E-11

With:

Sin[3.1415926535898`14*(1`14 + 0.00000000001`14)]= -3.14*10^-11
Sin[3.1415926535898`32*(1`32 + 0.00000000001`32)]= -3.14226880732546167205*10^-11

the true value to ten digits:

N[Sin[Pi*(1 + 1*10^-11)], 10]= -3.141592654*10^-11

and the Prime results quoted above:

sin(pi*(1+1E-11) = -3.02067615374E-11

Which despite rounding is accurate to 11 decimals:

Sin[3.14159265359`12*(1`12 + 0.00000000001`12)]= -3.*10^-11

but as discussed not the best precision answer because of rounding practices.


IMO, the facts that the TIs perform calculations with more significant digits and that they only claim accuracy yield more accurate and meaningful answers(*). On the other hand, Casio...

No, I'm not willing to engage in flame wars (and this is an old and complex issue that won't be settled as both sides want different things and they are right yet unreasonable), but I think that you guys have dismissed Colin too swiftly. As I've said elsewhere I'm not really interested in sharing my thoughts on the Prime saga much (/any) longer.

I'm not (by any means) an expert on floating point precision/accuracy of numerical algorithms (it's unbelievably involved). I only perform tests for my own calculations with data coming from measurements and check the accuracy of the numbers I get from models. In my experience raw precision and meaningful significant digits are not the same.

(... I feared this word sycophant could eventually catch on )

____________________________________________________________

(*) In this kind of calculations for ~(0, 2 Pi). As you might have noticed I'm a brand agnostic, so I have have no problem in saying that (I suspect) they do have other problems in the trig functions having to do with range reduction... yet this is not the place to delve into details.

[John R. Graham]

(04-04-2014 06:05 AM)HP67 Wrote:  50g CAS mode

Code:

 0

Small pedantic correction. 50g does not have a "CAS mode". It has an exact mode that functions uniformly across all calculation functions. Important in the context of the prime, I think.

- John

[ColinJDenman]

oh dear, I'm breaking my word.

I won't coment hugely on the detail discussed though I think it has been an interesting and useful thread.

I'd note sin(n*pi) - sin(pi) for n=1...6000000 suggests there is no mapping of x to 0<= x < 2pi, which I do think is appropriately correctable for sin, as is the appropriate short circuiting of the internal algorithm for 'well known' values of x and sin. As the CAS notes, sin(pi) is 0. Why doesn't the Home calculator defer to this superior result by internally defining "Home.sin(x)=eval(CAS.sin(x)) figuratively speaking. In this, I perhaps don't understand the resource consumption of having Home.calc and the segregation between. The code for a better result is already in there somewhere.

If I process observational data, I should estimate the error margins in the result from observational errors and lose superfluous precision. Simple functions show rounding errors. What about the result from a more complex calculation of many operations such as might occur in a program. How do I estimate the computational error in each and every calculation I perform without considerable extra work, in order to estimate the result I get plus or minus a relevant margin?

My attitude from the beginning has been a concern that observable error in a one-shot simple calculation questions what the errors are in a more complex one. And how to estimate them and rely on the results I see..

You might like to try Cos(pi/2)/(sin(pi)

My silence over the week in part extends from a painful back injury last Monday. This is my first session online since. And probably the last for a bit longer :-(

[Han]

(04-14-2014 02:48 PM)ColinJDenman Wrote:  My attitude from the beginning has been a concern that observable error in a one-shot simple calculation questions what the errors are in a more complex one. And how to estimate them and rely on the results I see..

The issue that I see (based on the posts in this thread) is nowhere close to, say, a case of a calculator computing 2+3 and returning 5.8. I don't work for HP (nor do I claim to speak for them) but I feel pretty confident in saying that the error resulting from using the Home view in doing numerical calculations will very likely NOT balloon into something ridiculous. The error is somewhere out toward the 10th or 11th decimal place. That said, anyone using any sort of calculating tool will necessarily need to be aware of roundoff error. This goes for using the CAS view as well. The results you get, even if all the precision needed is there, will still need to be interpreted correctly. (E.g. I always tell my students to watch out for negative values that a calculator will correctly return, but will not make sense if they are solving for the length of a side of a box.)

If you are doing scientific work in which even the slightest bit of error may result in catastrophic consequences, a scientific calculator is hardly the tool -- whether designed by HP or any other company.

EDIT: To address your specific example of: \( \frac{\cos(\pi/2)}{\sin(\pi)} \) -- there is a singularity at \( \theta = \pi \) for \( \frac{\cos(\theta/2)}{\sin(\theta)} \) so any numerical answer your calculator returns is the wrong answer.

EDIT #2: For calculators (such as the TI-84), if I type in \( \cos(3.141592654) \) it spits out the answer as -1. This is mathematically wrong, as \( \cos( \pi ) = -1 \) and \( \pi \not= 3.141592654 \). So what happens if I need to actually compute the cosine of the rational number 3.141592654? The calculator gives me division by 0 if I do \( 1/ \cos( 3.141592654) \) even though I know the denominator is not 0. The answer is off by a magnitude of "infinity" if you will. Of course this entire example is a bit silly. Insisting that \( \cos ( 3.141592654 ) = -1 \) being "wrong" is just as silly as insisting that \( \cos (3.141592654 ) \not=-1 \) is "right" -- inside an environment that is limited in precision.

I recommend reading:

http://www.stewartcalculus.com/data/ESSE...mp_stu.pdf
http://apcentral.collegeboard.com/apc/me...11703.html
http://www2.edc.org/cme/showcase/KY/calcliesarticle.pdf

(The third link is extremely interesting -- the graph of \( \sin(46x)\) looks like \(-\sin(x)\).)