I really have a different idea of your first paragraph. Here's how I would approach it:
A=:6 B=:7 A+B 13 +:A+B 26 Use math to get the answer you want. Explain your plan with an explicit definition which is more general. Now try it. f=: 13 :'+:x + y' A f B 26 Look at the final definition. There is no need to explain @ or @: f [: +: + The result is readable, and the cap is chosen by J to indicate how your two verbs are to be applied. Linda -----Original Message----- From: programming-boun...@forums.jsoftware.com [mailto:programming-boun...@forums.jsoftware.com] On Behalf Of Dan Bron Sent: Monday, March 03, 2014 9:32 PM To: programm...@jsoftware.com Subject: Re: [Jprogramming] bug in & ? Here's another a way to think about it. Let's say we want to double the sum of two numbers (and these numbers will be derived from our inputs rather the raw inputs themselves). The core function here is "sum doubling", so let's write that first. Well, we know how to do that. It's every-day, classic J: +:@+ . So far, so good. But now we realize we want to process our inputs a little first before we double their sum. That is, we do want to double their sum, BUT FIRST, we want to double them individually (in effect, we're summing 4x each input, but using 3 steps instead of 2). That "BUT FIRST" is key. It's how Kirk Iverson taught me to voice "&" when it's used to compose two verbs (as opposed to composing a verb with a noun). So: double =: +: of =: @: sum =: + but_first =: & dsBFd =: double of sum but_first double 2 dsBFd 3 20 So the insight is to separate the questions of "sum doubling" and "input doubling". Having done that, we recognize that "sum doubling" is nothing new, it's just two verbs composed with @ like we do every day (as opposed to two verbs composed with &, which is rarer). The & is only needed when we want to do something BUT FIRST do something else. That is to say, sum-doubling is the doubling of _one thing_ (sum takes 2 inputs but only produces 1 output, and it's the double of that solitary output we want to return), but since we're defining a dyad, here input-doubling is the (symmetric) doubling of _two things_ (each of our inputs, individually). If we want to apply the a verb (double) to the result of a monad (a solitary thing), we use @ as usual; if we want to symmetrically process both inputs to a dyad (here, +), we use & . If we only had one input (i.e. were defining a monad), we could use @ in place of & for the rightmost composition too (but then, of course, we wouldn't have a pair of numbers to sum, so + wouldn't do anything and would just output its solitary input). Hope that helps, -Dan ----- Original Message --------------- Subject: Re: [Jprogramming] bug in & ? From: Dan Bron <j...@bron.us> Date: Mon, 3 Mar 2014 20:19:03 -0500 To: "programm...@jsoftware.com" <programm...@jsoftware.com> I owe you a longer reply, but I'm having trouble finding the time recently. In short, if you compose a vet using only &, then x and y won't be combined until te very last verb. As Raul said, your expression is equivalent to the one he gave, and no amount of parenthesizing will change the meaning of & from "post processor" to "pre processor". If you want to "force monad", you should use @ instead of & . For example, if you want a verb that gives the double of the sum of twice x plus twice y, then you could say +:@+&+: : double=: 3 :'smoutput ''monad only'' label_. +: y ' : (4 : ' smoutput x label_. +: y') double ( (+:2) + (+:3) ) monad only 20 2 double@+&+: 3 monad only 20 2 +:@+&+: 3 20 Sent from my iPhone > On Mar 3, 2014, at 1:54 PM, Raul Miller <rauldmil...@gmail.com> wrote: > > 2 double &(+&+:) 3 > > is equivalent to > (++:2) double (++:3) > > And since neither 2 or 3 has an imaginary part, we can eliminate the > complex conjugate which means we have: > (+:2) double (+:3) > > Does that help? > > Thanks, > > -- > Raul > >> On Mon, Mar 3, 2014 at 11:10 AM, Pascal Jasmin <godspiral2...@yahoo.ca> wrote: >> thank you for your explanations dan, >> >> double =: 3 : 0 >> +: y >> : >> smoutput x >> +: y >> ) >> >> >> 2 (double &+)&+: 3 >> 4 >> 12 >> >> 2 double &(+&+:) 3 >> 4 >> 12 >> >> this I understand >> 4 (double &+) 6 >> 4 >> 12 >> >> and this >> (double &+) 6 >> 12 >> >> so this feels like a bug: >> >> 2 double &(+&+:) 3 >> 4 >> 12 >> >> should be able to parenthesize to force monad. Though I get what is happening to a slight degree, its extremely unusual that x gets modified. >> >> ----- Original Message ----- >> From: Dan Bron <j...@bron.us> >> To: "programm...@jsoftware.com" <programm...@jsoftware.com> >> Cc: >> Sent: Sunday, March 2, 2014 1:59:14 PM >> Subject: Re: [Jprogramming] bug in & ? >> >> Looking at that table, it's clear that the monadic cases of @ and & are identical, so the difference lies in how they combine dyadic verbs. So maybe a simpler or more intuitive way to express the difference is: @ expresses that you want x and y to "meet" _first_, and & expresses you want x and y to meet last. >> >> I think this definition will allow us to understand expressions like yours more intuitively. Rather think of grammar and precedence and rules of substitution, we just note that +:&+&+: is composed solely with &, so the combination of x and y will be deferred to the very end, pushed to the leftmost verb; therefore that +: will be called dyadically, and since dyad +: has a Boolean domain (both left and right), it will raise a domain error when invoked with integers (4 and 6 in this case). >> >> Sent from my iPhone >> >> >>> On Mar 2, 2014, at 10:59 AM, Dan Bron <j@bron. That tablus> wrote: >>> >>> The sentence 2 +&+&+: 3 expands to (+ +: 2) + (+ +: 3) . This might be clearer if we used 3 distinct verbs: x f&g&h y is (g h x) f (g h y) . >>> >>> In f&g, f retains the valence of the whole verb (is ambivalent), and g is always called monadically. By contrast, in f@g, f is always called monadically, while g retains the valence of the whole verb (is ambivalent). * >>> >>> expression | monad (exp y) | dyad (x exp y) >>> f&g | f g y | (g x) f (g y) >>> f@g | f g y | f (x g y) >>> >>> (All subject to the rank of g; the rank-independent analogs are &: and @: respectively). >>> >>> -Dan >>> >>> * Note that The symmetry is not perfect: in f&g, g could be called at most twice, if the whole verb is called dyadically (and g is applied monadically the the right argument and again monadically to the left argument), whereas in f@g, f will be called exactly once (monadically to the result of g, whether g itself was called monadically or dyadically; in short, the asymmetry mirrors the asymmetry of dyads, which take 2 inputs but produce 1 output). >>> >>> Sent from my iPhone >>> >>>> On Mar 2, 2014, at 10:33 AM, Pascal Jasmin <godspiral2...@yahoo.ca> wrote: >>>> >>>> That is indeed the problem, but the code >>>> >>>> 2 +&+&+: 3 >>>> >>>> >>>> is not 2 + 2 +&+: 3 >>>> >>>> but rather >>>> 0 + 2 +&+: 3 >>>> 10 >>>> when it should be: >>>> + 2 +&+: 3 >>>> 10 >>>> >>>> There doesn't seem to be a good reason to insert 0 v in it. This is weird though: >>>> >>>> 2 ([: +: ])&(+&+:) 3 >>>> 12 >>>> >>>> I don't think it is: >>>> >>>> 2+ 2 +&+:3 >> ---------------------------------------------------------------------- >> 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
