Very eloquent! _2 (128!:2)&.>/\"1 y
and it works for y of any rank. You're probably right that an ASCII name of its own would be better. Not many primitive names available, it seems. Oh well. On Wed, Feb 10, 2016 at 9:20 PM, Henry Rich <[email protected]> wrote: > No, _2 (128!:2)&.>/\ y > > Henry Rich > > > On 2/10/2016 5:16 AM, Henry Rich wrote: > >> The operation you describe is >> >> _2 (128!:2)&.>\ y >> >> I think the current definition of 128!:2 is a better primitive definition. >> >> I agree that it deserves a spot in the ASCII names. >> >> Henry Rich >> >> On 2/10/2016 3:59 AM, Matthew Baulch wrote: >> >>> Thanks for pointing that one out. Hadn't noticed it before. I find it >>> bizarre that it's regarded as a foreign. It seems like it deserves a >>> mention in the NuVoc page for ". y . >>> >>> Perhaps (128!:2) could be moved to the (currently undefined?) case of ". >>> y >>> where y is a box array? I suppose we could require that: >>> >>> (1) 0 -: 2&|{:y >>> (2) items of 1-cells with even indices unbox to a character list >>> (3) items of 1-cells with odd indices unbox to a noun >>> >>> Each such pair would map to a box in the result obtained by unboxing, >>> applying 128!:2, reboxing. >>> >>> Alternatively, we could have: >>> >>> (1A) 2 -: {:y >>> >>> and have an unboxed result. >>> >>> Or we could not bother and keep 128!:2. Hmm. Not sure what is best. I >>> suppose there is a mild efficiency advantage. I imagine the cost of >>> parsing >>> x dwarves the cost of a box and unbox operation. >>> >>> Just an idea. >>> On 10 Feb 2016 1:32 pm, "Henry Rich" <[email protected]> wrote: >>> >>> Look also at 128!:2, which takes a verb as a string argument and applies >>>> that verb to y. >>>> >>>> Henry Rich >>>> >>>> >>>> On 2/9/2016 9:10 PM, Matthew Baulch wrote: >>>> >>>> Thanks. I think this is what I was looking for. >>>>> >>>>> I was aware of 'noun define' but didn't know it could be used in this >>>>> way. >>>>> Good point about c0. >>>>> >>>>> Documentation, I agree, is particularly important with this style of >>>>> code. >>>>> My view is certainly not that definitions spanning multiple lines >>>>> should >>>>> be >>>>> commonplace. It is nice to know, however, that it is possible. >>>>> >>>>> Cheers. >>>>> If you do not have good names for partial calculations, that might be >>>>> a sign that you need to think a bit more about the abstractions you >>>>> are using. It can be difficult for other people to read if you don't >>>>> make sufficient effort to label your abstractions. >>>>> >>>>> Also, I would note that your 'c0' is not a combinator, as you are not >>>>> using its dyadic definition. So you might want to use a different name >>>>> for that one. Perhaps: >>>>> >>>>> v0=:c0 >>>>> >>>>> That said, if you really want to execute really long lines, you can do >>>>> that using ". 0 :0-.LF and indented text. (You need the indentation >>>>> because line feeds will not separate words here.) >>>>> >>>>> For example: >>>>> >>>>> myStruct=: ". 0 :0-.LF >>>>> v0 p0 c1 p1 c2 p2 c3 p3 c4 p4 c5 p5 c6 p6 c7 p7 c8 p8 c9 p9 >>>>> c10 p10 c11 p11 c12 p12 c13 p13 c14 p14 c15 p15 c16 p16 c17 >>>>> p17 c18 p18 c19 p19 c20 p20 c21 p21 c22 p22 c23 p23 c24 p24 >>>>> c25 p25 c26 p26 c27 p27 c28 p28 c29 p29 c30 p30 >>>>> ) >>>>> >>>>> I hope this helps, >>>>> >>>>> -- >>>>> Raul >>>>> >>>>> On Tue, Feb 9, 2016 at 4: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 >>>>> >>>>> ---------------------------------------------------------------------- >>>> 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 >> > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
