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

Reply via email to