On Sun, May 15, 2022 at 1:03 PM Henry Rich <[email protected]> wrote: > I'm not sure about 'should'. I think the case needs to be made. > > There is no room in the memory header, whose format cannot be changed > because of required compatibility with existing mapped files. > > You could use a word after the boxed data to hold the level.
Hmm... I am pretty sure that J does not support mapped boxed data, so it seems like there should not be a compatibility issue from extending the header for boxed data (for example, as a suffix to shape but only for the boxed array type). Though there might be other awkwardnesses... (this would be a pervasive change). But... allocating memory for an array requires knowing the type of the array. And... it's true that depth can be derived by traversing the entire boxed structure -- that's how L. currently works -- but it's information which is similar to shape, rank and type. So, it seems to me that it makes sense to track it in roughly the same way. As for "should"... I was thinking in terms of performance for (L.) and (u L:n) with negative n. These are particularly useful for large and deep boxed arrays, but the current implementation performs poorly for those cases. Now... I'm not saying "should" in the sense of some kind of immediate imperative. I was thinking more as an ideal -- as in: how it seems (to me) that J should eventually work. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
