@JohnE this tree article is really useful. I once came across a cp question which needed a tree structure and it was very annoying to try and implement.
i'm trying to extend ngn's approach to sublists to replace each-left/right, or at least provide a way to generate a table without having to raze the result
odometer lets us generate the desired element indices 'flat' but we still need a self-reference to index back in
the possible {y!x y} primitive lets us avoid the self-reference (at least until we apply except or drop), but it seems to take a lot of memory, and it's messy
@Razetime normally each-right would apply the verb directly, but this approach instead generates the pairs independently of the operation done on them (in this case a multiply) which is instead done by */
@ngn I think I found your comparison table a few weeks ago linked from hn or from a repo, amazing resource, I'd keep it up if it isn't too much of a hassle (perhaps link to the wiki or another place if it should go out of date for some reason?)
hmm, maybe this is the general list vs. rank thing
like intuitively when you have a table and you want to see if a given row is contained within it, you would check each row of the table individually, seeing if the whole of that row matches the whole of whatever "row" you are looking up
@coltim you could be looking for multiple rows though, like table?table
the implementation of "find" i have now is very simple - only 3 cases: if rank(x)=rank(y)+1 search for y (as a whole) among the elements (i.e. major cells) of x if rank(x)<rank(y)+1 recurse into y, using the same x if rank(x)>rank(y)+1 error
as discussed yesterday, finding a single item of a nested list, i need to enlist: (...)?,() which returns an enlisted index, which is also compatible with @