RPL programming questions

[HP67]

(02-19-2014 05:23 PM)DavidM Wrote:  You didn't misread my comments. The 23/21 sec. times were for the UserRPL programs that were re-coded without the single quotes around the variable names (and the subsequent RCL).

Thanks for clarifying. That is interesting and hard for me to reconcile, as I mentioned, unless the 50g devices themselves are that variable.

(02-19-2014 05:23 PM)DavidM Wrote:  

Code:

A 3, * B +

I missed something here. What does the comma do? Is that 50g-speak for integer in this example?

(02-19-2014 05:23 PM)DavidM Wrote:  But the above would be slightly slower and take up more memory. Is it worth it? As the programmer, you have to make that decision. If you're working on something that is likely to be updated later, it may be. If the above is in a tight loop that is executed thousands of times, the speed penalty may be excessive.

Until I get a cable I'm keying everything in on the device and that is slow (but not painful due to HP's unbelievable ability to pay attention and put out incredible stuff). On my listings that I keep elsewhere I have comments. I'm not worried about readability in the abstract, the HP 48 is slow, and for me whatever I code is going to be for performance uberalles.

(02-19-2014 05:23 PM)DavidM Wrote:  But as you can see, the former requires that the variables are already on the stack at the outset. The penalty for using stack-based operations is as has been mentioned by others: readability and code maintainability suffers.

Well, the point with stack-based languages is to keep everything on the stack as much as possible, right? I consider the code that makes it onto the device important only as far as that it works. The "real" source will live in a place where I can keep comments with it, so readability etc. should be fine, when I'm reading stuff in the right place.

(02-19-2014 05:23 PM)DavidM Wrote:  These are important factors that should not be discounted when considering how you write any application (on any platform). A program written with a bias toward using stack operations may be more efficient than one using local variables, but in most cases it will also be more fragile. Adding a new computation in the middle of previously written ones can wreak havoc with your carefully planned stack.

Yes! This is one very big difference from stack-based languages (and languages implemented on stack machines or machines that use a stack) as opposed to environments that are not stack-based. Making a mistake or having to change something later can be very time-consuming. And annoying! Happened to me just this morning when I coded up a command (is that the word for an RPL program? I keep wanting to say "word") as I went through a text and when I got to the end of a formula I saw what I thought was a typo. Then I found the formula was actually wrong. I contacted the author and got a correction and then I had to shoehorn the fix into the middle of my stack-dance. Not fun! But in the end, it is fun.