Calculators use decimal arithmetic because they can then represent our numeral system exactly and the user doesn't get unpleasant surprises.

Indeed. And in calculator programs, those surprises can crop up anywhere.

One common programming technique is to store multiple numbers in one register, like the way ISG and DSE combine loop counter, step, and limit values in one number. Extracting the parts of such combined numbers often involves multiplications by powers of 10 followed by IP, and that kind of thing is where binary arithmetic falls down -- not because it isn't accurate, but because in this specific scenario, it isn't exact.

I ran into this problem while trying to find out why a certain electrical circuit simulation program, that worked fine on the HP-42S, returned dramatically incorrect results in Free42 (when it was binary-only). Once I found the step where the two diverged, in code that split a combined number, I realized that the only way to prevent this kind of failure in general was to use decimal floating-point.

N.B. Of course you could work around this problem by using powers of 2 instead of powers of 10, but if you're trying to support legacy software, that isn't an option, since some of that software has the assumption of exact powers of 10 baked into it.

A friend of mine has ordered an NunWorks. I told him to play with the simulator till his calculator arrives. So he entered tan(cos(sin(9))), then asin(acos(atan(ans))) and then ans-9. Result when using intermediat results from the "stack" (ans) gives -0.010082. He wrote an issue on gitub. Maybe there are difference between simulator and physical device.

If SM could add a simple note taking feature with markdown functionality that can interface with the stack/printing engine, the DM42 would contain enough functionality to act as the ultimate calculator.

DM41X beta: SN00018.
DM41X: SN00496.
DM42 beta: SN00074.
DM42:SN06020.
DM10L: SN056/100.
DM11L: SN 02058.
DM15L: SN2074.
DM16L: SN2156.
DM15, DM16, DM41
and a whole bunch of the original HP's,

That's easy to explain: the calculator (emulator) only seems to be single precision (appr. 6 decimal digits, try squaring the square root of 2 or 3 and substracting the orginial number). And calculating the COS() of a small angle and then inverting the operation (or doing the same with any function near a stationary point) will seriously blow up the already significant rounding error.

So probably not a bug, but simply a matter of the calculator doing its best possible job within the available precision (and without doing any CAS).

Calculators use decimal arithmetic because they can then represent our numeral system exactly and the user doesn't get unpleasant surprises.

Indeed. And in calculator programs, those surprises can crop up anywhere.

One common programming technique is to store multiple numbers in one register, like the way ISG and DSE combine loop counter, step, and limit values in one number. Extracting the parts of such combined numbers often involves multiplications by powers of 10 followed by IP, and that kind of thing is where binary arithmetic falls down -- not because it isn't accurate, but because in this specific scenario, it isn't exact.

I ran into this problem while trying to find out why a certain electrical circuit simulation program, that worked fine on the HP-42S, returned dramatically incorrect results in Free42 (when it was binary-only). Once I found the step where the two diverged, in code that split a combined number, I realized that the only way to prevent this kind of failure in general was to use decimal floating-point.

N.B. Of course you could work around this problem by using powers of 2 instead of powers of 10, but if you're trying to support legacy software, that isn't an option, since some of that software has the assumption of exact powers of 10 baked into it.

A friend of mine has ordered an NunWorks. I told him to play with the simulator till his calculator arrives. So he entered tan(cos(sin(9))), then asin(acos(atan(ans))) and then ans-9. Result when using intermediat results from the "stack" (ans) gives -0.010082. He wrote an issue on gitub. Maybe there are difference between simulator and physical device.

I disagreed to also order an NumWorks for me...

I get -1.24138E-11 when I do this:

atan(acos(asin(sin(cos(tan(9))))))-9

Tom L

If I buy someone a drink to congratulate them, is it a Mazel Tov cocktail?