Determine the best array structure for hobby.

[loopspace]

When I originally wrote the code to implement Hobby's algorithm, there was rudimentary support for array-like structures in L3. In particular, the methods \seq_item:Nn and similar were not present. So I wrote my own version as a wrapper around a prop. My implementation included features that I don't actually use for completeness sake.

The commands that I actually use are (plus variants thereof):

• \array_new:, \array_gclear: Initialising an array
• \array_get: get an element of the array by specifying its index
• \array_gpush: put an element on the end of the array
• \array_gput: put an element at a specific place in the array
• \array_if_empty: test for contents
• \array_length: get the actual length of the array
• \array_map_inline: iterate over an array in order
• \array_top: get the position of the last element in the array

Also worth noting that my arrays are not specifically based. Internally, I keep track of the least indexed element and the greatest. This is not a sine qua non but is quite useful in terms of the code since there is a natural numbering of the arrays that I use that makes some of them 0-based and some 1-based.

In terms of existing L3 structures, I see three choices. All would need augmenting to fit my needs.

1. prop (what I currently use) provides all the needed access, the missing bit is the order of the terms and knowledge of where the last term is (for push)
2. seq doesn't have the ability to set an arbitrary term (but see https://tex.stackexchange.com/q/124782/86 and https://tex.stackexchange.com/q/497912/86)
3. fparray is fixed size (I could initialise an array of the right size for each time the algorithm is run, but there doesn't seem a way to destroy or re-use an fparray) and doesn't have the stack routines

I feel that seq is probably now closest to what I want, especially in light of those TeX-SX posts. But as there isn't currently a perfect solution, I'm not sure of the value of swapping one partial solution for another.

[PhelypeOleinik]

Hm... It seems to me that a seq would match all the function requirements, except for \array_gput: to place an item into an arbitrary index (which shouldn't be too hard to add in l3seq). A prop is not ordered (well, it is, but that's an implementation detail), and fparray (which is an intarray in disguise) is quite rigid in balance to its speed, although maybe the stack functions could be implemented internally.

The only problem with a seq is that it is always 1-indexed, so unless you do your own bookkeeping to make id whatever-indexed, that won't work well... But if you still keep track of the least index, you can normalise it to 1-indexed when accessing the seq, so it should work.

Want to open an issue for \seq_put_index:Nnn (and maybe a \seq_get_index:NnN to go with it) in the latex3 repo? (not necessarily this name, I just made one up :). I can't promise it will be added, nor when someone will have the time to do that, though, so don't hold expectations

[blefloch]

Regarding fixed-size of intarray and fparray variables, note that l3regex just assigns a large intarray (size 65536 I think) when loaded and uses it. In practice it has not been a problem, although I will at some point try to improve the situation.

[loopspace]

@PhelypeOleinik The 1-based-ness is not a deal-breaker. It'll be annoying, because I'll have to re-read and try to understand my code, but I can cope with that.

@blefloch The fixed size-ness is mainly a niggle in my mind about using up memory unnecessarily. I'd still need to implement the stack system with an underlying fparray if that was what I ended up using.