Oops, ravelWFill should be appendWFill =/
On Fri, Jun 28, 2013 at 9:15 PM, Michal D. <[email protected]>wrote: > 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
