What would be the ultimate calculator in 2017?

[Dani R.]

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

[keithdalby]

Hmmh, did you get the enlarged screen for senior customers for beta testing?

Now now, I'm only sharing my thoughts and opinions

[Walter]

Hmmh, did you get the enlarged screen for senior customers for beta testing?

Now now, I'm only sharing my thoughts and opinions

Hehe, I just commented your choice of terms. No offense intended.

[keithdalby]

Hmmh, did you get the enlarged screen for senior customers for beta testing?

Now now, I'm only sharing my thoughts and opinions

Hehe, I just commented your choice of terms. No offense intended.

And none taken

[RAPo]

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.

[AlexFekken]

* tan(cos(sin(9))) etc...

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

[dm319]

That's easy to explain: the calculator (emulator) only seems to be single precision

Are you saying the numworks calculator is single precision binary?

Can anyone tell me how most mainstream calculators store their numbers? Do most use BCD?

[pauli]

Can anyone tell me how most mainstream calculators store their numbers? Do most use BCD?

Virtually all use BCD or equivalent. I.e. decimal arithmetic.


Pauli

[toml_12953]

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

[rprosperi]

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

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

Is this using the the NumWorks machine?

On the DM42, I get -2.86934E-28 !
Amazing!