Summation based benchmark for calculators

[ijabbott]

(07-09-2019 12:44 PM)Gamo Wrote:  Casio fx-991EX
n=1000
t~ 2 min 15 sec
Result=1395.3463

That seems a bit slower than the previous "slow batch" result.

[pier4r]

Does someone have the nspire II? If yes, can the person do the test?

[Pjwum]

Some TI majestic line calculator results:

N = 10

~ 14s - TI-59 Result: 13.71183502
~ 16s - TI-58c Result: 13.71183502
~ 51s - TI-57 Result: 13.711835

Patrick

[toml_12953]

(08-20-2019 06:14 PM)pier4r Wrote:  Does someone have the nspire II? If yes, can the person do the test?

There were several benchmarks mentioned. I ran the nqueens program below on an Nspire CX II CAS in about 2.9 seconds. I really wish the Nspire had an RTC for more accurate measurements.
BTW, I'm using OS 5.1 which was released recently.

Code:

Define nqueens()=
Prgm
  Local a,r,s,t,x,y
  8->r
  newList(r)->a
  0->s
  0->x
  Loop
    x+1->x
    r->a[x]
    Loop
      s+1->s
      x->y
      While y>1
        y-1->y
        a[x]-a[y]->t
        If t=0 or x-y=abs(t) Then
          0->y
          a[x]-1->a[x]
          While a[x]=0
            x-1->x
            a[x]-1->a[x]
          EndWhile
        EndIf
      EndWhile
      If y=1
        Exit
    EndLoop
    If x=r
      Exit
  EndLoop
  Disp s
EndPrgm

[jlind]

With the exception of the Nspire CX II CAS, these were done without trying to simplify or optimize anything. Used default settings. 1000 was long enough for the older calculators listed. The TI-85 and TI-86 don't have a sigma summation function per se. To do a summation with an equation, the Seq() function is used to generate the sequence of f(x) from 1 to n with an optional specified interval (default is 1 if not specified). The TI-85 and TI-86 results are consistent as they're both driven by a 6 MHz Zilog Z80 uP and their hardware architecture is nearly identical. The TI-86 has 4x the RAM.

Didn't see the 2018 TI Nspire CX II CAS listed, which has a significantly faster uP than the CX. It was near instantaneous when set to 1000. Ran it at 10k and then 100k with its default settings using "Ctrl-Enter" for numerical approximation. Taking about 10x longer with 10x the sum iterations was expected. Provided its H/W and O/S data. Other than some f(x) tweaks to simplify and optimize it, the Nspire was run as-is out of the box with default settings.

1000:

• HP-50g: ~25.5 seconds; RPN; Sum function; Std number format; ~Num key; 1395.3462877
• TI Voyage 200: ~57 seconds; Sum function; 12 digits; "Approx ="; 1395.34628774
• TI-86: ~138 seconds: nested Sum(Seq(f(x),x,1,1000,1)); Mode defaults; 1395.34628774
• TI-85: ~136 seconds: nested Sum(Seq(f(x),x,1,1000,1)); Mode defaults; 1395.34628774
  

10,000:

• TI Nspire CX II CAS: ~9.5 sec; 13955.8579044; Sum function; original f(x); HW Rev. M-0119AF; OS 5.1.0.177
  

100,000:

• TI Nspire CX II CAS: ~ 94 sec; 139560.976284; Sum function and cube root; HW Rev. M-0119AF; OS 5.1.0.177
• TI Nspire CX II CAS: ~ 54.5 sec; 139560.976284; Sum function and ^1/3 power instead of cube root
• TI Nspire CX II CAS: ~ 51.5 sec; 139560.976284; Sum function and CAS simplified f(x)
  f(x) = e^(x/(3*sqrt(x^2+1)))
  

Nspire Notes:
Tweaked things with the 100k summation. Found that changing from cube root to 1/3rd power cut time by over 1/3rd. It's apparent the nth root function isn't as efficient as using the equivalent fractional power. Reduced time by several seconds more by letting CAS simplify original f(x) to the equation shown, which goes further than simply replacing the trig functions.

Should have tried replacing cube root with 1/3rd power in the other calculators. ;-)

John

[pier4r]

(08-24-2019 08:07 PM)toml_12953 Wrote:  There were several benchmarks mentioned. I ran the nqueens program below on an Nspire CX II CAS in about 2.9 seconds.

Thanks, although this is the Summation based benchmark (the test is on the post #2 in this thread).

Thanks for the other contributions, I'll add them.

[xerxes]

(08-24-2019 08:07 PM)toml_12953 Wrote:  I ran the nqueens program below on an Nspire CX II CAS in about 2.9 seconds. I really wish the Nspire had an RTC for more accurate measurements.

Thank you for testing. For more accuracy at fast and very fast results, I've used an outer loop:

Code:

Define nqueens()=
Prgm
  Local a,n,r,s,t,x,y
  8->r
  newList(r)->a
  For n,1,10
    0->s
    0->x
    Loop
      x+1->x
      r->a[x]
      Loop
        s+1->s
        x->y
        While y>1
          y-1->y
          a[x]-a[y]->t
          If t=0 or x-y=abs(t) Then
            0->y
            a[x]-1->a[x]
            While a[x]=0
              x-1->x
              a[x]-1->a[x]
            EndWhile
          EndIf
        EndWhile
        If y=1
          Exit
      EndLoop
      If x=r
        Exit
    EndLoop
  EndFor
  Disp s
EndPrgm

(Auto or Exact Mode)

[BartDB]

Sharp el-5250, n=1000, ~145s (program with Lbl-conditional-Goto)

HP 39gii
Built-in sum function, n=1000, ~2s (sum function can only do max. 1000)
Program with For loop, n=10000 ~18s, n= 100000 ~176s

[grsbanks]

TI-95 Procalc, 100 iterations, program "assembled".

83 seconds, Result (to 13 sig. fig.) = 139.2971870460

I've only just got mine and I'm still exploring its possibilities. It seems to be quite a powerful keystroke programming algebraic machine let down by its speed reminiscent of treacle climbing up a slope in the middle of a midwinter night.

[toml_12953]

(08-27-2019 01:11 PM)jlind Wrote:  Nspire Notes:
Tweaked things with the 100k summation. Found that changing from cube root to 1/3rd power cut time by over 1/3rd. It's apparent the nth root function isn't as efficient as using the equivalent fractional power. Reduced time by several seconds more by letting CAS simplify original f(x) to the equation shown, which goes further than simply replacing the trig functions.

Should have tried replacing cube root with 1/3rd power in the other calculators. ;-)

John

Yes. If you change the algorithm on one you should change it on all. The whole point of a benchmark is to compare machines running identical (or as much as possible) code, not taking advantage of any one machines special features. I'm amazed at how many people don't get that. In any set of benchmark results, someone will invariably say, "My machine has [such-and-such] function which the others don't and it's faster when I include it!" Those numbers are invalid if you change the code more than absolutely necessary. That's why BASIC benchmarks are written in the lowest common version of BASIC rather than an extended BASIC of one version or another. Translating from one calculator's native language to another's is permissible only because there is no standard calculator language. Even so, using the same algorithm is essential. Comparing two calculators ability to compute integrals using an algorithm is moot if one uses trapezoids and one uses rectangles for example.

[xerxes]

(09-12-2019 02:05 PM)toml_12953 Wrote:  Yes. If you change the algorithm on one you should change it on all. The whole point of a benchmark is to compare machines running identical (or as much as possible) code, not taking advantage of any one machines special features.

That's very true.

Regarding the test result of the CX II CAS: 2.9 seconds seems quite slow in comparison with the older
Nspire models. One possible reason could be a significant overhead or using the approx mode.
Could you please retest the CX II with the code in post #187 for confirmation? I've added a FOR loop
for minimizing the overhead effect and more accuracy.

[toml_12953]

(09-14-2019 03:46 PM)xerxes Wrote:  

(09-12-2019 02:05 PM)toml_12953 Wrote:  Yes. If you change the algorithm on one you should change it on all. The whole point of a benchmark is to compare machines running identical (or as much as possible) code, not taking advantage of any one machines special features.

That's very true.

Regarding the test result of the CX II CAS: 2.9 seconds seems quite slow in comparison with the older
Nspire models. One possible reason could be a significant overhead or using the approx mode.
Could you please retest the CX II with the code in post #187 for confirmation? I've added a FOR loop
for minimizing the overhead effect and more accuracy.

OK, I reran using your code. The time was 25 seconds making the time for one iteration about 2.5 seconds. My reaction time is quite slow!

[xerxes]

Thanks for retesting. So the TI-BASIC of the CX II is slower than expected considering the new hardware.

[toml_12953]

(09-14-2019 04:30 PM)xerxes Wrote:  Thanks for retesting. So the TI-BASIC of the CX II is slower than expected considering the new hardware.

Of course there is some added overhead for the loop itself but I wouldn't think it to be too much.

[ijabbott]

HP 49G with updated firmware "Version HP48-C Revision #2.10"

max=10000
~ 487.3s - HP 49G (ROM 2.10) radians real approx sum function (uses CAS see post #144) - 13955.8578444
~ 487.3s - HP 49G (ROM 2.10) degrees real approx sum function (uses CAS see post #144) - 13955.8578444
~ 505.4s - HP 49G (ROM 2.10) radians real approx UserRPL FOR/NEXT - 13955.8578444
~ 534.7s - HP 49G (ROM 2.10) degrees real approx UserRPL FOR/NEXT - 13955.8578444

max=1000
~ 47.8s - HP 49G (ROM 2.10) radians real approx sum function (uses CAS see post #144) - 1395.3462877
~ 47.8s - HP 49G (ROM 2.10) degrees real approx sum function (uses CAS see post #144) - 1395.3462877
~ 51.0s - HP 49G (ROM 2.10) radians real approx UserRPL FOR/NEXT - 1395.3462877
~ 53.9s - HP 49G (ROM 2.10) degrees real approx UserRPL FOR/NEXT - 1395.3462877

max=100
~ 5.5s - HP 49G (ROM 2.10) radians real approx sum function (uses CAS see post #144) - 139.297187047
~ 5.5s - HP 49G (ROM 2.10) degrees real approx sum function (uses CAS see post #144) - 139.297187047
~ 5.5s - HP 49G (ROM 2.10) radians real approx UserRPL FOR/NEXT - 139.297187047
~ 5.7s - HP 49G (ROM 2.10) degrees real approx UserRPL FOR/NEXT - 139.297187047

[pier4r]

(09-12-2019 02:05 PM)toml_12953 Wrote:  The whole point of a benchmark is to compare machines running identical (or as much as possible) code, not taking advantage of any one machines special features. I'm amazed at how many people don't get that. [...] Comparing two calculators ability to compute integrals using an algorithm is moot if one uses trapezoids and one uses rectangles for example.

Nicely put. For the rest, yes I am falling behind schedule as I have little time for the forum, on the other side this page: http://www.wiki4hp.com/doku.php?id=bench...g_exp_root ; is often not reachable by me (routing problems) and there there is the versioning of the entire benchmark list.

I'll try to collect the new entries as soon as I can.

[ijabbott]

I bought a 2nd hand Texas Instruments TI-57 II from eBay. It's a nice looking calculator in a nice case, but is a bit on the slow side. According to datamath.org, mine is the TI-57 II (1986) variant.

max = 10
~ 39s - TI-57 II - keystroke program (DSZ loop), 13.711835

max = 100
~ 419s - TI-57 II - keystroke program (DSZ loop), 139.29719

For what it's worth, the tests were done in degrees mode with the following program:

Code:

00 STO 0
01 ON/C
02 LBL 0
03 +
04 RCL 0
05 INV tan
06 sin
07 INV lnx
08 INV y^x
09 3
10 2nd Dsz
11 GTO 0
12 =
13 R/S
14 RST

[Mjim]

Just recently got hold of a Casio fx-50F (introduced 1987, but from the catalogues, still sold in 2000 and perhaps even later). Programming is limited to 29 steps (each single digit is counted as a step, so you want to set up constants in memory pre-program).

I split the program between 2 program slots P1 & P2, though you don't really need P1, as [FMLA][A] just maps to memory 1, so just send the value for n to this memory before starting the program P2.

P1 for the input and to clear the memory:

Code:

[FMLA][A]
[AC]
[SHIFT][Min]

P2 for the summation:

Code:

[Kout][1]
[SHIFT][tan^-1]
[sin]
[SHIFT][e^x]
[SHIFT][x^(1/3)] <---cube root
[M+]
[1]
[SHIFT][Kin][-][1]
[Kout][1]
[SHIFT][x>0]
[MR]

Summation Benchmark n=10:
Average of 3 tests (Degrees): 18.7 seconds
Result: 13.7118350165

Summation Benchmark n=100:
Average of 3 tests (Degrees): 187.1 seconds
Result: 139.297187029

Summation Benchmark n=1000:
Test 1 (Degrees): 1814 seconds
Test 2 (Radians): 1828 seconds
Result: 1395.34628605 (same for both tests, whether degrees or radians)

[pier4r]

apparently someone did the test on the casio fx9860GIII without reporting it here.

https://www.hpmuseum.org/forum/thread-14...#pid137152

Quote:First, I get it to calculate \(\sum_{k=1}^n \sqrt[3]{e^{sin(atan(k))}} \) (a function with no intrinsic value other than it gets the calculator to chew through a bunch of transcendental functions) for various values of \(n\).

Using the built-in \(\sum \) function it gets through this in roughly (because timed with a stopwatch) 25 seconds for \(n=10^3\) or 220 seconds for \(n=10^4\). Using a Casio Basic program it does it in about 16 seconds for \(n=10^3\), 164 seconds for \(n=10^4\) or 1650 seconds for \(n=10^5\). Using a python program it does it in only 2 seconds for \(n=10^3\), 18 seconds for \(n=10^4\) or 184 seconds for \(n=10^5\). That's 10× faster than using Casio Basic, BUT with what appears to be greatly reduced precision.

Knowing the precision would be interesting too.

[Frido Bohn]

DM41X: FOCAL, max=100
fast mode, battery powered: result=139.2971873, time 14.33 s
fast mode, USB connected: result=139.2971873, time 4.61 s

The FOCAL program was beginner level, i.e., not streamlined to stack-only operations.

Cheers,
Frido