New firmware for the Swissmicros DM15L

[Nigel (UK)]

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

The Free42, C43, and C47 programs all use IEEE 754 decimal 128. This is a decimal encoding that allows base 10 terminating decimals to be represented exactly, unlike the IEEE 754 binary formats which do not. The compiler(s) used support these numbers through the use of libraries, either the Intel decimal library or the decNumber library.

So if you simply say

Code:

double x; x=0.1;

you’ll have problems because the 0.1 isn’t represented exactly. The programs above don’t do this, because they use decimal types defined by the libraries they include.

Wikipedia tells me that IEEE 754 has supported base 10 encodings since 2008.

I hope this makes my meaning clearer.

Nigel (UK)

[Commie]

Hi Nigel,

I have just rechecked the Swissmicros website and it seems you are correct, they use ieee754 decimal 128. I originally thought it was ieee 754 quad 128 bit binary.

My compiler supports ieee 754 single(32bit) and double(64 bit) and they are not very good, as such I was not aware that ieee 754 also have decimal versions, which Swissmicro's use.

[jebedeo]

Hi everyone, new beta today with:

1. Fixed issue of permutations and computations not working for Y/X values above ~170
2. I reworked the algorithms to "print" the stack values to LCD to make things more consistent, thank you for spotting all those small errors in how numbers are presented to the user in different precisions and modes. Things should be working properly now, however I took a slight different approach then the original firmware in the following ways. In ENG mode, the precision that the user inputs is the significant digits to display. So ENG03 means that 0.012345 will be displayed as 12.3E-3 rather than 12.35E-3 as in the HP15C. Also, ENG00 is the same as ENG01. With respect to the different decimal digits in complex mode that you pointed out, I tidied things up but there will always be a case where the real/imaginary parts will have different lengths. The reason is that because there is not enough room on the LCD to show both parts at full precision, the algorithm drops fractional digits once it runs out of room. For example, when showing complex numbers each part gets 7 of the available 14 characters on the LCD. If in polar mode and FIX 4, for example, 1 ENTER 60 fI gives "X: 1.0000 < 60.0000" which is great. However, hitting CHS brings "X: 1.0000 < -120.000". The precision of the angle changed because -120.0000 cannot fit in 7 characters, and so the least important digits drop away. Balancing both parts of the complex number and forcing them to have the same precision, so that the above example would render as "X: 1.000 < -120.000", would be too much effort for the small price to be paid here. What do you guys think?

Till next time!

[Johnp_g]

Thanks for the update.

I haven't had a chance to try out all the new changes, but so far it looks good.

I notice some strange behaviour with fPREFIX though....

in FIX09

0.333333333 ENTER

display:

x:0.333333333

fPREFIX

shows

0

now add one

1 +

display shows

x:1.333333333

fPREFIX

shows

13333333329999998976

add another 1

1+

display shows

x:2.333333333

fPREFIX shows

0

subtract 1

1 -

display shows

X:1.333333333

fPREFIX now shows

13333333329999998976


fPREFIX seems to either show all digits or show 0 and I can't see what the pattern is as to which is shown!

Cheers,

John

1.

[jebedeo]

Ah, fixed! Thank you John

[Johnp_g]

I found another weird rounding error!

in FIX04

1.00005 ENTER

Displays as

2.0000

change to FIX05

now shows

1.00005

In FIX03

displays as

1.000

Staying in FIX03

1.0005 ENTER

displays as

2.000

It looks as though if there's a digit in the "n+1" position, in FIX0n (or SCI0n) that the rounding up happens to the whole number, not to the decimal portion. This seems to be the case whatever n is chosen for FIX/SCI/ENG.

I found it while going through the HP15C User Manual examples.

on P.22 "Numeric Functions"

in FIX04

3.4012 e^x

displays as 31.0000 instead of 30.0001

weirder still..... with 31.0000 in the display pressing ENTER

puts 31.0000 in Y and X

add them "+"

display now shows

60.0002

so the underlying number was still actually 30.0001 but was displayed as 31.0000, even when ENTER duplicated it and raised it to Y register!

very confusing!

Cheers

John

[jebedeo]

Thank you John, it should be fixed now!

The oddity comes from the fact that the only new thing in the last couple of betas is the functions that convert the numbers to strings to be displayed. I am writing my own double -> string function cause printf() with floating point support takes too much memory. So the actual floating point numbers on the stack are correct and the different operations work as before, but these bugs in my own printf are causing the issues that you saw.

[Johnp_g]

Thanks for the latest fix. Works correctly as far as I've tested...

A rather major bug with SIN /ARCSIN has come to light (EDIT : I tried beta241002 and it's in that version too, so perhaps it's been there all along?)

fFIX11

23 SIN

gives 0.39073112849, which agrees with my DM42

but ARCSIN of this number gives

0.40143 + 1.1E-16 i

instead of 23
which is clearly nonsense.

Stepping through some integer angles, to generate a SIN value between 0 and 1 and then ARCSIN to hopefully restore the original integer angle:

1 SIN ARCSIN -> 1.000
2 SIN ARCSIN -> 2.000
3 SIN ARCSIN -> 0.05235 + 1.1E-16i
4 SIN ARCSIN -> 4.000
5 SIN ARCSIN -> 5.000
6,7,8,9 all work correctly
10 SIN ARCSIN -> 0.17453 + 1.1E-16i
11,12,13,14,15,16 all work correctly
17 SIN ARCSIN -> 0.29671 + 1.1E-16i
18 SIN ARCSIN -> 0.31416 + 1.1E-16i
19 SIN ARCSIN -> 0.33161 + 1.1E-16i
20, 21, 22 work correctly
23 SIN ARCSIN -> 0.40143 + 1.1E-16i
24 SIN ARCSIN -> 0.41888 + 1.1E-16i
25 SIN ARCSIN -> 25.000
26 SIN ARCSIN -> 0.45379 + 1.1E-16i
27 SIN ARCSIN -> 27.000
28 SIN ARCSIN 0.48869 + 1.1E-16i

I gave up after this point, hopefully these are enough examples to determine the cause?

I found similar behaviour with COS ARCOS from 27 upwards, where again some integer angles work correctly and others give a strange small complex number.

I haven't found any ARCTAN oddities, which reminds me that early on there was an issue with ARCTAN 1 that you fixed. Are these ARCSIN and ARCCOS oddities related to this?

Trying a simple triangle problem - opposite side = 6, hypotenuse = 12

Opposite / Hypotenuse = SIN(angle)

6
enter
12
/
(answer = 0.500000)
ARCSIN
answer = 0.52360 + 1.1E-16i

instead of 30 degrees

(EDIT..... I just twigged..... the real part of the complex "wrong" ARCSIN is actually the correct angle, but in RADIANS - silly me for not spotting it earlier, And I see that the same complex result affects the calculation of ARCSIN from certain values if you stay in RADians mode. e.g 0.48869 (rads) ARCSIN -> 0.51059 + 1.1E-16i and presumably it's this that stops the conversion of RADIANs back to degrees if the radians value from the ARCSIN function is complex?)

John

[RPNerd]

(10-23-2024 01:03 PM)Johnp_g Wrote:  23 SIN

gives 0.39073112849, which agrees with my DM42

but ARCSIN of this number gives

0.40143 + 1.1E-16 i

instead of 23
which is clearly nonsense.

If you ignore the minute imaginary part of the result of ARCSIN, what you have is the correct angle but expressed in radians instead of degrees.

The algorithm should recognise that the argument of arcsin is a real number between -1 and 1 and explicitly return a real result.

[jebedeo]

New beta at the top.

Thanks for spotting that John! To save flash memory I am using the complex version of the C function to compute arcsin/cos. In theory they should not return complex numbers for arguments between -1 and 1, but they are buggy. The same code compiled on my desktop machine doesn't break the sin/asin test that you used to find the bug. It is, unfortunately, a "bug" of the ARM math library, new lib. I put bug in quotes because you could argue that I should not use a complex function when I know that the argument is a real number. I am cheating a bit and I was hoping to get away with it

To fix it, I implemented a simple check as suggested by RPNerd (thank you!) although it's costing me 0.5% of flash memory, we are now almost at 99% usage.

In the long term I hope to implement some of these functions from scratch, or use a different math library that behaves better, we'll see.

Another change in this beta is that the SOLVE algorithm now has some control over the precision used to get to the solution. The precision set by the user with FIX/SCI/ENG (up to the max of 15) is used by SOLVE to know when to stop. The function is evaluated and considered 0 with the precision set by the user, before stopping and returning the root. Of course, there is always the hard limit of a maximum of 100 iterations (which I might make user settable too, in the future).

Cheers!

[Johnp_g]

All seems to work nicely now!

I haven't come across anything that demonstrates the advantage of selectable precision for the SOLVE function yet, and I wonder how much precious space this takes up?

One thing that I've only just realized....

On a HP15C and DM15L it's possible to have programs with labels other than A-E. They can be numeric "LBL 0", "LBL .1" (of course that would now be "LBL 11") etc. and you'd run them directly with "GSB 0" or "GSB .1" (GSB 11).

This isn't possible with this firmware, as in RUN mode the GSB button is used to jump to a specific program line number (and GTO to jump to a specific LBL (letter/number).

If I've written a small utility prog (actually I did, last night, to find the unit vector given a complex number) and given it LBL 0 there's no quick way to run it. The only way I found is via

GTO
"Go TO LBL: "
0
ENTER

and then to use R/S to run from that point.

Much simpler is the HP way :

GSB 0

I haven't found a desire to directly jump to a line number from Run Mode. Since the line numbers on this firmware don't often increase in single steps, depending on the "memory cells" used, is it valuable to be able to jump to a line number while in Run mode? I guess for debugging it might quick to get to a specific place in the program memory once you know there's an issue around "line number xx", but is it worth losing the ability to have more than just the 5 prog labels A-E?

Just a thought.

John

[jebedeo]

Hi John,

f LBL does what you are asking, running any label from runmode. It makes me wonder if at some point I should reorganize things a bit to make them more intuitive. I take your point that from runmode the user usually doesn't need to go to a specific line...

[Johnp_g]

(10-25-2024 03:36 PM)jebedeo Wrote:  Hi John,

f LBL does what you are asking, running any label from runmode. It makes me wonder if at some point I should reorganize things a bit to make them more intuitive. I take your point that from runmode the user usually doesn't need to go to a specific line...

Wow!

Thanks for the quick reply! And for the solution.

Since you've got a way of running any label already (that I hadn't spotted... mea culpa), thus making the old HP use of GSB redundant, you should keep new function, to allow jumping to a line number, unless of course you find a better use for GSB in Run Mode.

Thanks again.

John

[Helix]

(10-25-2024 03:36 PM)jebedeo Wrote:  f LBL does what you are asking, running any label from runmode. It makes me wonder if at some point I should reorganize things a bit to make them more intuitive. I take your point that from runmode the user usually doesn't need to go to a specific line...

I think you should document the differences between your firmware and the standard 15C. I didn't know that LBL was active in RUN mode either.
I agree with John that there is nothing to change here.

[Johnp_g]

I've been enjoying using the latest firmware.

I put in the n-queens (for 8-queens) program I've used before and compared running times between the LC15 and my DM42.

Using the useful "runTime" feature (f-prefix in prog. mode) is helpful when it runs so fast!

DM42 on battery power : 8-queens in 4.6 seconds
DM42 on USB power : 8-queens in 1.76 seconds
LC15 : 8-queens in 1.37 seconds

I see a minor issue (bug might be too strong?) when running programs via the "old HP" method

"f A" or "f B" for programs labelled A or B....

A simple example :

if there's a prog labelled A and nothing else, trying to run non-existent LBL B via "f B" will actually run LBL A, presumable if it doesn't find LBL B it keeps going through memory until it finds anything.

With other programs in memory :

I had the n-queens prog under LBL 88 (which runs great via "f LBL 88") and another prog under LBL A, and another under LBL B. I forgot that I'd deleted another prog, LBL C, and tried to run it with "f C". Instead of an ERROR the calculator instead ran the n-queens program (LBL 88)....

Again, it seems to keep searching until it finds something after first looking for a non-existent label.

On the HP15C, and presumably the DM15L, trying to run a non-existent program gives ERROR 4.

It might be better to catch this, rather than risk letting the user think they're running a certain prog when actually they're running something else.

Otherwise, it's working really nicely.

Barring the Integrate and Matrix/Simultaneous equation support, it's like a mini-DM42/HP42s

Cheers,

John

[jebedeo]

Hi All,

Here's a new beta with:

1. Fixed the bug where fA/B/C/D/E would run whatever was at the beginning of memory if the label was not found, thanks for spotting that John!
2. Added support for saving program memory and loading it, through serial console. This is very bare bones but it gets the job done.

Once the calculator is connected, open a serial communication with putty or screen or whatever else you are using. I am on linux so I use "screen /dev/ttyUSB0 115200" your interface might be different but you get the gist. After that, if you long press STO on the calculator, you'll se the content of the program memory appear and you can copy that as text to save it.



To load program memory from a saved file, once you're connected on the serial port, if you long press RCL you'll be prompted to paste the program memory.

Also, a right-to-left arrow appears on the LCD to tell you that data is coming in. You can ctrl-c ctrl-v to the console directly. To stop, press any key on the calculator to end program memory load from serial.


A couple of additional info on the program memory load feature:

If you long press RCL by mistake, no big deal, just press any key and you won't lose data. However, once the calculator receives any data from the serial, it erases program memory and starts loading data from the serial console at program counter 1.

The calculator handles memory automatically so programs are always next to each other starting from the beginning of program memory. Usually, program memory that is a 0 is not an operation, but it could be data (for example GTO 0 will require a 0 in the memory cell following the GTO memory cell). This means that unless you're memory is full, you don't have to copy everything from the serial console after the memory dump. You can copy everything from the left until you reach the "sea" o zeros to the right which means that the memory is free.

To get you started, here's John's program for the Butterworth filter design:

43 8 17 255 17 19 30 39 103 39 40 86 43 9 118 12 7 5 7 4 86 43 10 118 12 7 4 7 5 86 43 6 17 0 26 25 25 25 40 26 37 13 254 86 43 7 6 6 43 3 17 254 93 30 40 53 115 0 7 9 7 10 43 4 6 8 31 25 39 13 255 75 254 7 3 86 43 5 6 8 31 25 40 13 255 75 254 7 3 86 7 7 43 100 76 3 107 0 13 19 14 118 3 111 0 104 13 0 6 6 43 1 17 254 93 6 0 115 0 20 13 255 75 254 7 1 7 7 43 0 30 39 26 38 26 32 25 39 17 0 30 39 40 11 30 39 86

Thanks again!

[Helix]

(11-01-2024 06:30 AM)jebedeo Wrote:  2. Added support for saving program memory and loading it, through serial console. This is very bare bones but it gets the job done.

Once the calculator is connected, open a serial communication with putty or screen or whatever else you are using. I am on linux so I use "screen /dev/ttyUSB0 115200" your interface might be different but you get the gist. After that, if you long press STO on the calculator, you'll se the content of the program memory appear and you can copy that as text to save it.

Fantastic!
I’ve tested this feature with Hterm, because I use it with the Sharp PC-E500S, and it works also with the Casio FX-880P.
The parameters are:
Baud: 115200
Data: 8
Stop: 1
Parity: None
CTS Flow control: No

A very minor remark though:
I think you could remove the line "PrgMemory:" in the output, because when I save the output with Hterm this line is included. Then I have to remove this line from the file for a subsequent load (I can send directly a file with Hterm, no need to copy and paste a sequence of codes!). But it’s not a big deal.

[Johnp_g]

(11-01-2024 06:30 AM)jebedeo Wrote:  2. Added support for saving program memory and loading it, through serial console.

That's great!

I can now feel better about typing in long programs while also updating to each new beta, by simply saving each program (or set of programs).

Here's N-Queens (runs from LBL 88)

43 88 54 32 13 10 43 80 17 0 17 10 118 6 7 84 26 121 0 17 0 13 254 17 10 13 255 43 81 26 121 11 17 0 13 9 43 82 26 122 9 17 9 118 12 7 80 17 0 13 254 17 255 17 9 13 254 10 17 255 38 118 12 7 83 104 17 0 17 9 38 118 7 7 82 43 83 17 0 13 254 26 122 255 17 255 118 1 7 81 26 122 0 17 0 118 1 7 83 43 84 17 11 58 86


And the Savage Benchmark (runs from LBL A)

43 100 112 30 27 36 36 13 0 26 22 22 22 43 101 84 4 88 8 99 19 37 71 0 7 101 58 86


And even both together:

SAVAGE (LBL A) and N-Queens (LBL 88)

43 88 54 32 13 10 43 80 17 0 17 10 118 6 7 84 26 121 0 17 0 13 254 17 10 13 255 43 81 26 121 11 17 0 13 9 43 82 26 122 9 17 9 118 12 7 80 17 0 13 254 17 255 17 9 13 254 10 17 255 38 118 12 7 83 104 17 0 17 9 38 118 7 7 82 43 83 17 0 13 254 26 122 255 17 255 118 1 7 81 26 122 0 17 0 118 1 7 83 43 84 17 11 58 86 43 100 112 30 27 36 36 13 0 26 22 22 22 43 101 84 4 88 8 99 19 37 71 0 7 101 58 86


Both benchmarks use the "runTime" trick with fPREFIX on the final line before RTN.

Cheers,

John

[jebedeo]

Quote:A very minor remark though:
I think you could remove the line "PrgMemory:" in the output, because when I save the output with Hterm this line is included. Then I have to remove this line from the file for a subsequent load (I can send directly a file with Hterm, no need to copy and paste a sequence of codes!). But it’s not a big deal.

The calculator ignores anything that is not a number, return key, or space, so you can send the file directly with the text header and it should work just fine.

Thanks for sharing those John!

[jebedeo]

New beta, minor bug fix with the display ('1 EEX 15 ENTER 1 -' would not show correctly as all 9s) and a slightly smaller footprint.

I am starting to look at implementing INTEGRATE and hopefully I can make it fit.

Cheers!