You've Got Mail.........DM42L
02-23-2016, 10:27 AM
Post: #21
 Paul Dale Senior Member Posts: 1,601 Joined: Dec 2013
RE: You've Got Mail.........DM42L
Looks like I've got to revisit the 34S trig functions again...

Try the 31S, it will get this one correct. It has improved trig functions in degrees and gradians. And only single precision

Pauli
02-23-2016, 10:53 AM
Post: #22
 Werner Senior Member Posts: 422 Joined: Dec 2013
RE: You've Got Mail.........DM42L
You will have to do the range reduction in DEG mode still before performing the DEG-RAD conversion, like Free42 does (now). Since that can be done without loss of precision, it will guarantee that equivalent expressions return the same answer.

Range reduction to 45°

Cheers, Werner
02-23-2016, 11:29 AM
Post: #23
 Paul Dale Senior Member Posts: 1,601 Joined: Dec 2013
RE: You've Got Mail.........DM42L
Hmmmm. I'm confused. Too long a day I think.

Working in the 39 digit internal precision.

179.9999 * pi/180 = 179.9999 * 0.0174532925199432957692369076848861271344
gives 3.14159090826054124413306645958873439558

sin(3.14159090826054124413306645958873439558) is
1.7453292519934434807679896054327907935835405E-6

which matches the 34S output.

What am I missing?

- Pauli
02-23-2016, 11:32 AM
Post: #24
 Paul Dale Senior Member Posts: 1,601 Joined: Dec 2013
RE: You've Got Mail.........DM42L
(02-23-2016 10:53 AM)Werner Wrote:  You will have to do the range reduction in DEG mode still before performing the DEG-RAD conversion, like Free42 does (now). Since that can be done without loss of precision, it will guarantee that equivalent expressions return the same answer.

I do do this reduction on the 31S, I didn't add it to the 34S due to flash space limitations.

Maybe I should use the newer code on the 34S too.

I'd planned to revisit all the for the 43S.

- Pauli
02-23-2016, 11:45 AM
Post: #25
 Paul Dale Senior Member Posts: 1,601 Joined: Dec 2013
RE: You've Got Mail.........DM42L
(02-23-2016 10:53 AM)Werner Wrote:  You will have to do the range reduction in DEG mode still before performing the DEG-RAD conversion, like Free42 does (now). Since that can be done without loss of precision, it will guarantee that equivalent expressions return the same answer.

This is the problem. With range reduction I get the same answer as Wolfram Alpha.

Time to port the 31S code to the 34S....

- Pauli
02-23-2016, 11:47 AM
Post: #26
 Werner Senior Member Posts: 422 Joined: Dec 2013
RE: You've Got Mail.........DM42L
(02-23-2016 11:29 AM)Paul Dale Wrote:  Hmmmm. I'm confused. Too long a day I think.

Working in the 39 digit internal precision.

179.9999 * pi/180 = 179.9999 * 0.0174532925199432957692369076848861271344
gives 3.14159090826054124413306645958873439558

sin(3.14159090826054124413306645958873439558) is
1.7453292519934434807679896054327907935835405E-6

which matches the 34S output.

What am I missing?

- Pauli

You lose precision when not performing range reduction..
SIN(3.14159090..) will have lost 6 digits of the result, (because the argument coincides with pi to 6 digits, and the range reduction will happen with radians, so subtracting pi first..) while
SIN(1e-4*pi/180) ends in 9605432786, which is the correctly rounded result.
(where Free42 gives ..787, one ulp off, due to the 34-digit DEG-RAD conversion, I think)

Werner
02-23-2016, 12:07 PM
Post: #27
 Paul Dale Senior Member Posts: 1,601 Joined: Dec 2013
RE: You've Got Mail.........DM42L
Just committed the range reduction code for the 34S. I kept the 34S's higher precision computation of the trigonometric functions since it supports double precision, although I'm not sure this is actually necessary. Now I can do the two examples with correct rounding. Unless I've made an error converting the code, the 34S should be good for trig now

None of this 1ULP off rubbish

Now it is time for bed for me....

Pauli
02-23-2016, 12:09 PM
Post: #28
 Paul Dale Senior Member Posts: 1,601 Joined: Dec 2013
RE: You've Got Mail.........DM42L
(02-23-2016 11:47 AM)Werner Wrote:  You lose precision when not performing range reduction..

I've been through exactly this before with the 31S, why didn't I remember that pain....

- Pauli
02-23-2016, 02:29 PM
Post: #29
 Claudio L. Senior Member Posts: 1,687 Joined: Dec 2013
RE: You've Got Mail.........DM42L
(02-23-2016 10:08 AM)Werner Wrote:  Ah, of course.. ;-)
But then, so does the 34S?
Take this example (in DEG mode)
SIN(180-a) = COS(270+a)
Take a=1e-4
WolframAlpha produces (for both, of course)
1.74532 92519 93443 48076 79896 05432 78633..e-6

Free42 produces (for both)
1.74532 92519 93443 48076 79896 05432 787e-6

the 34S produces
1.74532 92519 93443 48076 79896 05432 791e-6 for SIN
1.74532 92519 93443 48076 79896 05432 778e-6 for COS

BTW Free42 will honour the equality, whatever the value of a you might throw at it.

Cheers, Werner

Got me nervous for a second and I had to try it on my routines.
Happy to report newRPL matches Wolfram Alpha, I also do range reduction in the original argument, then convert to radians.
02-24-2016, 08:17 AM
Post: #30
 Werner Senior Member Posts: 422 Joined: Dec 2013
RE: You've Got Mail.........DM42L
(02-23-2016 12:07 PM)Paul Dale Wrote:  Just committed the range reduction code for the 34S. I kept the 34S's higher precision computation of the trigonometric functions since it supports double precision, although I'm not sure this is actually necessary. Now I can do the two examples with correct rounding. Unless I've made an error converting the code, the 34S should be good for trig now

None of this 1ULP off rubbish

Now it is time for bed for me....

Pauli

Thanks!
One more little tidbit, though:
TAN(a) = -TAN(-a)
but not for a=1e-4 ...
Here a similar range reduction needs to happen (also in Free42 this time).

Something like this: (unverified)

Code:
real function TANDEG(real x)   boolean fNEG := FALSE;   if x<0   then do     x := -x;     fNEG := TRUE;   end;   x := MOD(x,180);            -- [0 180[   if x > 90                -- TAN(x+90°) = -TAN(90°-x)   then do     x := 180 - x;     fNEG := toggle(fNEG);   end;   if x > 80                -- to improve accuracy for x close to 90°   then do     x := 90 - x;     x := TANRAD(x*PI/180);     x := 1/x;   end;   else do;     x := TANRAD(x*PI/180);   end;   if fNEG then x := -x;   return x; end;

- there is no separate test for 45°, as apparently TANRAD(PI/4) = 1, exactly
- the reduction to x<=45° is only done when x>80 so as to not do 1/TAN when it would not be necessary.

Cheers, Werner
02-24-2016, 08:27 AM
Post: #31
 Paul Dale Senior Member Posts: 1,601 Joined: Dec 2013
RE: You've Got Mail.........DM42L
I calculate TAN(x) = SIN(x) / COS(x) so the change to SIN and COS should roll through and it is done in higher precision than usual.

- Pauli
02-24-2016, 10:24 AM
Post: #32
 emece67 Senior Member Posts: 363 Joined: Feb 2015
RE: You've Got Mail.........DM42L
Thanks Paul for the patch. It works perfect and matches Wolfram Alpha. The problem reported by Werner (tan- != -tan) does not happen now.

Regards.

César - Information must flow.
02-24-2016, 12:26 PM
Post: #33
 BarryMead Senior Member Posts: 416 Joined: Feb 2014
RE: You've Got Mail.........DM42L
Paul: Thanks for the significant accuracy improvement to the trig functions.
I recompiled all of my emulators, and re-flashed my calculator to this latest version.

It is comforting to know that my Double Precision results are identical to Wolfram Alpha!

I (we users) appreciate your continued refinement to these already excellent algorithms.

Barry
02-24-2016, 05:54 PM
Post: #34
 mendesp Junior Member Posts: 19 Joined: Oct 2014
RE: You've Got Mail.........DM42L
Thanks for the improvement, but when I compiled the emulator on my pc and tried computing tan(cos(sin(9))), I got this error message.

Run-time Check Failure #2 - Stack around the variable 'x' was corrupted.

Am I doing something wrong ?

Post: #35
 BarryMead Senior Member Posts: 416 Joined: Feb 2014
RE: You've Got Mail.........DM42L
(02-24-2016 05:54 PM)mendesp Wrote:  Thanks for the improvement, but when I compiled the emulator on my pc and tried computing tan(cos(sin(9))), I got this error message.

Run-time Check Failure #2 - Stack around the variable 'x' was corrupted.

Am I doing something wrong ?

When I perform this sequence of trig functions on my emulator I do not get any errors, so I suspect that something went wrong in your emulator compilation process. I compiled my emulators on Ubuntu Linux (386) 14.04 so I doubt that the compiled binary files that I prepared would be of any use to you.
I did observe an error on the REAL CALCULATOR where display shows "Reset" which could indicate a stack overflow on the real calculator when I compiled this version and tried to take the tangent of the value .9999999. Perhaps the two problems are related. The problem seems to occur when the tangent function is asked to evaluate values close to integer whole numbers but only off by a tiny amount like .99999999 or 1.99999999, or 1.000000001 when the angle mode is in Degrees mode. If I had compiled my emulator in Windows, I may have observed the same stack corruption that you discovered, but my emulator was compiled in Linux and it didn't show any errors.
02-24-2016, 09:49 PM
Post: #36
 Paul Dale Senior Member Posts: 1,601 Joined: Dec 2013
RE: You've Got Mail.........DM42L
(02-24-2016 12:26 PM)BarryMead Wrote:  Paul: Thanks for the significant accuracy improvement to the trig functions.

I'd hardly call them a significant improvement -- we provide no assertions as to the accuracy of double precision mode and it was only a few last digits out of the 34 carried -- you could probably navigate across the solar system without missing by anything noticeable

Still correct is better than not.

- Pauli
02-24-2016, 10:40 PM (This post was last modified: 02-24-2016 10:43 PM by Massimo Gnerucci.)
Post: #37
 Massimo Gnerucci Senior Member Posts: 1,980 Joined: Dec 2013
RE: You've Got Mail.........DM42L
(02-24-2016 09:49 PM)Paul Dale Wrote:
(02-24-2016 12:26 PM)BarryMead Wrote:  Paul: Thanks for the significant accuracy improvement to the trig functions.

I'd hardly call them a significant improvement -- we provide no assertions as to the accuracy of double precision mode and it was only a few last digits out of the 34 carried -- you could probably navigate across the solar system without missing by anything noticeable :)

Still correct is better than not.

- Pauli

Just a few nanometers travelling the whole universe... :D

Greetings,
Massimo

-+×÷ ↔ left is right and right is wrong
Post: #38
 BarryMead Senior Member Posts: 416 Joined: Feb 2014
RE: You've Got Mail.........DM42L
Paul:

I have a somewhat unrelated question that came up while I was verifying this latest revision of the REAL calculator does a "Reset" when I try to take the tangent of .9999999 (7-9's). The emulator works perfectly, only the calculator and only the latest version has this issue. Since you made the 3884 revisions, can you point me in the right direction to begin to investigate how?

Which source file changes potentially affected the tangent function?
Can you think of anything unusual about .9999999 that would give me a clue?

I already confirmed that the flash memory was not full.
02-24-2016, 11:08 PM
Post: #39
 Paul Dale Senior Member Posts: 1,601 Joined: Dec 2013
RE: You've Got Mail.........DM42L
Low batteries is the first thing that comes to mind. Try slow mode if you aren't already. I don't know if the new code is faster or slower than the old -- it probably varies both ways depending on the input.

The second thought is that I've blown the stack size on the real device. I've not tried my changes on real hardware but I can't see why 0.9999999 would be special in this regard.

I can't recall anything in Bit's patches that would impact this and tan, but I've not looked at them for quite a while. I believe the function dispatch mechanism was changed but that would show up everywhere and my recent changes wouldn't alter this.

- Pauli
Post: #40
 BarryMead Senior Member Posts: 416 Joined: Feb 2014
RE: You've Got Mail.........DM42L
(02-24-2016 11:08 PM)Paul Dale Wrote:  Low batteries is the first thing that comes to mind. Try slow mode if you aren't already. I don't know if the new code is faster or slower than the old -- it probably varies both ways depending on the input.

The second thought is that I've blown the stack size on the real device. I've not tried my changes on real hardware but I can't see why 0.9999999 would be special in this regard.

I can't recall anything in Bit's patches that would impact this and tan, but I've not looked at them for quite a while. I believe the function dispatch mechanism was changed but that would show up everywhere and my recent changes wouldn't alter this.

- Pauli
I confirmed that is wasn't low batteries via two methods. First I checked the Batt voltage 3.0 and second I ran the test with the USB cable attached which ensures that there is plenty of power.

How would one investigate the stack usage (or increase the stack size) on a real device? I don't own
an ICE debugger for the ARM cpu yet.

My previous flash version was 3870 and it worked(s) fine. I still have some real calculators with that flash version.

Thanks for the pointers. I can always flash the stock realbuild to omit this issue.

I love a good puzzle. Perhaps I will invest in a debugger so I can catch and back trace the anomaly.
 « Next Oldest | Next Newest »

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