List Commands Library for 50g

[DavidM]

(06-25-2017 10:46 PM)ttw Wrote:  Another useful routine could be LPROD in analogy with LSUM. A single element list should yield its element and an empty list should return 1. There are a couple of other end-cases that are of interest: an scalar numeric value could be treated as a single-element list and an empty stack could be interpreted as an empty list.

While working on LPROD for the next release, I encountered an issue related to ΠLIST (capital-pi LIST). ΠLIST is designed to take a list and repeatedly execute the multiply function (*) on each element in succession after "priming" the stack with the first element. Like ΣLIST with "+", it is designed around repeatedly calling the same function that is activated when you press the "x" (multiply) key. This would lead you to believe that the same function overloading should occur for ΠLIST that occurs with *, so different object types would be handled appropriately.

That's not the case for at least one specific situation, though. Namely, any multiplication where at least one of the arguments is a list will fail with ΠLIST. It's easy to replicate this bug (yes, I consider it a bug). On any of the RPL calculators that have ΠLIST, enter this from the keyboard:

{ 2 } { 3 } *

The result should be { 6 } (at least it is on my 49g+/50g/48gx). This is the normal and expected answer for multiplying two lists in that manner on those machines.

{ { 2 } { 3 } } ΠLIST, however, results in "Bad Argument Type". This is a side effect of the way the dispatch mechanism is being altered during the looping for *, and I don't believe this error was intended to have worked that way. It wouldn't surprise me if this is documented as a known issue somewhere, though I haven't seen a reference to it after searching around a bit. It's probably that it was never considered important enough to fix. Interestingly, this issue has been around at least since the Rev. R version of the 48g/x (the oldest machine I can personally verify it on).

I attempted to work around this for LPROD. { { 2 } { 3 } } LPROD will correctly return a result of { 6 }, as should other LPROD invocations that include one or more sublists. If an error occurs while determining the product of a list containing sublists, however, the original stack contents won't be returned the way they normally are for a command that errors out. Instead, you'll end up with the "offending" arguments on the stack that generated the error. This might actually be a good thing, as it will clearly show what caused the problem. But it's not consistent with the usual way errors are handled. Short of recreating the entire dispatch sequence for *, I've yet to find a good way to provide the normal error handling if a sublist is involved. So hopefully this will suffice for now.