[WP-34S] DEG and RAD - diffs

[pito]

With WP34S emulator v3.3.3605 and 9degree test (double) you get with DEG mode

Code:

DEG mode
asin(acos(atan(tan(cos(sin(9.0))))))

8.999999999999999999999999999937535

with RAD mode:

Code:

RAD mode
180.0/pi * asin(acos(atan(tan(cos(sin(9.0 * pi/180.0))))))

8.999999999999999999999999999999979

Is that a feature or a bug?

PS: UPDATE: we do the conversions from 9deg->rad and rad->9deg with the RAD, of course.. (see above)

[Paul Dale]

In the second case it isn't 9 degrees.
I'd expect a third different result using 9 gradians.

- Pauli

[pito]

..including the conversions.. So does a mul/div by a constant introduce such errors?

[Paul Dale]

It isn't so much that a multiplication introduces such a large error, rather it introduces a small error which is then amplified by the subsequent functions.

Consider the gradient of the various functions at the points they are evaluated to get an idea of the magnitude of the error possible. For example, for an argument near zero, SIN will produce a greater error than COS simply because the function is steeper there. In degrees and gradians, 9 is reasonably close to zero. For radians it is heading towards one and a half times around the circle.

Also remember that there is a multiplication before and after each trigonometric function when not in radians. Each potentially introduces a small error.

Also, your result above for radians is completely wrong. It simply isn't possible for the final arcsine step to return a value greater than 2π.

- Pauli

[Dieter]

(06-05-2014 12:08 AM)pito Wrote:  With WP34S emulator v3.3.3605 and 9degree test

As you already said: it's a test for identifying chipsets and algorithms where the input is 9 degrees. So there is not much sense in using this with an input of 9 radians.

Quote:Is that a feature or a bug?

Of course a completely different input leads to a different output. So yes, this is a feature. It is called "accuracy". ;-) In the first example you used 9 degrees, in the second case it's 9 radians = 515,662 (or 155,662) degrees. So already the first step gives completely different results: sin 9° = 0,1564 while sin 9 rad = 0,4121.

I wonder how you got a result near 9 even in radians mode. The inverse trig functions do not return values beyond 2 pi. Trying the "test" in radians mode the 34s returns 0,42477796... Which simply is pi – (9 mod pi).

I hope you do not consider this a test that tells anything about accuracy. It's not, and the reasons have been discussed in detail. This "forensic test" is intended for identifying (especially older) calculators with regard to their built-in hardware and software.

Dieter

[pito]

(06-05-2014 09:16 AM)Paul Dale Wrote:  ..
Also, your result above for radians is completely wrong. It simply isn't possible for the final arcsine step to return a value greater than 2π.
- Pauli

Do you mean this result?

Code:

8.999999999999999999999999999999979

That comes from two independent sources

@Dieter - of course we consider rad/deg conversions here, we do not calculate with 9 radians..
The "radian" test (we've messed with it in the cordic topic) runs in rad mode and does 9deg->rad, then the actual test runs, and then rad->deg.
The "degree" test runs in deg mode, internally it most probably does deg->rad and rad->deg with each trigo function used.
So in the "degree test" there is ~6x more conversions involved than in the "rad test".
I've updated my post above for clarity.

My current understanding is the diff comes mostly from the internal conversions. Considering the internal calcs run 39digit (thus the conversions) it seems to me the diff is rather big.

[Marcus von Cube]

(06-05-2014 12:08 AM)pito Wrote:  

Code:

RAD mode
180.0/pi * asin(acos(atan(tan(cos(sin(9.0 * pi/180.0))))))

8.999999999999999999999999999999979

You need to do the conversion in each step, not only when you do the first sin() and after the last acos().

[pito]

(06-05-2014 05:45 PM)Marcus von Cube Wrote:  

(06-05-2014 12:08 AM)pito Wrote:  

Code:

RAD mode
180.0/pi * asin(acos(atan(tan(cos(sin(9.0 * pi/180.0))))))

8.999999999999999999999999999999979

You need to do the conversion in each step, not only when you do the first sin() and after the last acos().

I convert 9degree into radians.
Then I do the test (all in radians).
After that I convert back to degree to see the 9.0.
So I do not need to do conversion at each step (mind the calc mode is RAD in this test).

In DEG test the calc mode is DEG and I do not need to do any i/o conversion.
There are conversions done internally at each step (I do assume you do it as the trigo is usually in radians in your libs there).

[Marcus von Cube]

(06-05-2014 06:04 PM)pito Wrote:  I convert 9degree into radians.
Then I do the test (all in radians).
After that I convert back to degree to see the 9.0.
So I do not need to do conversion at each step (mind the calc mode is RAD in this test).

I disagree. The whole point about the test is that it feeds values to the trig functions which are prone to digit loss. This only works in degrees mode when every argument to sin, cos or tan is treated as a degree value and every result from the inverse functions is converted back to degrees. This is not the case when you do the conversion just before the first and after the last operation.

[pito]

It means the "less precise" result of the test in DEG mode is caused by the internal conversions rad<->deg as you have described above.
My question is whether the internal conversions (basically multiplication by a constant) done in 39digits may cause such difference in the 34digits test result.

[Claudio L.]

(06-05-2014 07:57 PM)pito Wrote:  It means the "less precise" result of the test in DEG mode is caused by the internal conversions rad<->deg as you have described above.
My question is whether the internal conversions (basically multiplication by a constant) done in 39digits may cause such difference in the 34digits test result.

Not just the pi/180 constant multiplication:

sin(9deg) = "some value" / This first value is the same when you work with radians.

cos(sin(9deg)) --> Since the calc is in degrees, you are actually (internally) doing cos(sin(9deg)*pi/180), which is a completely different value when you run it in radians or degrees, since in one case you are interpreting sin(9deg) as an angle in degrees, and in the other case you are interpreting as an angle in radians.
Now when working in degrees, you are taking the value of the sin() and making it much smaller (pi/180 smaller). Smaller angles are harder test cases and have more errors on trig function algorithms.

So it's very likely the result will have many more changed digits when you run it in DEG mode, and the error doens't come only from the additional conversions, but from the fact that you are using much smaller angles.

Claudio

[pito]

(06-05-2014 09:38 PM)Claudio L. Wrote:  ..Smaller angles are harder test cases and have more errors on trig function algorithms.
So it's very likely the result will have many more changed digits when you run it in DEG mode, and the error doens't come only from the additional conversions, but from the fact that you are using much smaller angles.
Claudio

Yes, that could be the source. Even this "test" seems to me to be a "symmetrical transformation", the symmetry will not compensate for errors coming from the harder cases inside..
Thanks!

[Paul Dale]

(06-05-2014 09:38 PM)Claudio L. Wrote:  Smaller angles are harder test cases and have more errors on trig function algorithms.

Why?

This must depend greatly on the algorithm used.

For example, using a Maclaurin series for the trigonometric functions gives very good results for all of the trig functions for small inputs.


- Pauli

[Claudio L.]

(06-05-2014 10:32 PM)Paul Dale Wrote:  

(06-05-2014 09:38 PM)Claudio L. Wrote:  Smaller angles are harder test cases and have more errors on trig function algorithms.

Why?

This must depend greatly on the algorithm used.

For example, using a Maclaurin series for the trigonometric functions gives very good results for all of the trig functions for small inputs.


- Pauli

Indeed: For very small angles, a couple terms of Taylor gives you great results. The smaller the value the less terms you need.
However, CORDIC accumulate angles from large to small, adding smaller and smaller numbers to bring a target to zero. This is really bad for precision, because it forces you to start adding large terms first that cancel each other. I was able to get good results by starting the loop at a more advanced stage, where angles are in the same order of magnitude as the argument to avoid the large errors. This way I was able to obtain good accuracy on all digits even for small angles, but the price was to triple the storage space since I need calibrated constants to start the loop arbitrarily at any location.
If the implementation doesn't do this, it loses a lot of digits.
There's other cases where this can't be avoided: cosh() for example. The small angles case has a result that's very close to one (you never have this with the normal COS() since you have to calculate sin(PI/2-alpha)). I found a way around it by storing the (COSH-1) instead of COSH (which gives me back the digits when the result is close to one), and also needed extra iterations. Unless you take all those precautions, CORDIC is very prone to error on small angles, and I suspect many implementations in the early days were very crude.

Claudio

[Paul Dale]

(06-06-2014 01:31 AM)Claudio L. Wrote:  There's other cases where this can't be avoided: cosh() for example.

Cosh is easily worked out from the definition: (e^x + e^-x)/2.
For x large (positive or negative), one term dominates. For x small, there are both relevant but of similar magnitude.

Sinh is a completely different beast.


- Pauli

[Thomas Klemm]

(06-06-2014 01:31 AM)Claudio L. Wrote:  However, CORDIC accumulate angles from large to small, adding smaller and smaller numbers to bring a target to zero. This is really bad for precision, because it forces you to start adding large terms first that cancel each other.

This depends on how CORDIC is implemented. It's not a problem with the method used in this article.

Cheers
Thomas

[Thomas Klemm]

(06-06-2014 01:51 AM)Paul Dale Wrote:  Sinh is a completely different beast.

What's the problem with the Taylor series for a small x:


Cheers
Thomas

[Paul Dale]

(06-06-2014 06:10 AM)Thomas Klemm Wrote:  What's the problem with the Taylor series for a small x:

Nothing. I was just noting that the obvious formula:

$$sinh(x) = \frac{e^{x} - e^{-x}}{2}$$

has problems for small x. In the 34S I use:

$$sinh(x) = \frac{e^{x}-1}{2 e^{x}} + \frac{e^{x} - 1}{2}$$

when |x| < 0.5.


- Pauli

[Paul Dale]

(06-06-2014 06:26 AM)Paul Dale Wrote:  In the 34S I use:

$$sinh(x) = \frac{e^{x}-1}{2 e^{x}} + \frac{e^{x} - 1}{2}$$

when |x| < 0.5.

Oops, that's what the comment in the code says but it isn't what's used anymore. Rather it is:

$$sinh(x) = \frac{(e^{x}-1)(e^{x}+1)}{2 e^{x}}$$

for |x| < 0.5. I suspect this version will work for large x too but haven't verified it.

- Pauli

[Thomas Klemm]

\[\sinh(x) = \frac{(e^{x}-1)(e^{x}+1)}{2 e^{x}} = 2\cdot\frac{e^{\frac{x}{2}}-e^{-\frac{x}{2}}}{2}\cdot\frac{e^\frac{x}{2}+e^{-\frac{x}{2}}}{2} = 2\cdot\sinh(\frac{x}{2})\cdot\cosh(\frac{x}{2})\]

How do you avoid infinite recursion?
Or do you calculate \(e^x-1\) directly without extinction for small x?

Cheers
Thomas

PS: I should probably just have a look at the code.