List Commands Library for 50g

[DavidM]

(02-06-2018 09:04 PM)John Keith Wrote:  1). Reverse the order of the level 1 and level 2 arguments (index and object to be inserted) of LINSR. This would make it consistent with built-in commands such as REPL, as well as INSERT on the Prime.

That's a good point, John. And it is in keeping with the spirit of some of the other commands which have been set up to expect similar arguments (and output) to built-in commands.

@Gilles: this one was really your suggestion. How do you feel about rearranging the arguments as John suggests?

(02-06-2018 09:04 PM)John Keith Wrote:  2). LMSEQ always returns a list of reals, even in exact mode. If it can be done without undue penalties in speed and complexity [my emphasis], I would prefer it return a list of integers in exact mode, as long as the level 2 and level 3 arguments (ratio and starting value) are integers.
This is not a big deal, as the GoferLists command Iterate provides this functionality.

Yeah, I would like that too.

After an initial set of checks for arg types and special cases (mostly 0/1 list size), LASEQ/LMSEQ/LDSEQ all use the same Saturn code engine with a flag that designates which operation to perform with the constant. This was fairly easy to set up due to the existence of add, multiply, and divide Saturn subroutines built into ROM that all expect their arguments as reals and in the same place/format. Doing those same operations with exact integers would be much more problematic (for me anyway) since the only way I know of to safely access the built-in integer math routines is at the SysRPL level. This would definitely mean a sacrifice in performance, and probably bring them more in line with Iterate. So their value vs. the library bloat decreases.

I ran into a similar situation when creating the engine behind LSEQ/LSEQR, but ended up deciding to build the output list from scratch instead of using built-in routines. This was a bit more complex, but still not too bad because in both cases I only needed to add/subtract 1 for each number in the result list. And I still limit the arguments in those routines to +/- 1E12 to keep the implementation fairly straightforward. Refactoring that same method to LMSEQ isn't as easy because the individual output elements can quickly grow beyond register-sized fields.

Bottom line: I'd like to be able to have the intuitive integer results, but the implementation seems like it would be more complex than it may be worth in comparison to simply doing it as a SysRPL code object, which then has questionable value when compared to existing alternatives. I may still play around with this some more, though.