Little explorations with HP calculators (no Prime)

[DavidM]

(04-19-2017 03:56 PM)pier4r Wrote:  I was meaning something like "apply a RPL program to a list" (even if a function is a program as well). For what I know there is STREAM, DOSUBS (NSUB, ENDSUB), DOLIST.

STREAM seems the most simple, since it reads one element after another (after reading the first two)
DOLIST allows a bit more work, reading more elements when specified.
DOSUBS seems the most generic, allowing as many elements as defined inputs of a RPL program (or function). I wonder how the number of inputs are detected, maybe DOSUBS parses the program before.

This if I'm not mistaken.

The Advanced Users Reference gives some insight into how those commands interpret the stack contents prior to execution.

I don't think the program/function is parsed for evaluation, other than checking to see if it is only one command (thereby allowing the "n" argument to be skipped). The results of the function passed as an argument are checked, though.

Consider these DOSUBS examples:

Code:

{ 1 2 3 4 5 6 7 } « + » DOSUBS

Note: 'n' not needed because the program is a single command. The same output is generated if '2' is used for n.
The output is a list of each subgroup of 2 items added together: { 3 5 7 9 11 13 }

That one seems very sensible, and probably exactly what you would expect. Let's change it a little:

Code:

{ 1 2 3 4 5 6 7 } 2 « + 0 DROP » DOSUBS

I had to explicitly set 'n' this time because the program isn't a single command. Looking at the program, you can see that it is essentially the same thing as before (+), but then it does something silly (0 DROP), which effectively does nothing at all (puts 0 on the stack then drops it). As such, the results are exactly the same as before: { 3 5 7 9 11 13 }.

Now for a twist. Let's keep the same input, but change the program to something entirely different (and totally unrelated to the actual input):

Code:

{ 1 2 3 4 5 6 7 } 2 « DROP2 x y z » DOSUBS

The given program in this case actually ignores the two parameters it's given (DROP2), then returns 3 arbitrary items on the stack as its result: x y z. You might be tempted to think this would result in an error, but the 50g is happy to execute the DOSUBS command and comes up with the following result:
{ x y z x y z x y z x y z x y z x y z } (6 sets of "x y z").

So you begin to see that DOSUBS really doesn't care much about the results of the function, and will simply group those results together in a result list based on the count of items in the source list taken 'n' at a time.

If you really want to confuse yourself , ponder the following question: How does DOSUBS know how many stack items were returned by the program/function it was given as an argument? I would suggest you try some experiments with DOSUBS (similar to the above) to formulate an answer.

These commands are complex creatures that perform a large number of behind-the-scenes operations. That's probably why they aren't known for their performance. I also find that I can't seem to remember exactly how they work (and all their quirks) without spending significant time with experiments and reading the manuals, which is probably why I rarely end up using them.