So I have to clarify that this discussion is about a language similar to J but not J itself, since obviously none of this stuff can be changed in J.
Maybe it makes sense to disallow fills altogether and instead result in an error. How much expressive power is really lost since you usually want to box the result anyways and might prevent errors (due to values being equal to fills)? The problem with boxed arrays is that they are not contiguous in memory with all the corresponding performance concerns. Has any thought been given to a more fine grained shape representation for ragged arrays? Possibly compressed in some form like below: j=:1+i. ravelWFill =: ,&.< ]ragged=: (j 2 2) ravelWFill ((j 2) ravelWFill (j 3)) 1 2 0 3 4 0 1 2 0 1 2 3 ]shapeOfRagged=: (<2),(<(<2 2),(<(<2),(<2,3))) +-+-------------+ |2|+---+-------+| | ||2 2|+-+---+|| | || ||2|2 3||| | || |+-+---+|| | |+---+-------+| +-+-------------+ On the other hand, how hard is it for the interpreter to recognized boxed arrays where the boxed items have the same rank (# @: $) and implement them as contiguous ragged arrays? (Perhaps the best solution if possible). Cheers, Mike Ps. I will be away for the weekend but will eagerly read all responses when I get back. On Thu, Jun 27, 2013 at 8:21 AM, Marshall Lochbaum <[email protected]>wrote: > 1) Fills need to be as unobtrusive as possible. This means they need to > keep the original array intact, and look distinct from the rest of the > array. Filling the front of an array would change which elements are at > which indices by moving each element up a few indices. This makes it > difficult to consistently index the array, so that's out. Cycling the > array is a bit more reasonable, but it has a few problems. First, the > cycled elements will look like data, making it hard to distinguish where > the fill has been added. Second, doing a cycle fill multiple times is > not equivalent to using one larger fill: > ]a=.i.4 > 0 1 2 3 > 8$6$a > 0 1 2 3 0 1 0 1 > 8$a > 0 1 2 3 0 1 2 3 > > 2) Yes, fills are a pain. In general, you should keep ragged data in > boxes rather than letting J concatenate it and fill out the shorter > elements. I can think of a few cases where fills are useful (working > with polynomials, which ideally are infinite lists where all but a > finite number of elements are zero, is one), but otherwise they will > probably just damage your data. > > Marshall > > On Wed, Jun 26, 2013 at 11:00:45PM -0700, Michal D. wrote: > > Hi All, > > > > I was wondering if any J implementors have some insight to share. > > > > (1) Is there a reason why fills are put in the places they are? Are > there > > any alternatives that were also explored? One might imagine filling the > > front of an array instead of the back, or cycling through the elements of > > the array instead of inserting fills. > > > > (2) They seem a little bit more tricky and unwieldy than I originally > > thought. Would others agree? > > > > Cheers, > > > > Mike > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
