New firmware for the Swissmicros DM15L

[Johnp_g]

(10-04-2024 06:29 AM)jebedeo Wrote:  Hey guys, here's another beta. Not much to it, just the f CLEAR PREFIX fixed.

For example, sqrt(2) = 1.41421356237309504880... but if you do it with this firmware and use f CLEAR PREFIX you will see "X: 1414213562373095168. ", so the first 16 digits are correct, and after that it's just noise. So perhaps that's all the calculator should show. I'll read up on floating point numbers a bit more, but for right now know that you can't trust all those digits

My thought is that the 16 "accurate" digits is all that should be displayed, as the trailing noise digits add nothing and could mislead.

For example, using a number that makes the noise visible

Code:


1 
ENTER
6
/

This displays as 1.667 in FIX4 and fPREFIX shows

1666666666666666496

The trailing 496 is obviously garbage, and should be hidden.

For a number like PI, e or SQRT2 or any calculation result with many digits, it's not so obvious, as the digits may have no obvious pattern.

You don't want to be seduced into thinking "the 18th digit of PI is 8" because my calculator is super precise and accurate. Curtailing at 16 digits gives confidence that everything shown is correct.

If it costs too much in terms of code size, to add the extra code to curtail at 16 digits, then saving memory and the ability to add the Solver (and Integrate) should take precedence, and fPREFIX left with the user to disregard the last few digits themselves.

Thanks for all you've done so far. My DM15L was largely unused as it was mostly a curiosity for me to have a modern "HP15C".The complex number handling, archaic programming display of keycodes and the sedate speed meant I had better, if larger and more expensive, calculators to use. Now the DM15L has been given a new lease of life and is useful for pretty much anything I need in day to day life, at work or in my other hobbies. And the Voyager form factor is cool, so that it's great to carry it around everywhere. I'm very happy to have this firmware to pep up my forgotten DM15L.

Cheers,

John

[Johnp_g]

I don't know if I should mention this....

I've never used Hyperbolic trig functions on any calculator in the past, it's just something that's never been necessary for me.

I thought I'd look at hyperbolics on LF15C and I think there's a bug.

My first random test was to find

fHYP SIN of 23 and I got the result 4872401723.1245 which appears to be correct.

Finding the inverse :

gHYP-1 SIN

gives INF +iNAN

the same for inverse of the Hyp sin of 21 and 20 and it appears for any angle greater than 23 too.

in FIX04 mode:

fHYP SIN of 19 gives 89241150.4816 and the inverse gHYP-1 SIN gives 18.0218

fHYP SIN of 18 gives 32829984.5687 and inverse gHYP-1 SIN also gives 18.0218

fHYP SIN of 17 gives 12077476.3768 and inverse gHYP-1 SIN gives 17.0102

fHYP SIN of 16 gives gives 4443055.2603 and inverse gHYP-1 SIN gives 15.9986

fHYP SIN of 15 gives 1634508.6862 and inverse gHYP-1 SIN gives 14.9999

fHYP SIN of 14 gives 601302.1412 and inverse gHYP-1 SIN gives 14.0000 (fPREFIX > 1399996882332322304)

fHYP SIN of 13 gives 221206.6960 and inverse gHYP-1 SIN gives 13.0000 (fPREFIX > 1299999133517606936)

I don't know if anyone would find these problematical - I certainly wouldn't - but it does appear to be buggy.

My HP35s calculates Hyp Sin of 23 and its inverse correctly, as does my DM32.

I haven't found issues with HYP COS or HYP TAN yet

Cheers,

John

[Johnp_g]

Just noticed an odd stack-handling issue when using < to backspace over/clear an entry currently being made in x


1
enter (puts 1 in y and 1 in x)
23 (begin typing a new value in x)
< (clear the 3)
< (clear the 2)

this will delete the 2 digits currently in the x buffer but it leaves 1 in y AND puts 1 in x too.

The usual behaviour is to clear x (to 0.00).

Remembering to press < a third time works, by clearing the erroneous X value, but it's not intuitive when you're used to "normal" behaviour.

Cheers,

John

[Helix]

(10-04-2024 06:29 AM)jebedeo Wrote:  f CLEAR PREFIX now shows all the precision that we can fit in the display. I am not sure how many significant digits is too many. To display the mantissa I simply multiply or divide by 10 until the integer part of the number to display has 18 digits. So the original floating number will multiply as much as you want, if the display was long enough you could display 100 digits but that would clearly not make sense.

For example, sqrt(2) = 1.41421356237309504880... but if you do it with this firmware and use f CLEAR PREFIX you will see "X: 1414213562373095168. ", so the first 16 digits are correct, and after that it's just noise. So perhaps that's all the calculator should show. I'll read up on floating point numbers a bit more, but for right now know that you can't trust all those digits

Thank you for the update!
Currently, f PREFIX displays 19 digits.
At first, I had a different opinion than John about the number of displayed digits.
Being able to see more digits than the typical precision of the calculator allows to understand why 0.1 * 3 is different from 0.3. I imagine this could be helpful in debugging some programs.

But after playing a while with this function, I see that it’s more complicated than I thought.
0.1 f PREFIX displays 100000000000000000.
But 0.1 3 * f PREFIX displays 1000000000000000512. which is a nonsense. In fact, even 100000000000000000. for 0.1 is misleading!

So, I think that the best solution is probably to avoid more confusion, and to stick with 16 digits.

[Helix]

Here are some observations, which are not necessarily bugs.

In Program mode, a long press on GTO followed by a non-existing line number displays two identical lines.
For example: f LBL A SIN long press GTO 2 shows two lines "1 LBL A". This is a bit strange.

In Program mode, I would like to be able to jump to a label. I imagine for example a long press on GSB, which after a second would display "Jump to LBL:__"
I know this feature isn’t available on the HP 15C. The alternative is to switch to Run mode, Go To the desired label, and then return to program mode, so this adds 4 keystrokes.
Given the memory limitation, I'll let you decide if it's worth it.

On the HP 15C, f CLEAR Σ also clears the stack. I don’t need this function, but I wonder if it shouldn’t be implemented for compatibility reasons.

y^x when y is negative and x is an integer gives a complex number.
There is nothing wrong here, as the imaginary part is very small, and it’s easy to change the result into a real number with g ABS for example.
On the other hand, that implies that every polynomial evaluated on a negative number results in a complex number, and this is not what we expect. Perhaps a modification is necessary for y^x?

[Helix]

(10-04-2024 05:01 PM)Johnp_g Wrote:  Just noticed an odd stack-handling issue when using < to backspace over/clear an entry currently being made in x


1
enter (puts 1 in y and 1 in x)
23 (begin typing a new value in x)
< (clear the 3)
< (clear the 2)

this will delete the 2 digits currently in the x buffer but it leaves 1 in y AND puts 1 in x too.

The usual behaviour is to clear x (to 0.00).

It's an old bug that has reappeared!

[jebedeo]

As always, thank you for the bug finding!

Here's what's fixed in the new beta:

1. f CLEAR PREFIX now shows the mantissa of the number, limited to 15 digits since that is the decimal digits for double float in c, as per float.h constant DBL_DIG. The precision can be 16 but in the worst case scenario is 15 digits, so that's what we are using. The display behavior was changed a bit to make sure that we never show more than 15 digits,as to not fool the user into thinking there is more information there rather than noise.
2. Entering a number and then cancelling now correctly clears the X register. It was indeed an old bug that came back to say hello.
3. in program mode, long press GTO/GSB brings up "go to label" and "go to line", respectively. In run mode, a single press brings up that menu since we cannot insert the operation. Thank you for the suggestion Jean-Charles, that's a great feature to have and makes the life easier for the user.
4. CLEAR SIGMA now clears also the stack, thanks for pointing that out
5. The bug with the hyperbolic sin/asin is fixed, great find!
6. Fixed the bug with the same line displayed twice when after a "go to line" to a non existent line number

Quote:Thanks for all you've done so far. My DM15L was largely unused as it was mostly a curiosity for me to have a modern "HP15C".The complex number handling, archaic programming display of keycodes and the sedate speed meant I had better, if larger and more expensive, calculators to use. Now the DM15L has been given a new lease of life and is useful for pretty much anything I need in day to day life, at work or in my other hobbies. And the Voyager form factor is cool, so that it's great to carry it around everywhere. I'm very happy to have this firmware to pep up my forgotten DM15L.

That warms my heart John! I started writing this cause the DM15L was awesome but as I was starting to learn RPN through it I kept wondering why it couldn't show both X and Y and I thought "maybe I can modify the firmware" turns out there are way more features that would make life easier, and thanks to you guys for pointing so many out!

Quote:y^x when y is negative and x is an integer gives a complex number.
There is nothing wrong here, as the imaginary part is very small, and it’s easy to change the result into a real number with g ABS for example.
On the other hand, that implies that every polynomial evaluated on a negative number results in a complex number, and this is not what we expect. Perhaps a modification is necessary for y^x?

Ugh this is a bit weird. This is due to how the complex power is implemented on the math library for the arm compiler, newlib. On a desktop machine the same C code doesn't return a small error in the imaginary part, since that math library uses a different algorithm. I gotta do some more research on this because it's not technically a bug of the math library, rather that's the error that comes with floating point numbers. And here is the part where I am not sure how to proceed cause I don't know enough about floating point. You could round the result of intermediate operations to try and avoid these types of errors, but is that rounding going to introduce more error in unexpected ways? I got some homework to do...

[Johnp_g]

(10-06-2024 07:09 AM)jebedeo Wrote:  5. The bug with the hyperbolic sin/asin is fixed, great find!

It doesn't seem to be fixed!

I still get the same behaviour as described in my initial bug report for HYP SIN.

I thought I'd possibly loaded the previous version by accident, but I see the new fPREFIX behaviour is working, the "stack handling on clear" issue is fixed, so I have certainly loaded beta241005

Looks like the HYP SIN fix didn't make it to the firmware you released. No show stopper for me, though. What do people use Hyperbolic trig for anyway?

Good work on everything else.

The issue of tiny imaginary parts in results, such as in -8^3 where the imaginary part should be zero is a bit of a nuisance, and it would be nice to have a fix.

Not the same thing, I think, but in my exploration of cube roots of negative numbers (i.e. -8) I see:

8 CHS
ENTER
3
1/x
y^x

result (correct): 1.0000 + i1.7321

If I then ENTER ENTER and multiply by itself twice (X X)

the result is

-8 + i3.11E-15

the tiny imaginary part shouldn't be there, of course.

However using the Binary version of Free42 on my PC I see exactly the same result there, so Thomas has left it and not tried to supress the small imaginary part, which I presume is just a rounding/precision issue as you're starting with an irrational complex part, with a certain amount of "Noise"

The C47 has an option to supress results below a certain size, say 10^-30, but given its 34 digit precision this seems reasonable. With only 16 digits would you want to supress small results below say 10^-14 ? probably not, as it's conceivable someone might be working with numbers of this magnitude on purpose. Of course in the C47 this behaviour can be turned off if necessary. You don't really have the ability to offer (yet?) user selectable options.

In Jean-Charles example of a simple integer power of a negative number eg -8^3

8 CHS
ENTER
3
y^x

we get -512.000 + i1.88E-13

Free42 (Binary version) gives simply -512, so in this instance the tiny imaginary part is not present, or is somehow suppressed in the results.

Regards,

John

[jebedeo]

Thanks for pointing that out John, it was a bug inside a bug lol!

It seems like there might be a bug in newlib's implementation of the complex hyperbolic arc sine, casinh(). To get around it I am computing it a different way so in this new firmware it should be fixed, and we'll see what the developer of newlib say about my bug report, maybe I am using it wrong.

I also added a fun new feature to this beta: f CLEAR PREFIX in program mode now insert a new operation which is called "runTime". It puts the current program run time, in seconds, into the X register. The precision is 1ms. This way you can stop a program after a fixed amount of time, or simply report how long it took to execute stuff. It runs off of the MCU's internal clock which by data sheet has a precision of 1%.

Quote: The issue of tiny imaginary parts in results, such as in -8^3 where the imaginary part should be zero is a bit of a nuisance, and it would be nice to have a fix.

I agree. Thanks for pointing out the behavior of free42. I quickly looked at their code for y^x and it seems they do quite a bit of checking the nature of the operands in there, like if they are integers, if they are smaller than a certain amount, and they run different algorithms depending on that, to increase precision. Perhaps I could do something like that, but I am afraid it's going to turn into a game of whack-a-mole of corner cases that would lead to a lot of memory usage. Perhaps I am missing something else. I will keep on researching, thanks for the input!

[Johnp_g]

(10-07-2024 02:00 AM)jebedeo Wrote:  Thanks for pointing that out John, it was a bug inside a bug lol!

I also added a fun new feature to this beta: f CLEAR PREFIX in program mode now insert a new operation which is called "runTime". It puts the current program run time, in seconds, into the X register. The precision is 1ms. This way you can stop a program after a fixed amount of time, or simply report how long it took to execute stuff. It runs off of the MCU's internal clock which by data sheet has a precision of 1%.

The HYP ASIN works properly now. Perhaps I need to learn what it's used for now ;-)

I like the new runTime feature - very handy for benchmarking, in the absence of any inbuilt time-calculation functions. I'll check the various benchmarks using it.

Sorry the y^x is looking to be a troublesome beast. Can you not just catch the one case of "when Y is real and negative and X is an integer then the IMAGINARY part of the result = 0" and not get too involved beyond that? Or am being too naive?

John

[Helix]

(10-06-2024 07:09 AM)jebedeo Wrote:  6. Fixed the bug with the same line displayed twice when after a "go to line" to a non existent line number

Thank you again for the improvements.
With "Go To Line: n" when n isn’t a valid line number, the lines displayed are n-2 and n-1. This is not very important, but I would rather expect to see the lines n-1 and n+1.

I’ve noticed some difficulties with very small numbers.
When the absolute value is inferior to 1E-294, f PREFIX doesn't work. As no real problem involves such tiny numbers, I can’t say it’s a concern.

1E-312 is displayed 10.0000E-313, same problem with 1E-314, 1E-315, and so on.

1E-323 cannot be displayed correctly.

I suspect that the last two cases are related to subnormal numbers (numbers with the minimum exponent, and with leading zeros in the mantissa). Most calculators don’t bother with subnormal numbers, but since you use an existing library, I suppose you have no choice.
Don’t try to fix that is this requires too much memory space.

[Johnp_g]

(10-07-2024 05:56 AM)Johnp_g Wrote:  I like the new runTime feature - very handy for benchmarking, in the absence of any inbuilt time-calculation functions. I'll check the various benchmarks using it.

I've just run the n-Queens benchmark (for 8 queens) and runTime gives me : 1.317 seconds.

That's pretty fast, I think.

And the SAVAGE benchmark took a reported 5.9510 seconds which is also pretty fast.

Using runTime takes away the uncertainty and error from manually timing with a stopwatch and makes the times easier to compare to calculators that can also self-time the operation.

Cheers,

John

[Helix]

f Py,x and g Cy,x leave the Y-register unchanged. The content of both X- and Y-register should disappear, as for + or * .

1 ENTER 2 ← RCL n (or RCL f #RAN) lifts 1 in the Z-register, and leaves 0 in the Y-register. 1 should remain in the Y-register.

[jebedeo]

Here's a new beta:

Quote:f Py,x and g Cy,x leave the Y-register unchanged. The content of both X- and Y-register should disappear, as for + or * .

1 ENTER 2 ← RCL n (or RCL f #RAN) lifts 1 in the Z-register, and leaves 0 in the Y-register. 1 should remain in the Y-register.

Fixed and fixed, thanks!

Quote:With "Go To Line: n" when n isn’t a valid line number, the lines displayed are n-2 and n-1. This is not very important, but I would rather expect to see the lines n-1 and n+1.

That's a good point, I fixed it.

Quote:I’ve noticed some difficulties with very small numbers.

Good catch. I added it to the list of things to look into, I think at some I gotta decide how to deal with subnormal numbers rather than letting the C compiler decide.

Quote:Can you not just catch the one case of "when Y is real and negative and X is an integer then the IMAGINARY part of the result = 0" and not get too involved beyond that? Or am being too naive?

I could, but my worry is that there will be an endless amount of similar checks that need to be sprinkled around. For example, g PI SIN does not return 0, but 1.2246E-16. I should also add a check for that function. cosine and tangent behave similarly, it all comes from the fact that the value for pi has only so much precision, and the built in trig functions don't check for that. Before I start adding as many as these sanity checks as I can find, I want to make sure that I am not missing something more obvious on how floating point works.

[Johnp_g]

(10-08-2024 12:26 AM)Helix Wrote:  f Py,x and g Cy,x leave the Y-register unchanged. The content of both X- and Y-register should disappear, as for + or * .

While playing with Py,x I tried

12
ENTER
12
fPy,x

this gave

y:12.0000
x:479001600.000

as Jean-Charles noted, the y register remained rather than being cleared.

I then used

x<>y

to give

y:479001600.00
x:12

and then again

fPy,x

the calculator appeared to hard crash - freezing display and no response from keyboard. I had to use RESET button.

Further investigation shows that any numbers that would (on a real HP15C) cause overflow (flashing 9.99999999 99) that can simply be cleared with <- cause the LF15C to appear to hard crash instead.

I tested with

2E6
ENTER
1E3
fPy,x

and again it appears to hang/crash, but after about 50 seconds it does actually return "NaN"

The stock DM15L returns flashing 9.9999999 99 immediately, does it do some quick sanity check first?

Cheers,

John

[Johnp_g]

(10-08-2024 06:36 AM)jebedeo Wrote:  For example, g PI SIN does not return 0, but 1.2246E-16.

The HP16C and DM15L return -4.102069E-10 for SIN of PI radians and the DM42 returns -1.158E-34 and not zero, so is it safe to not worry about these tiny but not zero results for this kind of calculation?

Returning a complex number for the cube of -3 is more annoying, as we aren't expecting a complex number, but a "precision" error returning a small number instead of zero, especially when the basic HP15C isn't perfect in this regard is sort of normal behaviour?

[EDIT.... ]
Ah, I see that even in degree mode 180 SIN still returns 1.2246E-16 which isn't the case for HP15C. So, yes, perhaps it's more difficult than I hoped.


Cheers,

John

[Johnp_g]

Hi again

I was pondering the "small results that should be zero" problem - and the "erroneous imaginary part" in a Y^X for negative number to an integer power.

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

As an example

fFIX 14
180
SIN (1.2246467991E-16)
fFIX 11 (1.2246467991e-16)
gRND

Now we have 0.00000000000

or

fFIX 14
3
CHS
ENTER
3
y^x ( -27.0000 + i9.92E-15)
fFIX 11
gRND

now we have -27.00000000000

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

A new BUG became apparent while I was checking this idea.......

I notice though that the FIX and RND function do some strange things.

fFIX 14
g PI

3.14159265358979

gRND

3.14159265353419

We're rounding to the number of digits set by FIX - i.e. 14 - but the last 4 digits of PI change after using gRND

fFIX 9

3.141592654

gRND

3.141592654

now expand digits to fFIX 14

3.14159265400000

this is correct.

Odd things happen when gRND is used on numbers with FIX greater than 9

when FIX is 10 and gRND is used the final displayed digit changes, when FIX is 13 and gRND is used the final 3 digits change.

Nothing should happen except the number being rounded to the number of digits specified in FIX, then if FIX is expanded to a greater number of digits we should see the new digits are zero.

This happens if FIX is 9 when gRND is used, but not if it's greater than 9.

I'm confusing myself now, so I'll just leave it here and see if you or Jean-Charles have any comments.

John

[Johnp_g]

(10-06-2024 07:09 AM)jebedeo Wrote:  2. Entering a number and then cancelling now correctly clears the X register. It was indeed an old bug that came back to say hello.

It's only partially fixed :-(

start with a clear stack, all zeros. Enter 21 into X and then start typing 23 but clear it with two Clr presses

21
ENTER
23
<
<

this now correctly leaves :

y:21
x:0

now type a new number (eg 42) into x and the 21 remains in Y, the zero in x is overwritten by the new value 42, as expected.

y:21
x:42_

multiply

[X]

Y:0
X:882

the value in X is there due to a completed calculation....

now start typing a new number (65)

Y:882
X:65_

but it's wrong so backspace

<
<

clears X to 0 as expected

now type the correct number 76

Y:0
X:76_

the 882 from Y has been raised into Z and the 0 from X is raised into Y when a new number is typed into X

this is wrong, the stack shouldn't lift the zero into Y. The error happens if the number in Y is there as a calculation result. When it's there due to user typing it in the backspace/clear behaviour is correct.

John

[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?)?

I would disagree with this solution. Reducing the precision from 16 to 11 digits just to avoid tiny errors is not a good compromise in my opinion.
I’m not disturbed by the fact that sin(180°) produces an error of 1.22e-16, but I think more like a physicist than a mathematician.

[Helix]

(10-08-2024 06:36 AM)jebedeo Wrote:  

Quote:Can you not just catch the one case of "when Y is real and negative and X is an integer then the IMAGINARY part of the result = 0" and not get too involved beyond that? Or am being too naive?

I could, but my worry is that there will be an endless amount of similar checks that need to be sprinkled around. For example, g PI SIN does not return 0, but 1.2246E-16. I should also add a check for that function. cosine and tangent behave similarly, it all comes from the fact that the value for pi has only so much precision, and the built in trig functions don't check for that. Before I start adding as many as these sanity checks as I can find, I want to make sure that I am not missing something more obvious on how floating point works.

I think that the question is not not how floating point works, but what are the algorithms used in this library. Perhaps range reduction could be better?
For example 3.6E9 SIN gives 1.12E-9 instead of 0
3.6E9 1 + SIN gives 0.017452405564 instead of 0.017452406437 which is an error of 8.73E-10, similar to the previous one.
The HP15C gives 0.01745240644, so the 10 significant digits are correct.

On the other hand, entering 3.6E9 implicitly supposes that the error on this number is about 1e-6 or 1e-7, due to the precision of the calculator, so this is not a surprise if there is an error of about 1E-9 in the result. I wouldn’t try to fix that, unless it’s easy.
The case of integer power of a negative number is different, because it gives a complex number.