List Commands Library for 50g

[pier4r]

(03-31-2018 01:16 AM)DavidM Wrote:  It seems to me that you're really talking about some concepts that are better served in a different way, though. You'd be better off if you simply load the items onto the stack (if they were already in a list, just use LIST→), then make whatever changes are needed to the stack items with ROLL/ROLLD/DROP/etc. When done, rebuild the list with →LIST. You'll find that this is much more efficient with memory, and probably speedier as well. The objects in question don't actually move in memory until the list is rebuilt. The stack is nothing more than a list of pointers to objects that are scattered in memory, and those pointers can be manipulated quickly and efficiently. Changing the placement/ordering of stack items doesn't move the objects themselves, just their stack pointers.

And, yes, adding a list of 20 items to another list is much faster (and much, much more efficient) than 20 consecutive STO+ steps.

Thanks for the info. For the stackrobatics. Yes I finally yielded that doing stack operations and then \->LIST (or even just stack things) is faster. But not if you have operations in the middle - that may change with the evolution of a routine - and one has to keep track of what is going on to avoid mixing objects. I found that not so maintainable.

Keeping juggling 2-3 elements on the stack with different operations is still ok, more or less. Mixing operations, for me, it is not. Surely it can be done. Of course if you explode a list, roll a couple of elements, and pack it again, the elements can be many. But that is a well "self contained" operation without other operations in the middle.
Interesting that the 4 registers stack of previous RPN models is enough for my taste of "using the stack".

I will use the STO+ between temp lists. That will speed up things when I build large lists. It is a useful info.

In general, as far as I understood you, every command that modifies a list explodes it. So If I pack a bigger input it is better as there are less "explosions".