On Mon, 31 Jan 2022, Raul Miller wrote:
It was overtake along the dimension indexed by symbols that I
anticipated problems.
Ah, I see. I do not think take should be specified in such cases, let
alone overtake. I do not think keys should be ordered, either.
Really, there are two issues to pin down. 1, underlying operational
model; 2, behaviour of specific primitives. I think 1 is more
interesting, and that many cases of 2 will fall out fairly naturally if 1
is settled.
I think we currently think of arrays as hyperrectangles of atoms. In that
case (considering only 1-d), x {. y can be seen as slicing off the first x
items of y and returning them. Then overtake can be thought of as slicing
into the empty space beyond the end of y.
If we permit dictionaries, though, then we must instead think of arrays as
functions. In that case, one sensible model for x {. y is a function with
domain i.x, such that z { x {. y is z { y iff y is defined at z, and y's
fill value if not. Then it does not do anything particularly useful for
an array keyed by 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.
I did not say that there was a conflict, only that it would be
inconsistent.
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.
I agree. I think shape should not be well-defined for symbolic arrays,
and there should be some other primitive to query domain.
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
I don't know what you mean here.
-E
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
