New firmware for the Swissmicros DM15L

[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