Interesting. Thanks for the links. It's neat that you've been able to avoid boxing with the trees. Don't know if it'll work for me, as I may not be able to pack the non-zero components quite as densely. Though, it's a nice goal to aim toward.
The s-expressions are cool. Once again, not sure. Will have to see if the parsing overhead is sufficiently low. These are all good suggestions. Cheers. On 10 Feb 2016 2:38 am, "Michal Wallace" <[email protected]> wrote: > I have an implementation of a "tree builder" interface here: > > http://tangentstorm.github.io/apljk/treebuild.ijs.html > > Rather than using a boxed array to build a tree, it uses a single > array to represent the parent links for all nodes. The actual data > can be stored in any number of parallel arrays. > > I also have a very simple graph database (triple store) here: > > https://github.com/tangentstorm/syndir/blob/master/graphdb.ijs > > Also an implementation of s-expressions (which you can stick > in a ( 0 : 0 ) block. > > https://github.com/tangentstorm/syndir/blob/master/boxer.ijs > > > On Tue, Feb 9, 2016 at 3:59 AM, Matthew Baulch <[email protected]> > wrote: > > > Suppose I wish to construct a complex, non-regular deeply nested > structure: > > to model some inherently non-linear system. A natural approach (for me, > > anyhow) is to construct a library of combinators, or a domain specific > > language, with which to specify the (boxed) structure. > > > > J rises easily to the task, and before long I'm looking at long function > > trains of the form > > > > myStruct =: c0 p0 c1 p1 c2 p2 ... cN pN > > > > where the ci are (combinator) verbs, and the pj are (parameter) nouns. > > Nice. Easy. > > > > Only trouble is, N may be large and J prefers such statements to sit on a > > single line. Correct? I can split my definition: > > > > msPartA =. ..... > > msPartB =. ..... > > ..... > > msPartX =. ..... > > myStruct =: msPartA msPartB .... msPartX > > > > though this feels awkward. The most obvious issue is that the PartA, ..., > > PartX are distracting; unless of course I can find a natural way of > > splitting and naming them. Ideally, the parts should be as close to a > > comfortable line width as possible. Again, awkward. If myStruct1 and > > myStruct2 have the same partitioning scheme but myStruct2 (for instance) > is > > much larger than myStruct1, there will be many sparsely, or many > > overpopulated lines. Awkward too. > > > > I love J. It handles complex regular data so elegantly. How can I bring > > similar elegance to irregular data? Can my combinators be rescued, or > > should I use another approach? > > ---------------------------------------------------------------------- > > 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
