Accuracy of Free42 and DM42

[Dieter]

Swiss Micros' DM42 now is available, and its firmware is based on Free42 Decimal. This reminds me of a remark (was it by Thomas Okken himself?), saying that Free42 works with 34 BCD arithmetics, but the implemented algorithms may not always be good for 34 digit accuracy.

So I started my good old 2014 version of Free42 Decimal, and indeed I got some results that were surprisignly inaccurate. For instance sin(45°) and cos(45°). These should equal √½.

Direct evaluation of the latter yields the correct value: 0,7071067811865475244008443621048490
This agrees with Wolfram Alpha and the WP34s.

But sin(45°) and cos(45°) both return 0,7071067811865475727373109293694142
This means only 16 correct digits and 18 digits of "numeric noise". In my Free42 version, that is.

So let me ask two questions:

- Does the above result only say that I'm using an outdated version of Free42 and current versions are more accurate, possibly with true 34-digit accuracy?

- How does the new DM42 behave in this regard?

Dieter

[Massimo Gnerucci]

(12-20-2017 08:16 PM)Dieter Wrote:  Swiss Micros' DM42 now is available, and its firmware is based on Free42 Decimal. This reminds me of a remark (was it by Thomas Okken himself?), saying that Free42 works with 34 BCD arithmetics, but the implemented algorithms may not always be good for 34 digit accuracy.

So I started my good old 2014 version of Free42 Decimal, and indeed I got some results that were surprisignly inaccurate. For instance sin(45°) and cos(45°). These should equal √½.

Direct evaluation of the latter yields the correct value: 0,7071067811865475244008443621048490
This agrees with Wolfram Alpha and the WP34s.

But sin(45°) and cos(45°) both return 0,7071067811865475727373109293694142
This means only 16 correct digits and 18 digits of "numeric noise". In my Free42 version, that is.

So let me ask two questions:

- Does the above result only say that I'm using an outdated version of Free42 and current versions are more accurate, possibly with true 34-digit accuracy?

- How does the new DM42 behave in this regard?

Dieter

my DM42 returns: 0,707106781186547524400844362104849

[Thomas Okken]

(12-20-2017 08:16 PM)Dieter Wrote:  Swiss Micros' DM42 now is available, and its firmware is based on Free42 Decimal. This reminds me of a remark (was it by Thomas Okken himself?), saying that Free42 works with 34 BCD arithmetics, but the implemented algorithms may not always be good for 34 digit accuracy.

So I started my good old 2014 version of Free42 Decimal, and indeed I got some results that were surprisignly inaccurate. For instance sin(45°) and cos(45°). These should equal √½.

Direct evaluation of the latter yields the correct value: 0,7071067811865475244008443621048490
This agrees with Wolfram Alpha and the WP34s.

But sin(45°) and cos(45°) both return 0,7071067811865475727373109293694142
This means only 16 correct digits and 18 digits of "numeric noise". In my Free42 version, that is.

So let me ask two questions:

- Does the above result only say that I'm using an outdated version of Free42 and current versions are more accurate, possibly with true 34-digit accuracy?

- How does the new DM42 behave in this regard?

Dieter

It sounds like you're using an old version, from before I added Werner Huysegoms' angle reduction logic for DEG- and GRAD-mode trigs.

[grsbanks]

My DM42 gives the following for sin(45°)

0.707106781186547524400844362104849

Square it and I get 0.49999999999999999999999999999999999

[Dieter]

(12-20-2017 08:26 PM)Thomas Okken Wrote:  It sounds like you're using an old version, from before I added Werner Huysegoms' angle reduction logic for DEG- and GRAD-mode trigs.

Sure. That's why I wrote "so I started my good old 2014 version of Free42 Decimal". The menu says it's version 1.5.5. It looks like I installed it November 2014. ;-)

When has this new angle reduction logic been added? And why does the angle reduction method make a difference for a 45° angle ?

Dieter

[Thomas Okken]

(12-20-2017 08:36 PM)Dieter Wrote:  

(12-20-2017 08:26 PM)Thomas Okken Wrote:  It sounds like you're using an old version, from before I added Werner Huysegoms' angle reduction logic for DEG- and GRAD-mode trigs.

Sure. That's why I wrote "so I started my good old 2014 version of Free42 Decimal". The menu says it's version 1.5.5. I looks like I installed it November 2014. ;-)

When has this new angle reduction logic been added? And why does the angle reduction method make a difference for a 45° angle ?

Dieter

The change history is here.
Although, on second thought, 18 digits of noise is way too much to be explained by missing angle reduction, especially when the argument is 45°. That sounds more like I was still using a 16-digit approximation of pi, but I don't see mention of that in the change history... I'd have to check the old sources to confirm. Since I'm in bed with a nasty cold right now, that kind of detective work will have to wait.

[Thomas Okken]

I just checked the 1.5.5 source code, and can't see anything wrong with it.
I built and ran it under Linux, and got the expected results, no 18 digits of noise.

[J-F Garnier]

Actually I'm using most of the time the same version 1.5.5 on my every-day computer, and confirm Dieter's observation.
And also:
SIN(30) is ok,
SIN(60) is ok,
SIN(45-1E-30) is accurate at about 1e-32

Seems related to the special value 45°.

And (in RAD mode), SIN(PI/4) is ok.

J-F

[Dieter]

(12-21-2017 03:17 AM)Thomas Okken Wrote:  I just checked the 1.5.5 source code, and can't see anything wrong with it.
I built and ran it under Linux, and got the expected results, no 18 digits of noise.

Strange. I just re-checked the example:
45 SIN 0,5 √x –  =>  4,8336...E–17

And I can confirm what J.-F. said:
45 ENTER 1E-32 – SIN 0,5 √x – => –1 E–34
45 ENTER 1E-32 + SIN 0,5 √x – => +2 E–34

Dieter

[Thomas Okken]

Found it -- the special case for 45° is coded like

if (x == 45) result = sqrt(0.5)

In the decimal case, this sqrt() call needs to be resolved as the Phloat version, not the standard C library double version. Apparently the desired thing happens in most builds, but not in the Windows build, and of course the standard library sqrt() only gives 16 digits of precision.

Do the latest Windows builds also do this? Now that I'm thinking about this, it's kind of odd that this would ever do the right thing. Instead of sqrt(0.5) it should be sqrt(phloat(0.5)).

[toml_12953]

(12-21-2017 08:30 AM)Thomas Okken Wrote:  Found it -- the special case for 45° is coded like

if (x == 45) result = sqrt(0.5)

In the decimal case, this sqrt() call needs to be resolved as the Phloat version, not the standard C library double version. Apparently the desired thing happens in most builds, but not in the Windows build, and of course the standard library sqrt() only gives 16 digits of precision.

Do the latest Windows builds also do this? Now that I'm thinking about this, it's kind of odd that this would ever do the right thing. Instead of sqrt(0.5) it should be sqrt(phloat(0.5)).

So will we see Windows version 2.08 soon?

[grsbanks]

That's interesting.

Free42 decimal V2.0.7 on Windows reports 7.5599E-17 for SIN(45)-SQRT(.5).

The DM42 reports zero.

[Thomas Okken]

(12-21-2017 08:45 AM)toml_12953 Wrote:  So will we see Windows version 2.08 soon?

I'll check the Decimal builds and update the ones where sin(45°) ≠ sqrt(0.5). So far, it sounds like that will include the Windows version, and not the Linux and iOS versions, but I'll check all of them to be sure.

[Thomas Okken]

Done. Only the Windows version needed to be updated.

[Thomas_Sch]

(12-20-2017 08:27 PM)grsbanks Wrote:  My DM42 gives the following for sin(45°)

0.707106781186547524400844362104849

Square it and I get 0.49999999999999999999999999999999999

Sorry, but a possibly stupid question:
how did you all get all the digits out of the calc (or from free42)?

I know [SHOW], but this display is cleared too fast (for me).
I did not manage to do this...
Thank you for an enlightenment!

[Thomas Okken]

(12-21-2017 05:54 PM)Thomas_Sch Wrote:  

(12-20-2017 08:27 PM)grsbanks Wrote:  My DM42 gives the following for sin(45°)

0.707106781186547524400844362104849

Square it and I get 0.49999999999999999999999999999999999

Sorry, but a possibly stupid question:
how did you all get all the digits out of the calc (or from free42)?

I know [SHOW], but this display is cleared too fast (for me).
I did not manage to do this...
Thank you for an enlightenment!

SHOW will keep showing all digits while you keep the [.] key pressed.

Also, in Free42, Copy will copy the X register to the clipboard in full precision.

[Thomas_Sch]

(12-21-2017 05:58 PM)Thomas Okken Wrote:  SHOW will keep showing all digits while you keep the [.] key pressed.

Also, in Free42, Copy will copy the X register to the clipboard in full precision.

Thank you very much!

[salvomic]

(12-21-2017 05:58 PM)Thomas Okken Wrote:  ...
Also, in Free42, Copy will copy the X register to the clipboard in full precision.

thank you!
I'm trying for funny to copy-paste (iOS) from and to Free42 and Prime: a lot (like π) is pasted in the Prime almost ok (changing , with .) with all it digits (then, pressing Enter, Prime cuts the digits beyond 11th, it's normal as at the present it hasn't Longfloat...), instead I copied 1.61803398875 from the Prime and pasting in Free42 I get 161.803.398.875, (with the final comma).
Is it a problem of different pragma (with , and .) or something else?

Salvo

[Thomas Okken]

(12-21-2017 07:19 PM)salvomic Wrote:  I'm trying for funny to copy-paste (iOS) from and to Free42 and Prime: a lot (like π) is pasted in the Prime almost ok (changing , with .) with all it digits (then, pressing Enter, Prime cuts the digits beyond 11th, it's normal as at the present it hasn't Longfloat...), instead I copied 1.61803398875 from the Prime and pasting in Free42 I get 161.803.398.875, (with the final comma).
Is it a problem of different pragma (with , and .) or something else?

You need to set "radix dot" mode: Shift DISP RDX.
SF 28 will do the same thing.

(EDIT: I said "radix comma" first, but you're already in that mode. The radix mode needs to match what you're trying to paste, and apparently your Prime app uses a decimal dot.)

[salvomic]

(12-21-2017 07:53 PM)Thomas Okken Wrote:  You need to set "radix dot" mode: Shift DISP RDX.
SF 28 will do the same thing.

(EDIT: I said "radix comma" first, but you're already in that mode. The radix mode needs to match what you're trying to paste, and apparently your Prime app uses a decimal dot.)

thanks!
Doing so, it works fine both from and to the two apps.