Posts: 267

Threads: 27

Joined: Jul 2005

On the 49G+, try unchecking "Approx", found under MODE | CAS.

Posts: 325

Threads: 18

Joined: Jul 2006

I don't have a 49 but my understanding is that the 50g is more-or-less the same hardware so I tried this on the 50g. It's also my understanding that in general the ARM emulating a Saturn is faster than the Saturn. But I've been known to be wrong...

With both Numeric and Approx checked, my UserRPL program approximated 250! as 3.2E492 in about 0.8 seconds. With both Numeric and Approx unchecked, the program generated a 493-digit integer in about 5.1 seconds.

My 48SX approximated it in about 19000 ticks while my 48GX did it in about 13000 ticks (2.3 and 1.6 seconds).

Here's the program I used:

<<

1. DUP ROT FOR I

I *

NEXT

>>

For exact mode, remove the decimal point.

Posts: 709

Threads: 104

Joined: Nov 2005

Quote:

Just for the heck of it, I ran a speed test of a simple user RPL

program on my old 48G and on my not so old 49G+ calculators. The program simply calculates the factorial of a positive integer.

I assumed that the 49G+ would execute faster than the 48G, but I was

wrong. The 48G computed 250! in 6 seconds while the 49G+ took 15 seconds to compute 250! .
I could be wrong, but I read somewhere that the 49G+ uses an ARM

processor that emulates the older Saturn processor for certain operations. This could account for the 49G+ slower speed in executing

User RPL programs compared to the 48G.

Anyone else have an idea why this speed difference exits?

The introduction of "integer" object types for exact calculations from the 49G and onward is the reason you see any "slower" performance. The HP48 uses algorithms which take only "real" input types. On the 49G and later models, there are additional routines to handle "integer" inputs and these routines would run at the same speed or slower on the HP48. So if you are doing pure numerical calculations and integer solutions are unnecessary, make sure to have all real numbers ending in a decimal point (the auto-conversion itself can create a lot of overhead). That is, instead of 4 5 +, use 4. 5. +