Euler Identity in Home

[Manolo Sobrino]

(04-14-2014 02:48 PM)ColinJDenman Wrote:  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.

There's no need for "short circuiting" and people really do get zeroes without it. This is a bounded (and periodical) function that maps [0, 2 Pi) to [-1, 1]. If you work with 12 significant digits, then:

A) 3.141592653585
B) 3.141592653586
C) 3.141592653587
D) 3.141592653588
E) 3.141592653589
F) 3.141592653590
G) 3.141592653591
H) 3.141592653592
I) 3.141592653593
J) 3.141592653594

Are all the same and (should) yield the same result than:

3.14159265359

There's no point in having as an answer:

-.000000000000206761537357

And swearing that every bit of it is true, because if those results were meaningful to E-13, then you could effectively tell F) from B), C)... J), and you can't. See how it works:

Let's generate A)-J):

(first line: Mathematica command, I hope the syntax is self-explanatory, results below)

Table[3.14159265359 + (i - 6)*10^-12, {i, 10}] // InputForm

/* i starts at i=1, // is the pipe to InputForm, so we can see all the digits from the output*/

{3.141592653585, 3.141592653586, 3.141592653587, 3.141592653588, 3.141592653589, 3.141592653590, 3.141592653591, 3.141592653592, 3.141592653593, 3.141592653594}


The true values of Sin for them are:

(first line: Mathematica command, results below, -I'm doing it the easy way-)

Table[Sin[3.14159265359 + (i - 6)*10^-12], {i, 9}]

{4.79318*10^-12, 3.79309*10^-12, 2.793*10^-12, 1.79335*10^-12,
7.93266*10^-13, -2.06823*10^-13, -1.20691*10^-12, -2.207*10^-12, -3.20665*10^-12}


Which value did the calc pick? The sixth? Why? But they are all good! in fact any value in (-3.20665*10^-12, 4.79318*10^-12) would be a good answer.


This is not a floating point issue. It's just continuous functions and significant digits' common sense. The best accurate and meaningful value your calc should give you is 0E-12, that is 2.06761537357E-13 rounded to 12, the rest is garbage. Yet people are not willing to get/believe it, go figure!


HP, or their fans, have taken historically a very strange viewpoint in which having obvious accuracy in the display is not that important, but raw results are, leaving to the user the task of making sense of them, with awful consequences on the average, I'm sad to say.


It's more sad that being burdened with mantras of 12 significant digits are enough, and you don't keep guard digits (even though apparently HP calculators adopted them later -I don't know for sure- and this, which makes some sense for an RPN machine, does not for a textbook entry), even when performing intermediate operations the user can't see, a powerful machine capable of a lot ends up doing things nobody else would. Anyway...

[Han]

(04-14-2014 07:10 PM)Manolo Sobrino Wrote:  Which value did the calc pick? The sixth? Why? But they are all good! in fact any value in (-3.20665*10^-12, 4.79318*10^-12) would be a good answer.

The calc picked the sixth case because it rounds \( \pi \) to 3.141592653590 and not any of the other values. And while all the other values are just as good, it only makes sense to map to one of them -- namely the one corresponding to an input of 3.141592653590.

Quote:This is not a floating point issue. It's just continuous functions and significant digits' common sense. The best accurate and meaningful value your calc should give you is 0E-12, that is 2.06761537357E-13 rounded to 12, the rest is garbage. Yet people are not willing to get/believe it, go figure!

I agree and disagree. I agree in terms of significant digits because we are doing numerical calculations and know that there will be roundoff error. I disagree in terms of pure mathematical results. Take for example:

\[ (10^{15}+1.2-10^{15})*100 \]

Most calculators will give you -- even Maple -- will give you a result of 0. This is a valid answer in practical terms. It is, of course, the wrong answer mathematically.

Quote:HP, or their fans, have taken historically a very strange viewpoint in which having obvious accuracy in the display is not that important, but raw results are, leaving to the user the task of making sense of them, with awful consequences on the average, I'm sad to say.

The blind reliance on any calculating machine for the right answer is always going to result in awful consequences. To suggest that there is one, right approach to handling numerical calculations is also going to result in awful consequences.

[Manolo Sobrino]

(04-14-2014 07:31 PM)Han Wrote:  

(04-14-2014 07:10 PM)Manolo Sobrino Wrote:  Which value did the calc pick? The sixth? Why? But they are all good! in fact any value in (-3.20665*10^-12, 4.79318*10^-12) would be a good answer.

The calc picked the sixth case because it rounds \( \pi \) to 3.141592653590 and not any of the other values. And while all the other values are just as good, it only makes sense to map to one of them -- namely the one corresponding to an input of 3.141592653590.

No, it doesn't.

The consistent answer for 12 significant digits is 0.000000000000, and that is not zero, those zeroes have a meaning.

Quote:I agree and disagree. I agree in terms of significant digits because we are doing numerical calculations and know that there will be roundoff error. I disagree in terms of pure mathematical results. Take for example:

\[ (10^{15}+1.2-10^{15})*100 \]

Most calculators will give you -- even Maple -- will give you a result of 0. This is a valid answer in practical terms. It is, of course, the wrong answer mathematically.

Well, in such a case that famous answer for sin (pi) is also wrong. You can't have your cake and eat it. Either you are consistent or you aren't.

Maple is able to do arbitrary precision calculations, you should try that.

Quote:The blind reliance on any calculating machine for the right answer is always going to result in awful consequences.

I fully agree on that

Quote:To suggest that there is one, right approach to handling numerical calculations is also going to result in awful consequences.

That's what professional Mathematicians do, and HP has taken advantage of it in the past. Kahan might still be available. If not, I'd suggest Higham.

You know, this thing Maths is unluckily for some not a matter of opinion, either you get it right or you don't. In the real world of Logic, Math departments and peer reviewed journals your preferences don't matter. If you keep on being wrong for the sake of it you're out.

[CR Haeger]

Hmm... Math departments and journals have settled this for HP and other calculator makers already?

Thanks to HP, TI, Casio and others replacing slide rules we can dicker about 10e-12 instead of 10e-4 in 1971

[Han]

(04-14-2014 09:17 PM)Manolo Sobrino Wrote:  

(04-14-2014 07:31 PM)Han Wrote:  The calc picked the sixth case because it rounds \( \pi \) to 3.141592653590 and not any of the other values. And while all the other values are just as good, it only makes sense to map to one of them -- namely the one corresponding to an input of 3.141592653590.

No, it doesn't.

The consistent answer for 12 significant digits is 0.000000000000, and that is not zero, those zeroes have a meaning.

I was not debating what the answer for 12 significant digits was. I was debating on your suggestion any one among {4.79318*10^-12, 3.79309*10^-12, 2.793*10^-12, 1.79335*10^-12, 7.93266*10^-13, -2.06823*10^-13, -1.20691*10^-12, -2.207*10^-12, -3.20665*10^-12} would be fine. There is a difference between suggesting the correct answer is 0.000000000000 versus any one among this list. They are all "equal" when rounded to 12 sig. digits, but they are clearly not the same numbers. Surely you agree.

Quote:Well, in such a case that famous answer for sin (pi) is also wrong. You can't have your cake and eat it. Either you are consistent or you aren't.

In what sense are you suggesting it's wrong? Mathematically? or practically? Mathematically, no numerical calculations involving rational approximations of transcendental values will every be "exactly right", but they can be "right" in a practical sense once we account for roundoff errors. The Prime enables you to use two separate environments depending on your needs. If you only care to have approximate solutions, use the Home environment. If you need exact values, use the CAS environment.

Quote:Maple is able to do arbitrary precision calculations, you should try that.

That is completely irrelevant. One could argue that the Prime has a CAS mode in which the value of \( \sin(\pi) \) is always 0 and that users "should try that."

Quote:

Quote:To suggest that there is one, right approach to handling numerical calculations is also going to result in awful consequences.

That's what professional Mathematicians do, and HP has taken advantage of it in the past. Kahan might still be available. If not, I'd suggest Higham.

You know, this thing Maths is unluckily for some not a matter of opinion, either you get it right or you don't. In the real world of Logic, Math departments and peer reviewed journals your preferences don't matter. If you keep on being wrong for the sake of it you're out.

Mathematicians would not even consider using a calculator or CAS or any of the stable algorithms designed by Higham when it comes to "exact" mathematics for their proofs. The question of accuracy is moot in this case. That said, are we still discussing numerical algorithms applied to transcendental values -- on a calculator -- here? If you want the power of Higham or Kahan or (insert whatever numerical analyst you like here) then why are we even debating this in the context of a calculator? At some point one must concede that, given the constraints of a particular machine (RAM, CPU power, etc), some amount of accuracy is sufficient. Otherwise, we need a more powerful machine. As already mentioned, the calculator has a CAS for those who need "exact" answers.

[Manolo Sobrino]

(04-14-2014 10:47 PM)Han Wrote:  I was not debating what the answer for 12 significant digits was. I was debating on your suggestion any one among {4.79318*10^-12, 3.79309*10^-12, 2.793*10^-12, 1.79335*10^-12, 7.93266*10^-13, -2.06823*10^-13, -1.20691*10^-12, -2.207*10^-12, -3.20665*10^-12} would be fine. There is a difference between suggesting the correct answer is 0.000000000000 versus any one among this list. They are all "equal" when rounded to 12 sig. digits, but they are clearly not the same numbers. Surely you agree.

Oh Han... I proposed this, I took the time and pains to explain why it should be 0.000000000000. It should be that because if you consider that your result is accurate to more digits you are actually trespassing your own limits. But people just don't care, no one in this forum has ever mentioned the table maker's dilemma for instance, which is relevant for this kind of recurring discussions, it's all talk, talk, talk and vacuous claims. It's a kind of totemic attitude versus a device that I, due surely to cognitive biases having to do with my painful education can't understand.

Quote:

Quote:Well, in such a case that famous answer for sin (pi) is also wrong. You can't have your cake and eat it. Either you are consistent or you aren't.

In what sense are you suggesting it's wrong? Mathematically? or practically? Mathematically, no numerical calculations involving rational approximations of transcendental values will every be "exactly right", but they can be "right" in a practical sense once we account for roundoff errors. The Prime enables you to use two separate environments depending on your needs. If you only care to have approximate solutions, use the Home environment. If you need exact values, use the CAS environment.

First you like that your calc comes up with the exact result for Sin[3.14159265359000000000000000000000000000000000000...], which is not the true value of sin(Pi) yet is given with spurious precision to it's true value. Then you complain about them not being able to give the true answer of an arithmetic calculation when they're working out of their range. I just get lost with your point.

Quote:

Quote:That's what professional Mathematicians do, and HP has taken advantage of it in the past. Kahan might still be available. If not, I'd suggest Higham.

You know, this thing Maths is unluckily for some not a matter of opinion, either you get it right or you don't. In the real world of Logic, Math departments and peer reviewed journals your preferences don't matter. If you keep on being wrong for the sake of it you're out.

Mathematicians would not even consider using a calculator or CAS or any of the stable algorithms designed by Higham when it comes to "exact" mathematics for their proofs. The question of accuracy is moot in this case. That said, are we still discussing numerical algorithms applied to transcendental values -- on a calculator -- here? If you want the power of Higham or Kahan or (insert whatever numerical analyst you like here) then why are we even debating this in the context of a calculator? At some point one must concede that, given the constraints of a particular machine (RAM, CPU power, etc), some amount of accuracy is sufficient. Otherwise, we need a more powerful machine. As already mentioned, the calculator has a CAS for those who need "exact" answers.

Applied Mathematicians have been crunching numbers for a long time with less computing power than that which you have in your hands now. It can be done, and of course it has been done. We have digital computers since really the 50s, and people have been doing a great job with them since then, developing interval arithmetic and all kinds of nice stuff to provide meaningful answers with error bounds, which is the more "exact" mathematics you can do for this job, you're not proving the four colour theorem here. What would have given Feynman at Los Alamos for a dozen of these?... This is hopeless, we won't agree tonight (at Europe). Let's leave it for another day.

[Han]

(04-14-2014 11:32 PM)Manolo Sobrino Wrote:  This is hopeless, we won't agree tonight (at Europe). Let's leave it for another day.

I don't think we were ever really disagreeing about the big picture. (Edit: by this I mean that in most circumstances we likely agree on what the answer should be when considering significant digits etc.) But certainly we disagree on the details. My stance is that there are two modes: and approximate mode and an exact mode so we should choose the appropriate mode for our needs.

In particular, your statement:

Quote:HP, or their fans, have taken historically a very strange viewpoint in which having obvious accuracy in the display is not that important, but raw results are, leaving to the user the task of making sense of them, with awful consequences on the average, I'm sad to say.

This is where we essentially disagree. It is my opinion that the onus is always on the user to interpret the results. "With great power comes great responsibility."

Now, some are arguing (perhaps you included?) that the approximations could be better, and that in certain circumstances, the calculator should also take into account sig. digits and round appropriately. My response to that will always be that it is up to the user to properly interpret the results. What may mathematically be wrong may be practically correct, and vice versa. The calculator should not be responsible for interpreting results -- it should only compute them. When Maple computes (1.0E16-7.2-1.0E^16) and tells me the result is 0. (as opposed to 0.0E16 by the way), it's mathematically wrong AND it also interprets wrong (wrong sig. number of digits). But practically speaking, it's the right answer. There is a very valid reason why it should not interpret for us. In mathematics, there is no difference between
\[ (10^{15}-7.2-10^{15})\cdot 100 \]
and
\[ (10^{15} - \frac{72}{10} - 10^{15}) \cdot 100 \]
but for many computer algebra systems, there is a huge difference in the results. No CAS is going to reliably guess whether either input is meant to be computed exactly or approximately, so almost all of them insist that the use of a decimal point is meant to be a floating point approximation -- and that's fine as long as everyone is aware. In the same vein, it should be a given that any time one uses decimal approximations for computing with transcendentals, the result needs to be handled with proper care and interpretation.

So yes, I agree that sin(3.141592653590) should practically be interpreted as 0.00000000000 (hopefully I have the right number of 0's there) -- provided that intent was to get a decimal approximation of \( \sin(\pi) \) and not an exact mathematical evaluation -- but I don't think it should be up to the calculator to decide that interpretation for me. It should return whatever its algorithm was designed to return, based on whatever limitations on precision have been set. Then it is up to me to properly interpret the results myself. Note that this goes for hand calculations, too.

(Hopefully I am not misreading the posts in this discussion.)

[Manolo Sobrino]

Han, what's so hard to understand that if you claim to work with 12 significant digits, and you round in every step to 12 significant digits, and you store numbers with 12 significant digits, you can't simply give back results calculated with 25 significant digits? And adding insult to injury give them rounded to 12 in floating point?

I finally got it, these things are made by engineers, for engineers, with the depth of mathematical knowledge of engineers. A match made in heaven.

[Didier Lachieze]

Manolo, I'm confused, if fort SIN(3.14159265359) a calculator with 12 significant digits should return 0.00000000000, then for 2^(-40) should it also return 0.00000000000 and not 9.09494701773E-13 ?

[Joe Horn]

(04-15-2014 09:17 PM)Manolo Sobrino Wrote:  Han, what's so hard to understand that if you claim to work with 12 significant digits, and you round in every step to 12 significant digits, and you store numbers with 12 significant digits, you can't simply give back results calculated with 25 significant digits? And adding insult to injury give them rounded to 12 in floating point?

You are assuming that we don't understand that. We DO understand it... and disagree with it. And for good reason, as the following hopefully makes clear.

If I want to calculate the sine of exactly 1 radian, then I would type sin(1), and of course I would intend it to mean sin(exactly 1.000000000000000000... radians). But YOU would say, "Oh no no no, that's wrong; sin(1) is using an input of only one significant digit, so the output should only have one significant digit, and any more digits than that in the output are bogus." At this point, you will of course object that you never said any such silly thing. Ah, but you have said it, over and over, every time you have insisted in this discussion that typing sin(3.14159265359) on an HP calculator cannot possibly be intended by the user to mean "give me the sine of exactly 3.141592653590000000000... radians". Apply that false assumption to sin(1) and you get the previously mentioned silly statement.

What's so hard to understand about this: HP allows the user to decide how many digits of the input are significant (including trailing zeros!), which then (as you mentioned!) requires the user to interpret the calculated result accordingly. When TI makes those decisions for the user, the user is prevented from exploring certain questions, such as "What is the sine of numbers very close to pi?" HP allows such exploration. Therefore HP can do what TI can't. Q.E.D.

Disclaimer: All of the above was my opinion when I wrote it, but I enjoy learning, and changing my opinions when that is warranted, so stay calm.

[Manolo Sobrino]

(04-15-2014 10:21 PM)Didier Lachieze Wrote:  Manolo, I'm confused, if fort SIN(3.14159265359) a calculator with 12 significant digits should return 0.00000000000, then for 2^(-40) should it also return 0.00000000000 and not 9.09494701773E-13 ?

Of course not, and that's the beauty of it. It has to do with the nature of the function you are considering (and where), for instance, is it bounded? How much does it change around this or that particular point?

You need more than 12 significant digits of Pi to specify a value different than 0.00000000000 for Pi rounded to 12 significant digits, but your 12 significant digits of 2, or 2.00000000000 are enough to specify any value with 12 significant digits of the exponential function.

In the first scenario you are mapping [0, 2 Pi) to [-1, 1]. In the second it's Reals* to Reals. Just think about the definition of function (eom style):

Let the sets X and Y be given. To each element x of X corresponds an element y of Y, which is denoted by f(x), then we say a function f is given on X.

Joe, just read my post of yesterday. It's not the same, and you will see why. Trailing zeroes can be significant figures. x=1.00000000000 means that I know that x is 1 with a precision of 11 decimals. You can specify a value of sin(1) with 11 decimals, and you can specify a value of sin(Pi) with 11 decimals as well, it happens to be 0.00000000000. Notice that if we calculate Sin(3.14159265359*10^-12) the right answer to 12 significant digits is 3.14159265359*10^-12.

As I wrote a few days ago, not worrying about what you can say or not according to your precision (and maiming it) yields "wrong" results, check the example sin(pi*(1+1E-11)). So it's not like there's any particular advantage to it. In the neighbourhood of Pi it gives correct results when rounded, but if the user doesn't know, and sometimes they can't know, it is misleading at best.

This reminds me of a thread of some time ago. The linear solver of the 50G spat results for an incompatible system and that's it, after some digging it turns out that it was producing the minimum norm Least Squares solution with no warning. How is that good for you? Do you have to check if the system has indeed a solution before trusting the solution? In an exam? Now, do you have to check with Mathematica wth is going on with the rounding and the real precision available for calculations in your calculator before you can understand the results for sin(), and then you have to interpret them? What's the point of a calculator I have to check elsewhere the things it shows me? And the results from a TI, that in this case are decent and accurate are bad for you, because it's a TI?? And as they get it right you suggest that they're doing tricks??? I just find all this extremely bizarre. I love RPN, but that has nothing to do with it: Amicus Plato, sed magis amica veritas.

[Joe Horn]

(04-15-2014 10:53 PM)Manolo Sobrino Wrote:  ... you can specify a value of sin(Pi) with 11 decimals ... check the example sin(pi*(1+1E-11))....

<takes deep breath to calm down> There you go again, insisting on talking about pi, when we are specifically talking about a number that is NOT PI, namely, EXACTLY 314159265359/10^11. THAT'S NOT PI, and it's NOT AN APPROXIMATION either. It's an EXACT number, the exact ratio of two integers. And exactly that many radians does in fact have an exact sine. TI can't find it. That's a Good Thing? HP does find it. That's a Bad Thing?

(04-15-2014 10:53 PM)Manolo Sobrino Wrote:  ... And the results from a TI, that in this case are decent and accurate are bad for you, because it's a TI??

No. The result given by TI for the sine of 314159265359/10^11 is neither decent nor accurate, not because it's a TI, but because it's wrong. I couldn't care less who made the calculator. Remember, I was the guy who blew the whistle on the horrible square root accuracy bug in the HP 30S (not to mention the zillion other HP bugs I've reported over the past few decades). Finding HP bugs is my #1 hobby; it actually gives me a visceral thrill when I find one. But HP gets this sine right.

(04-15-2014 10:53 PM)Manolo Sobrino Wrote:  And as they [TI] get it right you suggest that they're doing tricks???

Your insisting that TI's answer is "right" does not make it right. Just look at all the mental gymnastics you've posted in this thread, attempting to justify TI's erroneous result. But then look at the simplicity of HP's position. Does sin(exactly 314159265359/10^11 radians) have a value that's exactly defined by Maths? Yes. Is HP's result closer to it than TI's? Yes. Period.

(04-15-2014 10:53 PM)Manolo Sobrino Wrote:  Amicus Plato, sed magis amica veritas.

Oh? If truth be so precious, then why are you defending TI's false result for sin(314159265359/10^11), and denigrating HP's true result?

Remember, we're talking about the EXACT value 314159265359/10^11 here, not an approximation of pi or of anything else. Anything else in this discussion is a digression.

[DavidM]

(04-15-2014 09:17 PM)Manolo Sobrino Wrote:  Han, what's so hard to understand that if you claim to work with 12 significant digits, and you round in every step to 12 significant digits, and you store numbers with 12 significant digits, you can't simply give back results calculated with 25 significant digits?

Perhaps my understanding of significant digits is different than yours, because I can't see where the 25 significant digits comes into play. As I was taught, -0.000000000000206761537357 still only has 12 significant digits. Where are you getting the 25 digit count from? I'm genuinely curious as to whether there is a different understanding of significant digits here. I suppose it's more likely that I just don't understand what you're trying to say.

I don't have a large collection of calculating/computing systems to compare, but I can say that I have checked the following systems to see what the result of "sin(3.14159265359)" is for each one:

Wolfram Alpha (on the web):
-2.0682310711021444E-13

MS Excel 2010 on my laptop:
-2.06823056944638E-13

HP 50g:
-2.06761537357E-13

HP 30b:
-2.0676153736E13

A compiled Delphi XE2 app using the default SIN function with extended (80-bit) reals (also on my laptop):
-2.06761528471349765E-13

The only TI calculator I have is a TI-34 (a 10-digit unit). Here's the results it gave:
a) 3.141592654 SIN: -4.1E-10
b) <pi> SIN: 0

Pressing the <pi> key results in the display showing the value 3.141592654 (the same as item a above). But clearly there's a difference. In an attempt to see that difference, I tried the following:
<pi> - 3.141592654 = -4.1E-10

It appears the TI-34 is carrying more digits than it displays for pi. But it is still rounding its result when using that value.

Of those systems, only the TI-34 rounded the final result to 0, and it only did that when I used the special key for pi. Granted, we are focused on calculators here. But the insistence that zero or 0.000000000000 is a more correct answer for sin(3.14159265359) than -2.068E-13 seems to be a TI-specific viewpoint which isn't shared by the other math libraries I am able to compare it to.

What's more interesting to me is the variance in the non-zero results.

[Dieter]

(04-16-2014 08:23 AM)DavidM Wrote:  I don't have a large collection of calculating/computing systems to compare, but I can say that I have checked the following systems to see what the result of "sin(3.14159265359)" is for each one:

Let me add just two remarks:

1. The true value of sin(3,14159265359000000...) is 2,0676 15373 56616 72049 71158...·10^–13-.

For arguments that close to \(\pi\) the first 20+ significant digits for sin(x) and tan(x) agree with \(\pi\) – x. This means that the results given by Wolfram Alpha and Excel have merely three valid digits. In the latter case this probably is due to the fact that Excel uses binary arithmetics and 3,14159265359 cannot be represented exactly with the usual 52 mantissa bits. If x is off by 2^–53 the error in sin(x) will be roughly the same, i.e. about 10^–16. Which agrees with the error in the result you posted.

2. For evaluating trig functions, calculators often use a method that requires an internal value of \(\pi\) with at least twice the number of returned significant digits for a full precision result. However, the HP and TI devices I used only carry three additional digits for internal calculations. This explains the behaviour of your TI-34, which BTW is the same as in earlier HP 10-digit calculators:

(04-16-2014 08:23 AM)DavidM Wrote:  The only TI calculator I have is a TI-34 (a 10-digit unit). Here's the results it gave:
a) 3.141592654 SIN: -4.1E-10
b) <pi> SIN: 0

The internal value of \(\pi\) is 3,141592653590 (rounded to 13 digits). Since sin(x) here essentially is \(\pi\) – x = –4,1E–10, this it what you see.
If you use the \(\pi\) key, the internal 13-digit value is entered so that \(\pi\) – x becomes zero.

(04-16-2014 08:23 AM)DavidM Wrote:  Pressing the <pi> key results in the display showing the value 3.141592654 (the same as item a above). But clearly there's a difference. In an attempt to see that difference, I tried the following:
<pi> - 3.141592654 = -4.1E-10

Right. That's 3,141592653590 – 3,141592654. Which agrees with the returned sine value because for the TI-34 \(\pi\) equals 3,141592653590.

(04-16-2014 08:23 AM)DavidM Wrote:  It appears the TI-34 is carrying more digits than it displays for pi.

Sure. It carries 13 digits not just for \(\pi\). Try e¹ – 2,718281828.

(04-16-2014 08:23 AM)DavidM Wrote:  Of those systems, only the TI-34 rounded the final result to 0, and it only did that when I used the special key for pi. Granted, we are focused on calculators here. But the insistence that zero or 0.000000000000 is a more correct answer for sin(3.14159265359) than -2.068E-13 seems to be a TI-specific viewpoint which isn't shared by the other math libraries I am able to compare it to.

All this is due to the way sin(x) is evaluated. As already stated, many (most?) calculators use an algorithm where sin(x) for x so close to \(\pi\) is \(\pi\) – x. If you press the \(\pi\) key, x equals the 13-digit internal \(\pi\) value, so sin(x) = \(\pi\) – x becomes zero. It's that simple. On the other hand, HP's 10-digit devices use their 13 digits only internally, so you cannot enter a 13-digit \(\pi\) value. 3,141592654 is as close you can get – both manually and by using the \(\pi\) key. So the result is always the difference between the 10-digit and the internal 13-digit representation of \(\pi\): –4,1E–10.

Dieter

[Manolo Sobrino]

Joe, I don't know what to do when people just don't read the posts in the thread.

As jebem told us, the TIs 86 and 89 work with pi=3.1415926535898, and all the results I quote are for pi=3.1415926535898. When you press Pi it shows a greek Pi, and if you evaluate that you get 3.14159265359, that's because the display mode of floats in those calculators just shows 12 significant digits.

If you evaluate pi-3.14159265359, you get -2E-13. The values those TIs calculate for sin(pi) are accurate and consistent for a 14 significant digit calculator:

Type sin(pi) or

sin(3.1415926535898)

And you get zero

And the values those same TIs calculate for sin(3.14159265359) are accurate as well: type sin(3.14159265359) and... do you know what you get?

sin(3.14159265359) = -2E-13

That's right. And why is that good here? That's good because these machines work with 14 digit precision, they can give you that.

And why sin(3.14159265359)=-2.06761537357E-13 in the OP's calculator is "wrong" (not really wrong, but rounding pending) and it should show 0E12 instead? Because it comes from a machine with 12 digit precision. It shouldn't know that, because in order to know that you need more than 12 significant digits, actually 25 significant digits. That's my whole point. The "awful consequences" are that you believe that as the result shows 12 significant digits in floating point notation it all makes sense, but that's really a joke that shows the absurd of mixing things up.

And if you can work with 25 significant digits (at least), how come a TI can give you: sin(3.14159265359*(1+1E-11))=-3.16E-11, which is accurate and it's all this thing can get, while the OP's calculator gives you -3.0206761537357*10^-11? Because of rounding 3.14159265359*(1+1E-11)->3.14159265362.

How did you calculate Sin(3.14159265359*10^-12)? Maybe the implementation I'm working with is wrong, but I get (not in a TI) just that, and it should be that because in the Taylor expansion of sin(x), the second term for x=3.14159265359*10^-12 is -(1/6)*3.10063*10^-35... give me a break.

DavidM: Just read the posts in the thread. And yeah, Wolfram Alpha gives you that for "Decimal approximation" and 0E-12 for "Result". Or at least that was what it gave me the day I posted it on this thread.

(edit)



And this is what Pi+ArcSin looks like (it should cross the y axis a little bit upwards, but you get the idea, I don't have time to get the perfect ticks right now). If you round Pi to 3.14159265359 and every other number to 12, what does it mean having a value of Sin of -2.06761537357E-13? Well, according to the significant digits you are considering, no more than you just can say that sin(3.14159265359) is 0E-12.

Maybe it's so obvious for me that I'm just incapable of explaining it to you. At least I hope that you understand now why Wolfram Alpha gives you that 0.*10^-12 "Result".

[Han]

For Manolo -- just three simple questions:

1. When a user computes SIN(1.1) on any calculator (or Mathematica or Maple, etc), what should the calculator return? (Assume radian mode)

2. Same question, this time the user enters SIN(1.10) -- same value but with an extra significant digit. What should the returned result be? (Assume radian mode)

3. How should a real number be implemented so that a calculator can know the difference between 1.1 and 1.10 ?

[Manolo Sobrino]

(04-16-2014 03:09 PM)Han Wrote:  For Manolo -- just three simple questions:

1. When a user computes SIN(1.1) on any calculator (or Mathematica or Maple, etc), what should the calculator return? (Assume radian mode)

2. Same question, this time the user enters SIN(1.10) -- same value but with an extra significant digit. What should the returned result be? (Assume radian mode)

3. How should a real number be implemented so that a calculator can know the difference between 1.1 and 1.10 ?

1)&2)

In a world of perfect calculators I guess that you'll have to type 1.1 for 2 significant digits, 1.10 for three, 1.100 for four, and so on. That is, for instance if we're talking about 1.1*10^-10: 1.1E-10, 1.10E-10, 1.100E-10,... . Now in their default mode they assume that every number you type has 12 significant figures for the HP, 14 for the TI (those that I've discussed). That's OK if you understand what they're doing. BTW, they fill with zeroes and show you the rounded results to N when you work in FIX N mode.

And they should return, if not the multiple precision value according to that (people have no use for too low precision results, really), at least the most accurate value rounded to the significant digits of your input. They already do that in FIX mode.

About 3), I don't know. But the minimum should be that you implement a fixed number of significant digits, and using reasonable algorithms and round where it's due you get results for that number of significant digits, preferably no less, and it would be nice that no more, because it really makes no sense.

[Joe Horn]

Manolo! Good news! I think I figured out a solution to the root cause of our disagreement! (Details below) Meanwhile, back at the ranch...

(04-16-2014 12:29 PM)Manolo Sobrino Wrote:  Joe, I don't know what to do when people just don't read the posts in the thread.

Sorry that I came across that way! I really have read them all, but I think we've been on different wavelengths, or in alternate universes, or something. But I'm trying. ("Yes... very trying." -- my brother Jim)

(04-16-2014 12:29 PM)Manolo Sobrino Wrote:  Maybe it's so obvious for me that I'm just incapable of explaining it to you.

Two quotes come to mind:

Joe, the fact that something is obvious to you does not mean that it is obvious to everybody. -- Richard Nelson, during a friendly debate many years ago.

"Because it's obvious" is not an acceptable mathematical proof. -- Mr. Santo Formolo, my favorite high school math teacher.

(04-16-2014 12:29 PM)Manolo Sobrino Wrote:  At least I hope that you understand now why Wolfram Alpha gives you that 0.*10^-12 "Result".

AHA! (Light bulb lights up!) Try both of these in Wolfram Alpha:

sin(3.14159265359)
sin(314159265359/10^11)

The first one is assumed to be the sine of an approximate value, hence the zero "result" (notice that it does not say "exact result"), rounded the way you've been saying it should be rounded, and you're correct, and nobody has denied that... IFF it's an approximate input.



The second one is assumed to be the sine of an exact value, hence the "exact result" with its humongous "decimal approximation", and even offering a "more digits" button since the result IS exact and has an infinite number of CORRECT digits:



Bottom line: I think we're both right. (yay) You're right that approximate inputs should not yield results with more "precision" than the input (because GIGO), and I'm right that exact inputs do in fact have exact results which can and should be computed. The only difference is that TI ASSUMES the former for sin(3.14159265359), and HP ASSUMES the latter for sin(3.14159265359). Neither assumption is always correct; whether it's correct or not depends entirely on the user's intentions. Hence using EITHER tool correctly requires that the user understand how the tool works and what its assumptions are. Can we agree on at least that much? (I hope so!)

[Manolo Sobrino]

Hallelujah, Joe!

Yes, exactly. It's nice to agree every once in a while

(And now that we're on the same frequency, if you read the posts again you might catch the nuances.)

An inconsistent precision implementation is like using an scalpel to peel tomatoes. If you're a seasoned surgeon you might do wonders with it. If you're not... well, imagine the consequences.

I'd just prefer a consistent precision throughout all the calculations and/or proper rounding. Using your word, I use calculators for "approximate" results and want them accurate, predictable and sound.

I still can't understand how you can have high precision algorithms (BTW, the frequently great 50G behaves this way too) and then don't use that precision for everything else, leaving rounding for the final result. Now that Saturn is gone this ought to be possible. I can understand that in RPN mode this is not so easy to do and introducing, for instance, a visual mark beside the number you got as a result might be puzzling (and awesome), but when you're evaluating an expression, come on, it's all profit.

And then, this particular number "3.14159265359" is not really that interesting to be called on all the time. For instance, "3.1415926535897932384626433832795" is much more appealing

[ColinJDenman]

Quote: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.
....
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)\).)

I do entirely agree that returning a value is wrong. It should say divide by zero, or not a number or "I'm sorry Dave, I can't do that" or some other indicator. I favour the approach that the calculator tells you that your going near its limitations rather than giving a value that can potentially roll through into further calculation. I liked this example because it is a) obviously wrong and b) too big to justify as a small thing like the 2E-13 stuff.

If you wish, "a calculator's gotta know its limitations". Or I need a shotgun:
http://www.hpmuseum.org/forum/thread-1103.html

Your references are indeed interesting. Thanks.