List Commands Library for 50g

[DavidM]

(09-11-2017 01:36 PM)David Hayden Wrote:  

(09-09-2017 02:09 AM)DavidM Wrote:  The reason for both the size and the speed difference is the same: two embedded Saturn routines in LPICK take up a lot of space but get the final result much faster.

I can't argue with that tradeoff, assuming that the Saturn code is related to the "get" functionality and not the rest. Otherwise, it might be worth considering if the more generic function would be a useful tradeoff.

LPICK starts out by exploding the contents of the source list onto the stack, then it performs the following steps to obtain the final results:
1) Make room on the stack above the exploded elements for the final "picked" element pointers.
2) Queue the pick list onto the RPL return stack, then loop through its contents. Pointers for each picked item are placed in the next available slot at the top of the stack.
3) Drop the original source elements from the stack, leaving only the "picked" elements.
4) Bundle result into final list

The Saturn parts are in steps 1&2. The first routine is essentially a "targeted MOVEDN" that moves the stack contents into position after the stack was expanded with NDUPN. The second one simply copies the given stack pointer into the identified position for the result.

(09-11-2017 01:36 PM)David Hayden Wrote:  While we're on the subject of size vs. speed tradeoffs, I'll mention HPGCC... then this might be a viable alternative.

It would be if I was anything more than "conversant" with C. I can usually read it and figure out what's going on, but I've never actually had to work on any C projects over the years, and thus never really got into the C mindset. I know that may seem odd to many, but C isn't really in my "toolbelt".

(09-11-2017 01:36 PM)David Hayden Wrote:  Great work by the way! I've really been enjoying reading the thread and using the library. Is the source code available?

Thanks, this has been an interesting exercise for me. I've had a long-standing desire to do more with list processing in RPL, and Pier's challenges were the perfect playground to do that. As is usually the case with me, though, I keep seeing opportunities for general solutions when I work on the specific problems. If others can make use of them, so much the better!

The source isn't published anywhere just yet, but I plan to make it available. I still need to clean it up some, as there are a handful of redundancies that I can eliminate and quite a few places where alternative approaches are "in the works" (notably storing lists as globals before exploding in a few key places). As is usually the case, I learn a few things as I go along and then want to go back and recode where appropriate, but that's never as fun as working on the newer things, is it?