The focus system seems designed to accelerate near-sequential lookups or iteration. Is this your trick?
Yep, the idea is to optimise for locality of reference by reducing indirection to recently accessed sub-radixs. I think this is what Scala does for its vectors as well.
How was it chosen over, say, a doubly linked list running through the leaf vectors?
It seems like a doubly liked list on the leaves would be better. It's fewer indirections to neighbours when the tree is tall, and you don't have to store height. Perhaps when doing concurrent unordered operations the focus system is fewer indirections, and that's why scala did it this way? but why would you care about locality then? I'll probably redo it as a doubly linked list as you suggest.
The rationale behind the new-start computation of the let* of focus-set! is not immediately obvious to me. Could you explain a bit? Why is the multiplication factor 32 rather than node-size?
This was the mistakes that was causing radix->list to vomit random data all over the place, nice!
I think a note would be appropriate somewhere around focus-set! that you are choosing to compute focus-start and focus-end as the maximum possible range of positions that the focus could cover, but those positions are not all guaranteed to actually exist in the current radix.
Okay done.
Naive-append-vector! looks much more manageable now. I do have to wonder though about the make-radix call in the proc call of the else branch, when the let* has new-radix.
Thanks, I think there is still a good bit of room for improvement there, the double make-radix is silliness as usual though, it's now fixed.
As explained in >>20 about radix-copy-path, radix-ref-height must also not be called with a position that is 32-aligned at the end of the radix. Radix->list-iter does not respect this, and in >>19 this was almost harmless because the radix was stateless and the vector-copy handled the empty slice. But now the radix is stateful so the modulo piece should become the empty list immediately when the modulo is 0, without a call to (radix-ref-height radix-struct length 1).
I haven't dealt with this yet but I will soon.
The final-vector-remainder of radix-append regressed from >>21.
Oops, I moved to a old save because I was working on the rewrite on the current branch. I really need some sort of version control.
Yesterday I just ended up working on the election system, I came up with a different weighting function than the one I thought would work two days ago, and I ended up resolving many of my problems by using fancy vector functions, main thing left is to find a efficient means of resolving ballot level ties: http://ix.io/1xJM I'll try to focus on the radix library today.