Question

I just got an HP 50G graphing calculator last week, and I’ve been learning the standard language for it (RPL). I have two questions:

1. Is there a limit on how large the stack can grow, and does the interpreter perform any tail call optimization anywhere? Or should I implement everything with loops instead of recursion to make it faster? (Either way I’m implementing fold/reduce and unfold with loops or recursion, whichever is faster).

2. Currently, in order to do higher order functions I have to call EVAL on the function. e.g. “xs HEAD f EVAL” to call f with some arguments (where f is a function that gets popped off the stack). Is there a cleaner way of doing this without using EVAL?

Answer 1

I am also an HP RPL newbie, but by playing around I think I’ve been able to find some decent answers to your questions.

Is there a limit on how large the stack can grow?

Yes. It is limited by available RAM.

That answer may seem facile, but read on.

does the interpreter perform any tail call optimization

Apparently not. Consider this simple RPL program, DEC0:

« → n
  « n
    IF n 0 >
    THEN 1 - DEC0
    END 
  »
»

If you time runs of the program, you get this result:

Note the log scale on the Y axis: running time increases exponentially as a function of the value you pass to the program. This tells us the RPL interpreter is not optimizing this to a simple linear operation, despite the fact that the DEC0 call in the THEN clause is recognizably a tail call.

Maybe there are other cases where the RPL interpreter can do tail call optimization (TCO), but if it misses a clear opportunity like this one, it seems like a bad idea to use recursion generally. At best, you turn an O(N) operation into an O(N^1.7) operation[1]. At worst, this[2] happens:

The 90,735 value on the stack is what’s left after trying to run the program with n=100,000, and the 1 value is the subtrahend in the THEN clause. The error says it ran out of memory to store the difference.

Now, you may wonder why I got a failure after 9,265 iterations in this case when the graph above says I got a 10,000 iteration run to succeed in about 49 minutes. This one died after about 47 minutes, so it was clearly on the way to 10,000. My guess is that because we’re so close to the memory limits here, a successful run to 10,000 iterations depends on the state of the heap at the time you start the test. I’ve seen failed runs with as little as 344 left on the stack.

should I implement everything with loops instead of recursion

Based on the above results, I’d say yes.

Even ignoring the RAM size question, recursion is slow. Simply decrementing a counter from 100 down to 0 took 5 seconds. Decrementing from 1,000 took over a minute, because run time increases exponentially.

Is there a cleaner way of doing this without using EVAL?

I couldn’t find a way. The HP manuals don’t mention “recursion” or “recursive” at all, and Google didn’t turn up much on the topic, either.

I believe this also supports my deduction that the RPL interpreter lacks TCO. HP already knows what I discovered and documented above, so they don’t give recursive methods in the manuals. Experienced RPL programmers trained in the FP Way try recursion, find some or all of the above problems, and resolve to use iterative methods from then on, indirectly influencing programmers who see their non-recursive solutions.

If I have not yet dissuaded you, there is a chapter on recursive programming in RPL in The Definitive User’s Guide to the HP 48g/49g/50g Calculators.

Footnotes

[1] My curve fitting program says the function is y = 4.048 · x^1.715

[2] Though my initial tests were done with a 49g+, the results are still relevant to the 50g because the two models are the same as far as far as this question goes. I later verified the results on an actual 50g. I’ve also tried all this on a 48GX, and got the same results, except that the memory size limit seems to be about half that of the 49g+ and 50g.