43S News

[Patrick]

I think I have identified a bug that I want to submit to you.

When I loaded the pgm file into my DM42, I noticed that when I accessed the Info menu and wanted to know the battery status, I got the value -NaN999... . It doesn't work on the emulator either.

Regards,

Patrick

[TwoWeims]

I have found some thinner material for a possible keyboard overlay for the DM42.
It is styrene sheet 0.20mm thick. My HP-41CV Overlay that came with the calculator measures 0.30mm thick.
This material cuts very cleanly on the laser so it will look very professional.

The samples shown in the photo are white but it comes in black also. I had white scraps in stock so I used it for experimentation.

The only problem is this is still too thick to fit in the slots on the side of the DM42 keyboard...
Any thinner and the durability may suffer.

2019-09-08 19.44.47.6410.jpg (204.03 KiB) Viewed 708 times

[Over_score]

I think I have identified a bug that I want to submit to you.

When I loaded the pgm file into my DM42, I noticed that when I accessed the Info menu and wanted to know the battery status, I got the value -NaN999... . It doesn't work on the emulator either.

Thank you for reporting. It's fixed now.

[Over_score]

Fault report in Long integer operation, sign is not processed correctly:
RESET 2 [+/-] ENTER 3 [y^x] and the same for
RESET 2 ENTER [+/-] 3 [y^x] and
RESET 2 ENTER [+/-] 3 EXIT [y^x]

all render 8, not -8.

Thank you for reporting. It's fixed now.

[Over_score]

2.0 ENTER 55 [y^x] which gives 3.6... x 10^16, within range of short int.
I then do # D which gives me 0 base 10. Not right. I expected it to give me a 15 odd significant digit integer with zeroes where the figures were gone.

It's fixed but keep following in mind:
2^55 = 36 028 797 018 963 968
and
2.^55 = 3.602 879 701 896 397x10^16 = 36 028 797 018 963 970.
This is because the SP real data type has only 16 significant digits and 2^55 has 17 digits.

So: 2.[ENTER]55[y^x]2[ENTER]55[y^x][-] results in 2 and not 0

[Over_score]

Using a freshly compiled emulator, I removed bin file for a fresh start, then 77 ENTER 88 [y^x] keeps on crashing, with "segmentation fault 11".

I experience the same issue on Linux but not on Windows... For now I have no idea what the problem is. I think it's the same as https://gitlab.com/Over_score/wp43s/issues/297 reported August 4th

[Jaymos]

2.0 ENTER 55 [y^x] which gives 3.6... x 10^16, within range of short int.
I then do # D which gives me 0 base 10. Not right. I expected it to give me a 15 odd significant digit integer with zeroes where the figures were gone.

It's fixed but keep following in mind:
2^55 = 36 028 797 018 963 968
and
2.^55 = 3.602 879 701 896 397x10^16 = 36 028 797 018 963 970.
This is because the SP real data type has only 16 significant digits and 2^55 has 17 digits.

So: 2.[ENTER]55[y^x]2[ENTER]55[y^x][-] results in 2 and not 0

Thank you. Great!
I understand. That is what I tried to say in red above but failed, but you explained perfectly and in the right terminology. Thank you.
J

[Jaymos]

Fault report.

I like the keyboard change, those changes make it a lot better.

I downloaded a new tar.gz and compiled a Mac version from scratch. Ensured the bin file was deleted.

I tried some values for x! and found the following:

290! used to work. I used it to demo longints by (290! +1) - 290!. It does not do that any more. It crashes with segmentation error 11.
Reducing the number in steps, it keeps on crashing for 200!, 150!, 100!, 90!, 80!, 50!, restarting every time until I get to 40!. At 40! it does not crash and gives an answer.
Restarting again without bin file: directly starting at 40! works, then subsequently doing 150! works, but the next digit pressed causes a crash.
Restarting again without bin file: directly starting at 40! works, then 200! crashes.

Not sure if this is again the same longint crash that you know about (refer 77^88 a few messages above), but it changed now.

Trying reals: 204.! works. Same as previously. 205.! does not work, as previously. Did not crash.

Jaco

[Walter]

Fault report.

I like the keyboard change, those changes make it a lot better.

Thanks for reporting this fault. Glad you like it.

I tried some values for x! and found the following:
...
Trying reals: 204.! works. Same as previously. 205.! does not work, as previously. Did not crash.

This is due to the SP number range - please see the error message - it is no fault.

[Jaymos]

Fault report.

I like the keyboard change, those changes make it a lot better.

Thanks for reporting this fault. Glad you like it.

I tried some values for x! and found the following:
...
Trying reals: 204.! works. Same as previously. 205.! does not work, as previously. Did not crash.

This is due to the SP number range - please see the error message - it is no fault.

Sorry for not being clear. The last part re reals was not a fault report, it was just a confirmation that all is still normal and no crashes occurred using reals: sort of a control case if you like to confirm the scope of the previously mentioned crashes.

J