New firmware for the Swissmicros DM15L

[dm319]

This is a really interesting discussion. Albert Chan and I have been discussing privately a lot in my attempts to work out whether the rogue HP-12c is underlying binary or binary-coded decimal.

I would be a very strong advocate for not doing any 'magic' with the numbers. Texas Instruments and Casio do this, and I think it causes more problems than it solves. It is pretend precision. See this link Albert sent me: about the dirty secrets of the TI-83 and TI-84. HP calculators have generally left these type of 1ULP inaccuracies alone (i.e. calculate 1 3 / then 3 *, and subtract 1).

However, I don't think there is anything wrong in withholding the number of returned decimal digits. This is what is done for MS Excel and other spreadsheet programs. Binary generally equates to 15.95 digits of decimal precision (53bits x log10(2)) ~ 16 digits, but this can vary depending on which part of the number line you are on.

Saturn calculators (and the HPs beyond) use decimal precision, and I understand calculate to 15 digits then display only 12 (rounded). I think rounding for the display is reasonable.

For trig functions have a look at this thread which links to an interesting article about inaccuracies in fsin function.

[EdS2]

Just to jump with a strong but defensible position: Because the constant PI on a calculator is never exactly the same value as the mathematical constant pi, sin(PI) should never return zero.

In fact it's better than that: sin(PI) should return, to full precision, very nearly the next set of digits of the constant pi.

For example, sin(3.141592653) is close to 5.8979323e-10

sin(180) should, ideally, return zero.

Arranging for those two things to happen might or might not be so easy.

[Helix]

(10-08-2024 12:17 PM)Johnp_g Wrote:  My thought was "do we need more than 11 digits of precision?

What would happen if answers were rounded to say 11 digits after being calculated with whatever the number of digits is (16? 17?)?

[...]

This seems a reasonable compromise, to limit the displayed precision to 11 digits.

I think I misunderstood your suggestion.
Rounding numbers just for the display could be interesting, as long as f PREFIX still shows 15 digits.
But f PREFIX still wouldn’t work properly with integer powers of negative numbers.

[jebedeo]

Great finds as always gents!

New beta with:

1. Fixed stack lift behavior with delete/backspace interaction
2. g RND bug fixed, now it works up to the full cal precision
3. Combinations, permutations, and the factorial with large inputs don't crash the calculator anymore, thanks for spotting this! It now just return INF

Quote:This is a really interesting discussion. Albert Chan and I have been discussing privately a lot in my attempts to work out whether the rogue HP-12c is underlying binary or binary-coded decimal.

Welcome to the discussion and thanks for the suggestion! I agree that the "tricks" used in some of the TI and Casio calculators are going to do more damage than good. However, I am uncomfortable with having a sin that does not return 0 when the input is 180 degrees.

The problem comes from the fact that the sin() from the math library for c is implemented with rads. Which, as said a couple of posts ago, is not representable in floating point so sin(pi) should not return 0. Fair enough, but that means that unless I play some dirty trick in converting radians to degrees, sin(180) won't return 0.
The math library for ARM microcontrollers that I am using, newlib, doesn't have a sin() function that takes degrees, so perhaps I should implement that myself.

It's interesting because it turns out that the issue with a cube of a negative number returning a small imaginary part (3 CHS ENTER 3 Y^X = -27 + i9.92E-15 in the latest firmware) is due to the sin(pi) not returning 0! The cpow() function in newlib, which computes the power of two complex numbers x ^ y, uses the sin internally. You can imagine that one of the ways you can compute a complex power is by rotating a vector as many times as needed. Well, cpow() as implemented in newlib does just that, but when the power is an integer k, it rotates the vector by k * pi. But since sin(pi) returns almost 0, we get an imaginary part that is almost 0. Annoying, fascinating, add your own adjective

[Werner]

(10-10-2024 05:11 AM)jebedeo Wrote:  However, I am uncomfortable with having a sin that does not return 0 when the input is 180 degrees.

The problem comes from the fact that the sin() from the math library for c is implemented with rads. Which, as said a couple of posts ago, is not representable in floating point so sin(pi) should not return 0. Fair enough, but that means that unless I play some dirty trick in converting radians to degrees, sin(180) won't return 0.

SIN(180°) not returning 0 is indeed, a sin ;-)
You have to do range reduction (to x<=45°) in degrees before converting to radians..
I see that the post about this doesn't show it anymore, so in high-level pseudocode:
For SIN and COS:

real function SINCOSDEG(real x, boolean fSIN)

  boolean fNEG := FALSE;

/* this part IS needed, because eg -4/3 360 MOD loses digits */
  if x < 0
  then do
    x := -x;
    if fSIN then fNEG := TRUE;    -- SIN(-x) = -SIN(x) and COS(-x) = COS(x)
  end;

  x := MOD(x,360);                -- [0 360[

  if x >= 180
  then do
    x := x - 180;                 -- SIN(x+180°) = -SIN(x°) and COS(x+180°) = -COS(x°)
    if fNEG then fNEG := FALSE;   -- toggle fNEG
            else fNEG := TRUE;
  end;
                                  -- [0 180[
  if x >= 90                      -- SIN(x+90°) = COS(x) and COS(x+90°) = -SIN(x)
  then do
    x := x - 90;
    if fSIN
    then fSIN := FALSE;
    else do
      fSIN := TRUE;
      if fNEG then fNEG = FALSE;  -- toggle fNEG
              else fNEG = TRUE;
    end;
  end;
                                  -- [0 90[
  if x = 45 then x := SQRT(0.5);
  else do

    if x > 45                     -- SIN(90°-x) = COS(x) and vice versa
    then do
      x := 90 - x;                -- [0 45[
      if fSIN then fSIN := FALSE;
              else fSIN := TRUE;
    end;

    if fSIN then x := SINDEG(x);
            else x := COSDEG(x);
  end;

  if fNEG then x := -x;

  return x;

end;

For TAN:

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 := x*PI/180;
    x := TANRAD(x);
    x := 1/x;
  end;
  else do;
    x := x*PI/180;
    x := TANRAD(x);
  end;

  if fNEG then x := -x;

  return x;

end;

Cheers, Werner

[raprism]

(10-09-2024 12:34 PM)EdS2 Wrote:  Just to jump with a strong but defensible position: Because the constant PI on a calculator is never exactly the same value as the mathematical constant pi, sin(PI) should never return zero.

In fact it's better than that: sin(PI) should return, to full precision, very nearly the next set of digits of the constant pi.

For example, sin(3.141592653) is close to 5.8979323e-10

sin(180) should, ideally, return zero.

Arranging for those two things to happen might or might not be so easy.

If you have n digits, e.g. n = 15, and you're very keen on showing deviations due to incomplete rounding, then use this:

Code:


In []: [round(sin(round(pi,n)),n+1) for n in range(10, 16)]
Out[]: [-1e-11, -0.0, -2e-13, -1e-14, 3e-15, 1e-16]

If you have a calculator that shows 12 digits, but use internally 15, it should be not worse like this:

Code:


In []: round(sin(round(pi,15)),15-1)
Out[]: 0.0

This is Python code (requires "from math import pi, sin" on top).

If you show less digits than used internally, it should be always "0.0", e.g "0.000000000000" up to shown digits.

[Helix]

(10-10-2024 05:11 AM)jebedeo Wrote:  2. g RND bug fixed, now it works up to the full cal precision

Only in FIX mode!
For example, with SCI 4:
7 1/x g RND rounds to 1.4290E-1 instead of 1.4286E-1

With SCI 11:
π 1000 * g RND does nothing.
π 1E9 / g RND rounds to 3.14E-9

Same problem with ENG mode.

[dm319]

(10-10-2024 05:11 AM)jebedeo Wrote:  The problem comes from the fact that the sin() from the math library for c is implemented with rads.

Ah, I get you now.

The Intel decimal library only uses radians for trig functions too, but range reduction in plus42/free42 is done in degrees (see the sin_or_cos_deg() helper function), which subtracts 180 in this situation.

D

EDIT: Ah I see Werner has described exactly that code!!

[jebedeo]

Quote:Only in FIX mode!
For example, with SCI 4:
7 1/x g RND rounds to 1.4290E-1 instead of 1.4286E-1

It should be fixed now, thanks for catching this!

Thank you all for the input about the precision and how to handle sin() and range reduction. I am working on it.

[Johnp_g]

A new one?

Strange FIX with negative number behaviour

I was in FIX02 mode (doing some money calculations) and one result was

-0.05

but it displayed as

-5.00E-2

Closer inspection shows that if there's a single digit, in the final decimal place of FIXnn (with zeros in other positions) and the number is negative it displays in SCI notation..

FIX02

0.01
ENTER
CHS

displays as -1.00E-2

0.11
ENTER
CHS

displays as

-0.11

ONLY when the only digit (all others are zero) is in the "last" position does this occur for negative numbers.

FIX05

0.00001
ENTER
CHS

displays as -1.00000E-5

Otherwise I haven't spotted anything else, but not having a lot of time to dig too deeply at the moment, just using the latest firmware in daily life and seeing what oddities pop up,



Cheers,

John

[jebedeo]

Hi All,

Here's another beta:

1. Fixed the display issue with negative numbers with a non-zero last digit, in FIX mode (thank you John!).
2. Added support for SOLVE give it a go and let me know what you think. It uses the secant method, so nothing fancy but it gets the job done. It works only for real numbers though. I am not sure if the original 15C supported solving for complex functions, but my understanding is that is not an easy task. But then again, I am not a mathematician.

I am still working on the issue of precision and the fact that sin(pi) and sin(180) don't return a zero. It's frustratingly complicated but it's amazing to see what experts do and to learn how precision in floating point works. Lots of fun.

Cheers!

[Johnp_g]

A minor display format bug..

A complex number in Polar format generally shows up to 5 decimal places (for FIX5 and above).

If the the angle is negative the angle displays with 4 digits (not decimal places, total digits).

eg (on Polar mode)

1 ENTER
60 CHS
f I

displays as
1.00000 <-60.00

whereas

1 ENTER
60
f I

displays as

1.00000 <60.0000

if the angle is eg. 120 degrees

1 ENTER
120 CHS
f I

displays as

1.00000 <-120.0


four digits, and only one decimal place.

for a simple R->P conversion

in Rect mode, FIX 6

4 enter 3
f I

4.00000 + i 3.00000

g P (to polar)

5.00000 < 38.8699

but for (back in Rect mode)

4 enter 3 CHS
f I

4.00000 - i3.00000

g P (to Polar)

5.00000 <-36.87

only four digits / 2 decimal places for the angle.

A minor niggle, but for consistency it would be nice to keep the same displayed decimal places for negative angles.

Otherwise - I'm exploring the new Solver and so far it works on all my tests - I've tried the simple examples in the HP15C handbook too. I don't think the HP15C handled complex numbers in the solver either, but someone else may have more knowledge.

Cheers,

John

[Helix]

I’ve found other minor inconsistencies in display format for real numbers.

With FIX 13:
7 1/x gives 0.1428571428571 so as expected 13 digits after the period.
But then CHS gives -0.142857142857 so only 12 digits.

With FIX 14, negative numbers are still displayed with 12 digits.

With SCI 10, we have -1.428571429E-1 so only 9 digits after the period.
With SCI 11, we have the same display.

The same problem occurs with ENG mode.

There is perhaps a more serious problem with ENG mode: it sets the number of digits after the period, whereas in the HP15C it sets the number of significant digits.
For example in ENG 4 mode, 7 1/x is displayed 142.8571E-3, whereas the HP15C displays 142.86E-3
This affects the result of a subsequent RND function.

[Helix]

(10-15-2024 05:59 AM)jebedeo Wrote:  I am still working on the issue of precision and the fact that sin(pi) and sin(180) don't return a zero.

As mentioned by EdS2 above, sin(PI) should not return 0.
The HP 15C, the HP 50g, and Free42, either decimal or binary, don’t return 0 for sin(PI).

[naddy]

(10-15-2024 05:59 AM)jebedeo Wrote:  I am not sure if the original 15C supported solving for complex functions

It does not. You can run SOLVE in complex mode, but the solver algorithm will only consider the real part of the result. Same for INTEG. Interestingly, there are use cases for this.

[Helix]

(10-10-2024 05:11 AM)jebedeo Wrote:  3. Combinations, permutations, and the factorial with large inputs don't crash the calculator anymore, thanks for spotting this! It now just return INF

For permutations and combinations, the HP15C accepts Y numbers up to 9999999999, and your firmware up to 170 only.

[Commie]

(10-09-2024 08:31 AM)dm319 Wrote:  I would be a very strong advocate for not doing any 'magic' with the numbers. Texas Instruments and Casio do this, and I think it causes more problems than it solves. It is pretend precision

I take it, you are a IEEE-754 single,double or quad fan?

The Swissmicro's is the only calculator manufacturer to implement the above, whilst every other manufacture has(for decades) is or using BCD. In fact, the financial institutions worldwide insist on only using BCD.

All compilers available for PIC's,AVR's and 8051 and ARM mcu support only IEEE-754 floating point formats. Just imagine if these compilers supported bcd floating point? It would wipe out the entire low end calculator market almost immediately.

And yes, you guessed it right, IEEE-754 is biggest pile of crap that ever appeared on planet earth.

[Nigel (UK)]

(10-16-2024 05:29 PM)Commie Wrote:  All compilers available for PIC's,AVR's and 8051 and ARM mcu support only IEEE-754 floating point formats. Just imagine if these compilers supported bcd floating point? It would wipe out the entire low end calculator market almost immediately.

I’m not sure what you are saying here. The compilers people use are C compilers and so they can support not just BCD but even Roman numerals if given the correct code to compile, as C is a Turing-complete language. All of the major DM42 projects do support decimal arithmetic: Free42 uses the Intel Decimal library, C43/7 use decNumbers, db48x uses a variable precision decimal library written by the author (as well as allowing machine precision binary numbers for speed). The Intel and decNumber libraries are IEEE-754 compliant but they are still decimal libraries.

What’s the problem with this?

Nigel (UK)

[Commie]

(10-16-2024 07:21 PM)Nigel (UK) Wrote:  What’s the problem with this?

Nigel (UK)

Hi Nigel,

Please tell me which c compilers are available that support bcd floating point format, i.e., not ieee 754 fp.

According to the Swissmicros website, they deploy ieee754 quad 128bit fp in all their calculators.

[rprosperi]

(10-16-2024 10:03 PM)Commie Wrote:  

(10-16-2024 07:21 PM)Nigel (UK) Wrote:  What’s the problem with this?

Nigel (UK)

Hi Nigel,

Please tell me which c compilers are available that support bcd floating point format, i.e., not ieee 754 fp.

According to the Swissmicros website, they deploy ieee754 quad 128bit fp in all their calculators.

Where do you see that, it's simply not the case?