Just for the fun of it...the savage benchmark

Discussion around the SwissMicros DM42 calculator
mcc
Posts: 277
Joined: Fri Jun 23, 2017 5:10 am

Just for the fun of it...the savage benchmark

Post by mcc »

Hi,

I couldn't decide where to put this...it is kinda software...but it
is not ready to type in and run it. It is a description of a short benchmarking/
accuracy measurement and there is a list of different calculators and
how they had performed as well:

http://www.technicalc.org/tiplist/en/fi ... ip6_50.pdf

May be someone is interested in checking this on her/his DM42....

Happy benchmarking!
Meino
DM 42 - SN: 00373, Firmware release v.:3.22. / DMCP 3.24. as compiled by SwissMicros
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Just for the fun of it...the savage benchmark

Post by grsbanks »

I've not looked but if this was done on the HP-42S then it can be run pretty much as-is.
There are only 10 kinds of people in the world: those who understand binary and those who do not.
elulis
Posts: 5
Joined: Mon Nov 27, 2017 9:53 pm

Re: Just for the fun of it...the savage benchmark

Post by elulis »

Still waiting my DM42 to arrive, instead I tried with new arrived numworks calculator. cost about 3 seconds(n=2499) and gives a relative accuracy of 4.71e-13 :shock:

Iam really really looking forward to it, and there’s no more news updated since 14th Dec it departed Germany on AfterShip tracking :(
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Just for the fun of it...the savage benchmark

Post by grsbanks »

Assuming I've understood the algorithm correctly:

Code: Select all

00 { 53-Byte Prgm }
01▸LBL "SAVAG"
02 ABS
03 IP
04 STO 01
05 TIME
06 →HR
07 STO 02
08 R↓
09 1
10 RAD
11▸LBL 01
12 ENTER
13 ×
14 SQRT
15 LN
16 E↑X
17 ATAN
18 TAN
19 1
20 +
21 DSE ST T
22 GTO 01
23 TIME
24 →HR
25 RCL- 02
26 3600
27 ×
28 X<>Y
29 RCL 01
30 1
31 +
32 -
33 END
2499 iterations in 14.08s with an error of 5.8726E-26.

I also did it on the DM41L (48MHz) and it finished in 966s with an error of..... 0.0297

Just for shits & giggles I also did it on Free42 on my Samsung Galaxy S8+ phone. 0.25s (same error as the DM42 of course)...
There are only 10 kinds of people in the world: those who understand binary and those who do not.
elulis
Posts: 5
Joined: Mon Nov 27, 2017 9:53 pm

Re: Just for the fun of it...the savage benchmark

Post by elulis »

grsbanks wrote:
Thu Dec 21, 2017 8:19 pm

2499 iterations in 14.08s with an error of 5.8726E-26.

I also did it on the DM41L (48MHz) and it finished in 966s with an error of..... 0.0297
Thanks for the information and now I’m more eager to... counting the days... :D
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Just for the fun of it...the savage benchmark

Post by grsbanks »

As an addendum...

The DM42 does it in 6.35 seconds when connected via USB.

I gave up on the HP-28S (UserRPL) after about 3 minutes...

I'm going to test on the HP 50g and the HP Prime and update this post with the results.

HP 50g: 80 seconds and 0.0051353 error
HP Prime: 0.63 seconds, same error as the HP 50g.
There are only 10 kinds of people in the world: those who understand binary and those who do not.
jfb9301
Posts: 21
Joined: Mon Dec 11, 2017 12:33 am

Re: Just for the fun of it...the savage benchmark

Post by jfb9301 »

I took my own go at this, but I got different results.

gsrbanks, I did not follow your command at line 21, nor did I understand the last few lines you did.

The code I used:

Code: Select all

01▸LBL "SAVAGE"
02 1
03 STO 01
04 2499
05 STO 02
06 TIME
07 →HR
08 STO 03
09 RCL 01
10▸LBL 01
11 ENTER
12 ×
13 SQRT
14 LN
15 E↑X
16 ATAN
17 TAN
18 1
19 +
20 DSE 02
21 GTO 01
22 STO 01
23 TIME
24 →HR
25 RCL- 03
26 3600
27 ×
28 RCL 01
29 2500
30 -
31 2500
32 ÷
33 DEG
34 RTN
35 END
partial documentation, is that this stores a in 01, n in 02 and time in 03. The program follows the calculation by determining elapsed time, and then calculates accuracy.

This program executes in 27 sec un-pluged, 9.4 sec plugged, and accuracy of 1.33796 E-29.

The longtime HP user in me wanted to do away with lines 11 and 12 and replace them with x^2, which saves a line (helpling to cope with HP's notoriously small memory), and does compute slightly faster.


HMMM, I didn't do this in RAD.....
Inserting a line between 01 and 02 to shift to rad, gets 20.9 sec un-plugged, 7.1 sec plugged, and accuracy 2.34904E-29.
Still not the same, but I believe it to be correct, unless I am missing something.
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Just for the fun of it...the savage benchmark

Post by grsbanks »

jfb9301 wrote:
Mon Dec 25, 2017 5:51 pm
gsrbanks, I did not follow your command at line 21, nor did I understand the last few lines you did.
Hmm... Not sure how "DSE ST T" got there because on my DM42 it's "DSE ST Y"

If the calculator were absolutely precise then after 'n' iterations of the loop you would have 'n+1' in the X register. One of the points of this little program is to test the accuracy, so I keep a record of the number of iterations requested 'n' (in R01) and use the Y register as the loop control register because, just before you reach LBL 01, X contains 1 and Y contains 'n'.

When the loop has finished, i.e when Y reaches zero, I subtract 'n+1' from X to reveal the error accumulated throughout the calculations. That's the point of line 21 and the last few lines.

Also, I used the "ENTER *" sequence because the problem features the quantity "a*a", not "a^2". OK, mathematically they're the same but there may be some optimization that happens when using x^2 and does not happen when using multiplication.
There are only 10 kinds of people in the world: those who understand binary and those who do not.
jfb9301
Posts: 21
Joined: Mon Dec 11, 2017 12:33 am

Re: Just for the fun of it...the savage benchmark

Post by jfb9301 »

I guess it is that I knew what you were doing with DSE ST Y or T or what have you, but I cannot figure out how to access that on my DM42, all I could manage was DSE, which allowed a 2 digit number. but I think it works fine the way I wrote it, but the end time is different, by a rather large margin.

If I understand the accuracy calculation from the pdf, doesn't line 32 need to be a [/] rather than a [-]?
grsbanks
Posts: 1122
Joined: Tue Apr 25, 2017 11:23 am
Location: Preston, Lancs, UK
Contact:

Re: Just for the fun of it...the savage benchmark

Post by grsbanks »

jfb9301 wrote:
Mon Dec 25, 2017 7:12 pm
I guess it is that I knew what you were doing with DSE ST Y or T or what have you, but I cannot figure out how to access that on my DM42, all I could manage was DSE, which allowed a 2 digit number.
DSE then press the dot, which gives you a menu:

[IND] [ST L] [ST X] [ST Y] [ST Z] [ST T]
jfb9301 wrote:
Mon Dec 25, 2017 7:12 pm
If I understand the accuracy calculation from the pdf, doesn't line 32 need to be a [/] rather than a [-]?
It's always possible that I didn't pay attention to that detail :) What I was doing was getting the absolute error rather than relative.
There are only 10 kinds of people in the world: those who understand binary and those who do not.
Post Reply