## What would be the ultimate calculator in 2017?

General discussion about calculators, SwissMicros or otherwise
Dani R.
Posts: 291
Joined: Fri May 05, 2017 10:23 pm

### Re: What would be the ultimate calculator in 2017?

Thomas Okken wrote:
Thu Aug 31, 2017 2:28 pm
pauli wrote:
Thu Aug 31, 2017 1:26 pm
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...
DM42 SN:00032
keithdalby
Posts: 564
Joined: Mon Apr 24, 2017 8:38 pm

### Re: What would be the ultimate calculator in 2017?

Walter wrote:
Thu Aug 31, 2017 9:52 pm
Hmmh, did you get the enlarged screen for senior customers for beta testing?
Now now, I'm only sharing my thoughts and opinions
Walter
Posts: 1666
Joined: Tue May 02, 2017 11:13 am
Location: Close to FRA, Germany

### Re: What would be the ultimate calculator in 2017?

keithdalby wrote:
Thu Aug 31, 2017 11:40 pm
Walter wrote:
Thu Aug 31, 2017 9:52 pm
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.
DM42 SN: 00041 Beta
WP 43S running on this device

HP-35, HP-45, ..., HP-50, WP 34S, WP 31S, DM16L
keithdalby
Posts: 564
Joined: Mon Apr 24, 2017 8:38 pm

### Re: What would be the ultimate calculator in 2017?

Walter wrote:
Fri Sep 01, 2017 7:31 am
keithdalby wrote:
Thu Aug 31, 2017 11:40 pm
Walter wrote:
Thu Aug 31, 2017 9:52 pm
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
Posts: 258
Joined: Wed May 03, 2017 6:54 pm
Location: The Netherlands
Contact:

### Re: What would be the ultimate calculator in 2017?

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,
AlexFekken
Posts: 10
Joined: Wed Jul 26, 2017 7:58 am

### Re: What would be the ultimate calculator in 2017?

* 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
Posts: 31
Joined: Thu Aug 03, 2017 12:21 pm

### Re: What would be the ultimate calculator in 2017?

AlexFekken wrote:
Sun Sep 03, 2017 7:09 am
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
Posts: 118
Joined: Tue May 02, 2017 10:11 am
Location: Australia

### Re: What would be the ultimate calculator in 2017?

dm319 wrote:
Fri Sep 08, 2017 12:41 pm
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
Posts: 683
Joined: Wed May 03, 2017 7:46 pm
Location: Malone, NY USA

### Re: What would be the ultimate calculator in 2017?

Dani R. wrote:
Thu Aug 31, 2017 10:29 pm
Thomas Okken wrote:
Thu Aug 31, 2017 2:28 pm
pauli wrote:
Thu Aug 31, 2017 1:26 pm
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?

DM10L SN: 059/100
DM41X SN: 00023 (Beta)
DM41X SN: 00506 (Shipping)
DM42 SN: 00025 (Beta)
DM42 SN: 00221 (Shipping)
rprosperi
Posts: 1025
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

### Re: What would be the ultimate calculator in 2017?

toml_12953 wrote:
Sat Sep 09, 2017 2:12 am
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!
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100