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
