HP Forums

Full Version: Summation based benchmark for calculators
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
Updated until post #140. Thanks for the info!

Casio 90E+ anyone ?
(09-08-2018 08:18 PM)pier4r Wrote: [ -> ]Casio 90E+ anyone ?

Very likely to be identical to fx-CG50.
Finally my question on the Ti-Planet forum got an answer Smile

TI Nspire CX CAS, hardware version P-0411A (2011), OS (2017):
Lua max= 100000: 47.1s - 139560,97614105
C with Ndless max=100000: 12 s

This a very old version of the TI-Nspire. A more recent version should be faster.

source: https://tiplanet.org/forum/viewtopic.php?f=19&t=20986
(01-02-2018 10:57 AM)grsbanks Wrote: [ -> ]...
One way round it is to use the fact that \( sin(atan(x)) = { x \over \sqrt(1+x^2) } \) Smile

That, however, doesn't benchmark the trig functions, so any results obtained would not be relevant to this particular test.

Taking a look at the UserRPL Σ (summation) vs. SysRPL looped versions of the 50g results was puzzling me, as I didn't see how Σ could possibly be executing a symbolic UserRPL expression with type checking faster than a simple SysRPL loop could step through the same calculations without the type checks. That prompted me to dig a bit into the Σ command, which in turn provided the answer: Σ uses the CAS to simplify the expression prior to looping through the summation, which ends up applying the same optimization you've identified above (\( sin(atan(x)) = { x \over \sqrt{1+x^2} } \)). In my mind, that would appear to invalidate the 50g benchmarks that use the summation notation since they aren't actually performing the same series of computations as the other platforms. I'm assuming, of course, that none of the other non-RPL calculators perform a similar optimization prior to summing the values. I have no way of knowing if that's a safe assumption, though.

To put this into perspective, a 50g SysRPL implementation that takes advantage of this same simplification could be as follows:
   %0 DUP
   1000 ZERO_DO (DO)
      DUPDUP %*
      %3 %NROOT
(Execution time: about 18s on 50g)

That compares more reasonably with the UserRPL Σ version(s) that complete in about 25s, also yielding the same result. This could be made even faster (16s) by performing extended real calculations and raising the final term to the 1/3 power instead of finding the cube root.

It's possible that there's some combination of modes/flag settings that will disable the automatic simplification process that Σ performs, but I haven't tried to find them. As it stands now, I don't believe the 50g UserRPL Σ versions are appropriate to include with the other benchmarks since they aren't actually performing the intended computations defined by the test.
DavidM thanks for the insight! I tried to pick a formula that couldn't be optimized but the 50g won again!
(I wonder if the savage test can be optimized as well as it trivially use a function and its inverse)

I'll put a disclaimer to the results of the 50g.
Post #143,#144 included.
(11-17-2018 11:37 PM)pier4r Wrote: [ -> ](I wonder if the savage test can be optimized as well as it trivially use a function and its inverse)

The formula for the Savage test can definitely be simplified by the 50g CAS:


You could probably come up with an implementation that starts with the long version of the above, then SIMPLIFY it and loop the modified algebraic to come up with a total. It would be fast, and of course accurate as well. But it wouldn't be running the actual Savage test, would it? I see this as the same issue, and the result would be similarly meaningless in the context of that benchmark.

After a bit of playing around with this, it appears that the UserRPL SIMPLIFY command will skip this particular optimization if you set system flag -111. However, the Σ command's simplification doesn't use the same code as SIMPLIFY. It appears to be hard-wired to simplify regardless of that flag's setting (it uses an internal SysRPL routine called SimplifyExpression instead).

Just to be clear, I actually think it's a Good Thing that Σ performs this simplification, in that the typical use case for that command will normally only benefit or remain neutral from that step. Benchmarking and performance comparisons are the only situations I can think of where this feature may actually be problematic, since you can end up running entirely different code than you originally intended.
TI Nspire CX CAS, hardware version N-0118AB (2018), OS (2017):
C with Ndless max=100000: 9 s
Updated to post #147

Interesting how the Prime still smokes even C on a recent nspire. I wonder if the prime sum function does the same optimizations of the 50g, although I think that Home and CAS on the prime are strictly separated.

Still impressive the prime and the nspire.
MAX 10: 31.6 sec Result: 13.71183502
MAX 100: 316.2 sec Result: 139.2971874

MAX 10: 9.2 sec Result: 13.71183502
MAX 100: 91.3 sec Result: 139.2971873

MAX 10: 3.5 sec Result: 13.7118350166
MAX 100: 31.9 sec Result: 139.297187046
MAX 10: 33.2 sec Result: 13.71183502
MAX 10: 31.5 sec Result: 13.71183502
MAX 100: 316.5 sec Result: 139.2971874
I'll update asap. Thanks for the contribution!
MAX 10: 4.6 sec. Result: 13.71183502
MAX 100: 45.2 sec. Result: 139.297187
Just another take for Casio fx-720P ;-)

MAX 10: 4.4 sec. Result: 13.71183502
MAX 100: 44.4 sec. Result: 139.297187
updated first post and wiki up to post #154
TI-30X Pro MathPrint (sum function)

Result=1395.346288 [1395.346287743 internal]

Result=139.2971870 [139.2971870461 internal]

(More than double the speed of TI-36X Pro / TI-30X Pro MultiView.)
updated to post #156

I have tried Nintendo New 2DS XL with SmileBasic.

This is the result:
max= 100000
Result = 139536.56649434
time = 0.55 sec.

Hey, this 14 times faster as the HP prime!

Yes, it is a interpreted structured BASIC. You can buy it like a game at the Nintendo store.
Yes, 3DS is a game handhold with a quad core ARM with 268 Mhz default clock and 804 Mhz on demand. But I am not shure, which clock SmileBAsic is using.
(This data I got from the german wikipedia.)

Here is the program for checking:
M=MAINTCNT '60 Ticks per second, I think
FOR X=1 TO 100000
PRINT ROUND(10/6*(MAINCNT-M))/100;" sec"

I have many fast calculator from HP 50 to Casio FX-CG20 and TI-Nspire.
But I think this is fastest handheld with the program editor for a high level language inside the device.

If you are interested, I have tried the 8 dame benchmark.

I hope it is ok, to tell about this astonishing result.


I have update the benchmark, because somebody told me, I made a mistake:
So I delete the RAD function.

100000 loop:
FOR X=1 TO 100000

Note: POW is used because 3. Root doesn't exist
Time: 0.52 secs, A=139560.97614105

And with 1 million loop I got this:
Time: 5.22 secs, A=1395612.15872538

Has anybody tried a Raspberry PI with this benchmark?
Because you can build the Raspberry like a handheld with a small display and keyboard in little box. This could be faster as a handheld game consol.

I'll add those but not as calculator devices. Just as loose reference.

There are calculators with physical keyboards for math input, what is meant here. Then another category is app calculators , at least they have a screen for math input. Then there are programming languages running on whatever computing platform and those are another category again. I'd suppose a smartphone running python would crush everything. Or a tablet.

So thanks for contributing, but don't expect to see the DS count as calculator.

edit: I didn't realize the prime g2 was as fast as an iphone 6s with free42. wow.

update: updated up to post #159
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13
Reference URL's