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
Just for the fun of it...the savage benchmark
Just for the fun of it...the savage benchmark
DM 42 - SN: 00373, Firmware release v.:3.22. / DMCP 3.24. as compiled by SwissMicros
Re: Just for the fun of it...the savage benchmark
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.
Re: Just for the fun of it...the savage benchmark
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
Iam really really looking forward to it, and there’s no more news updated since 14th Dec it departed Germany on AfterShip tracking
Iam really really looking forward to it, and there’s no more news updated since 14th Dec it departed Germany on AfterShip tracking
Re: Just for the fun of it...the savage benchmark
Assuming I've understood the algorithm correctly:
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)...
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
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.
Re: Just for the fun of it...the savage benchmark
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.
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.
Re: Just for the fun of it...the savage benchmark
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:
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.
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
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.
Re: Just for the fun of it...the savage benchmark
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.
Re: Just for the fun of it...the savage benchmark
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 [-]?
If I understand the accuracy calculation from the pdf, doesn't line 32 need to be a [/] rather than a [-]?
Re: Just for the fun of it...the savage benchmark
DSE then press the dot, which gives you a menu:
[IND] [ST L] [ST X] [ST Y] [ST Z] [ST T]
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.