You've Got Mail.........DM42L

[Paul Dale]

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

[Werner]

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

[Paul Dale]

Hmmmm. I'm confused. Too long a day I think.

Working in the 39 digit internal precision.


Convert 179.9999 to radians:
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

[Paul Dale]

(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

[Paul Dale]

(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

[Werner]

(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.


Convert 179.9999 to radians:
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

[Paul Dale]

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

[Paul Dale]

(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

[Claudio L.]

(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.

[Werner]

(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

[Paul Dale]

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

[emece67]

Thanks Paul for the patch. It works perfect and matches Wolfram Alpha. The problem reported by Werner (tan- != -tan) does not happen now.

Regards.

[BarryMead]

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

[mendesp]

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 ?

Thanks for your help.

[BarryMead]

(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 ?

Thanks for your help.

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.

[Paul Dale]

(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

[Massimo Gnerucci]

(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

[BarryMead]

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.

[Paul Dale]

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

[BarryMead]

(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.