On Mon, Jan 31, 2022 at 4:26 PM Elijah Stone <elro...@elronnd.net> wrote: > Obviously such arrays would have to be rectangular, that is homogenous. > So for instance, if I have a rank 2 array where the first axis is integral > and the second is symbolic, every row will have the same set of keys. So > I think overtake makes perfect sense: retain all the keys, and use the > fill element to generate the new values.
It was overtake along the dimension indexed by symbols that I anticipated problems. Your indices are: cat, dog, mouse. That's three, you overtake (or reshape) that dimension, asking for four values. What is the fourth index? A lot of J's primitives take advantage of the structure of arithmetic, and that goes away when you index with arbitrary symbols. > Negative dimensions seem inconsistent given that certain primitives (such > as " and |:) already assign meaning to such. I think it makes most sense > to make symbolic axes positive, same as normal axes. That should not be a conflict. That said, it might indeed make sense to use some other mechanism to indicate symbolic dimensions. => A question is what the shape of a partly symbolic array should be. I > propose a boxed array, where the symbolic axes are identified by a vector > of keys. That seems to force an order on the keys; I am not sure of a > good way around this. I note the linked 'What is an Array?' is careful > not to show shape, only rank. That's not the shape, though -- that's the indices. > You bring up the issue of whether amend should have index error or not. > There is an interesting issue there: what if you attempt to amend a > nonexistent key in only some cells? Should we fill the remaining cells > with the fill value, or err only then? The easier (and more consistent) > answer is that it should be an error. Catenate offers an obvious way to > add keys which does not have this problem; but update-or-add is a useful > operation to have. Hmmm. I have no problem with using fill where we specify the indices without specifying the values. > P.S. I was imagining catenate as effectively a union. This is not > completely consistent, but good enough. But what should it do about > duplicate keys? If we say that it always picks from one argument--the > left, say--on conflict, then that provides a complete solution to the > update problem. I think I would treat that in a manner analogous to merge with repeated indices: (i.5) (1 2 3 2 1) i.5 -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
