What's wrong with your HEAD?

[3298]

(10-10-2018 11:07 AM)pier4r Wrote:  yes I was thinking about LTAIL as super quick like the SUB command. But likely TAIL goes traversing the list as well, so it is not needed. What I think it is needed is a mention in the documentation.
"LTAIL --> use TAIL".

Pretty much that.

TAIL is almost as quick as SUB because it internally uses the same SysRPL command as SUB (that one being SUBCOMP). The only reason it's slower is the romptr: TAIL is one, SUB isn't, but SUB needs two numbers to be equivalent to TAIL, the first being 2 and the second being at least as large as the list length. Let's take a closer look at what benefits each command has.

In terms of size, TAIL should always win. As much as I wish TAIL wasn't a romptr, 5.5 bytes is better than the 7.5 bytes minimum for SUB, because for SUB you need two real numbers as parameters. SUB itself takes 2.5 bytes, the 2. you want as start of the range takes another 2.5 bytes (any single-digit whole number is compiled to a pointer into ROM, so you just need the size of a pointer instead of the size of the actual object), and the end of the range has to be at least as large as the length of the longest list your code needs to handle. If that maximum length is 9 or less, that's another 2.5 bytes (for 7.5 bytes total), other solutions are at least as long because you need at least one command to yank an appropriate number to the correct position on the stack (level 1 on entering SUB).

In terms of speed, the matter is more difficult. TAIL has the overhead of a romptr, but TAIL can also take a while because it has to convert the real numbers (BCD-encoded floating point) to system binary integers (hexadecimal). My tests indicate that if you just plug the real number 1048575. in there (this is the highest value a system binary integer can hold; TAIL uses a system binary integer with that value as a parameter to SUBCOMP), SUB is actually going to lose because the conversion of that number (and the 2. accompanying it) takes a bit longer than the romptr overhead. The less digits the number has, the faster the conversion, so if you know the list is 9 elements or shorter and the two additional bytes compared to TAIL don't bother you, 2. 9. SUB wins. For bigger numbers SUB's advantage diminishes bit by bit, and you'll have to accept either the heavy hit of a real number object (2. 99. SUB is 2.5+10.5+2.5=15.5 bytes long!) or put in a short calculation for an upper bound of the length. Though be alert: OVER SIZE may make the entire TAIL-replacing snippet just 10 bytes long, but SIZE walks through the entire list, which makes this snippet not only longer but at the same time slower than TAIL, especially for huge lists. The best I can think of would be taking the next power of 10 that's larger than the longest expected list length (e.g. 1000), and combining the exponent (which will be a single-digit number, in this example 3) with the command ALOG. That also makes for a 10-byte snippet, but it might still be slightly faster than TAIL.

Oh, and when you want to chop off more than one element at the begin of a list, don't chain multiple TAIL calls. That takes obviously about n times as long as SUB (where n is the number of TAIL calls), and SUB can do it at basically no time penalty by increasing the 2 in our snippet by n.

The bottom line is that if I'd use UserRPL more, I'd indeed prefer TAIL due to its acceptable tradeoff between size and performance. If the list is known to be 9 elements or shorter and performance is a major concern, the SUB alternative might be worth exploring - but if speed is so important, SysRPL is definitely the way to go. If I need to chop off more than one element, SUB is the right tool for the job.

---

A library could win against TAIL if you copy the TAIL code and store the library in port 0, because that port gets favorable treatment. It's part of the RAM area that's permanently mapped into the Saturn processor's address space, so the code will not suddenly be gone when something changes the mapping in the section of the address space where other ports or ROM sections are mapped. The library command loading code is smart enough to know that, so instead of copying the code into TEMPOB (also part of the permanently mapped area; the only part of the mapped area not listed so far that's able to store objects is USEROB a.k.a. HOME and its subdirectories) it just runs it in place. I still don't think it's worth adding it to ListExt, even though one should probably install it into port 0 to get the most out of DavidM's speed optimization.