[WP34S] DEG and RAD  diffs

06052014, 12:08 AM
(This post was last modified: 06052014 04:31 PM by pito.)
Post: #1




[WP34S] DEG and RAD  diffs
With WP34S emulator v3.3.3605 and 9degree test (double) you get with DEG mode
Code: DEG mode with RAD mode: Code: RAD mode PS: UPDATE: we do the conversions from 9deg>rad and rad>9deg with the RAD, of course.. (see above) 

06052014, 12:53 AM
Post: #2




RE: DEG and RAD  diffs
In the second case it isn't 9 degrees.
I'd expect a third different result using 9 gradians.  Pauli 

06052014, 06:27 AM
(This post was last modified: 06052014 09:01 AM by pito.)
Post: #3




RE: DEG and RAD  diffs
..including the conversions.. So does a mul/div by a constant introduce such errors?


06052014, 09:16 AM
Post: #4




RE: [WP34S] DEG and RAD  diffs
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 

06052014, 11:12 AM
Post: #5




RE: [WP34S] DEG and RAD  diffs
(06052014 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 builtin hardware and software. Dieter 

06052014, 01:38 PM
(This post was last modified: 06052014 04:39 PM by pito.)
Post: #6




RE: [WP34S] DEG and RAD  diffs
(06052014 09:16 AM)Paul Dale Wrote: ..Do you mean this result? Code: 8.999999999999999999999999999999979 @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. 

06052014, 05:45 PM
Post: #7




RE: [WP34S] DEG and RAD  diffs
(06052014 12:08 AM)pito Wrote: You need to do the conversion in each step, not only when you do the first sin() and after the last acos(). Marcus von Cube Wehrheim, Germany http://www.mvcsys.de http://wp34s.sf.net http://mvcsys.de/doc/basiccompare.html 

06052014, 06:04 PM
(This post was last modified: 06052014 07:20 PM by pito.)
Post: #8




RE: [WP34S] DEG and RAD  diffs
(06052014 05:45 PM)Marcus von Cube Wrote:(06052014 12:08 AM)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). 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). 

06052014, 07:36 PM
Post: #9




RE: [WP34S] DEG and RAD  diffs
(06052014 06:04 PM)pito Wrote: I convert 9degree into radians. 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. Marcus von Cube Wehrheim, Germany http://www.mvcsys.de http://wp34s.sf.net http://mvcsys.de/doc/basiccompare.html 

06052014, 07:57 PM
(This post was last modified: 06052014 08:04 PM by pito.)
Post: #10




RE: [WP34S] DEG and RAD  diffs
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. 

06052014, 09:38 PM
Post: #11




RE: [WP34S] DEG and RAD  diffs
(06052014 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. 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 

06052014, 10:07 PM
Post: #12




RE: [WP34S] DEG and RAD  diffs
(06052014 09:38 PM)Claudio L. Wrote: ..Smaller angles are harder test cases and have more errors on trig function algorithms.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! 

06052014, 10:32 PM
Post: #13




RE: [WP34S] DEG and RAD  diffs
(06052014 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 

06062014, 01:31 AM
Post: #14




RE: [WP34S] DEG and RAD  diffs
(06052014 10:32 PM)Paul Dale Wrote:(06052014 09:38 PM)Claudio L. Wrote: Smaller angles are harder test cases and have more errors on trig function algorithms. 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/2alpha)). I found a way around it by storing the (COSH1) 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 

06062014, 01:51 AM
Post: #15




RE: [WP34S] DEG and RAD  diffs
(06062014 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 

06062014, 06:07 AM
Post: #16




RE: [WP34S] DEG and RAD  diffs
(06062014 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 

06062014, 06:10 AM
Post: #17




RE: [WP34S] DEG and RAD  diffs  
06062014, 06:26 AM
Post: #18




RE: [WP34S] DEG and RAD  diffs
(06062014 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 

06062014, 07:56 AM
(This post was last modified: 06062014 07:58 AM by Paul Dale.)
Post: #19




RE: [WP34S] DEG and RAD  diffs
(06062014 06:26 AM)Paul Dale Wrote: In the 34S I use: 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 

06062014, 08:21 AM
Post: #20




RE: [WP34S] DEG and RAD  diffs
\[\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^x1\) directly without extinction for small x? Cheers Thomas PS: I should probably just have a look at the code. 

« Next Oldest  Next Newest »

User(s) browsing this thread: 2 Guest(s)