Oops, I inadvertently left out the definition of Cmn. (Odd.. I thought
I remembered copying that into my message.)
Anyways, it was really basic;
Cmn=: 2 :'m+n'
Thanks,
--
Raul
On Mon, Feb 17, 2020 at 11:18 AM Raul Miller <rauldmil...@gmail.com> wrote:
>
> So here's the deal with Henry's point 3:
>
> Cxmny=: 2 :'x+m+n+y'
> (>: i.3) Cxmny (*:9)
> (1 2 3) (2 : (':'; 'x+m+n+y')) 81
>
> Here, m .and n have been evaluated, but are represented as nouns, not
> as text. You see a formatted representation but the internal
> representation is binary
>
> (>: i.3) Cmn (*:9)
> 82 83 84
>
> Here, there is no pending evaluation. This operation is basically the
> same as addition (except with different syntax so -- hypothetically --
> it might happen earlier during parsing, which might effectively give
> you an implied set of parenthesis.
>
> Now, your expression is a bit different -- you've other verbs which
> will not be evaluated inside your conjunction. But what you're not
> seeing is the tree structure of the partially evaluated expressions
> (which, in turn, reflects the syntax of the language).
>
> To accomplish what you were suggesting, as a general operation, the m
> and n nouns would have to be represented as text within a copy of the
> conjunction. Like this:
>
> (>: i.3) Cxmny (*:9)
> 2 :'x+1 2 3+81+y'
>
> Now... it's true that this particular example could instead be
> represented as something like:
> (>: i.3) Cxmny (*:9)
> [ + 1 2 3 + 81 + ]
>
> But that's because this is a simple example -- this kind of
> transformation won't work for the general case. It could be attempted
> for simple cases, but the attempt isn't free, so we'd want something
> like 12 :'x+m+n+y' for that feature, instead of hijacking (2 :)
> expressions, and no one has implemented that yet. (It might be worth
> the effort though -- mostly it's about taking the (13 :)
> implementation and getting it to treat m and n the intended way.)
>
> Anyways... the hardest parts to understand, when using english, are
> the unstated assumptions. I am hoping this helps by stating one of
> those that I think cropped up here.
>
> Or, put different: am I making sense to you?
>
> Thanks,
>
> --
> Raul
>
> On Mon, Feb 17, 2020 at 2:13 AM Hauke Rehr <hauke.r...@uni-jena.de> wrote:
> >
> > All my fault :/
> > In the sentence that didn’t behave as expected,
> > I used a variant of my conjunction that actually
> > wasn’t defined tacitly: there were references to y
> > which kept m and n (and thus constant expressions
> > they were occurring in) from being evaluated when
> > the derived verb was built.
> >
> > Sorry for the noise …
> >
> >
> > @Henry Rich
> > I disagree with your point 3.
> > The verb (? 1e9 1e9)&(+/ . *) has that large matrix inside.
> > Why would verbs be allowed to know about a large constant
> > when conjunctions are not?
> >
> > this has to stay the programmers’ responsibility
> > the language should provide the means to do what
> > might be desirable (and J does so when used tacitly);
> > if anyone abuses these possibilities
> > they’ll have to bear the blame for the consequences
> >
> > All I wanted was subexpressions being evaluated,
> > and that I got when I turned my code tacit.
> > for reference:
> > essentially what I wanted (and got) is this behaviour:
> > (apologies for another not very useful example)
> >
> > con =: 2 : '((>./ m) * (>: m) #~ (# n) <. ])'
> > (i. 3) con (i.5)
> > 2 * 1 2 3 #~ 5 <. ]
> >
> > I didn’t use (>./ * >:) for in my actual expression I wound up
> > with a more complicated structure where it wouldn’t have
> > been that easy to mention m just once – it was hard enough
> > getting rid of those references to y
> >
> >
> > Am 16.02.20 um 16:39 schrieb Henry Rich:
> > > Several misconceptions.
> > >
> > > If the body of c refers to y, m c n produces a verb that operates on a
> > > subsequently-given [x]/y. I will assume that is what you are using,
> > > since the only way to produce a modifier is using an explicit definition.
> > >
> > > In this case, you must distinguish between the execution of c, in m c n,
> > > and the execution of the /derived verb/ (m c n) in the later x (m c n) y.
> > >
> > > The execution of c does very little: it remembers the values of m and n
> > > and packages them with the body of c into the derived verb. m and n are
> > > not 'evaluated', because by the time they get to c they have already
> > > been reduced to a single noun value.
> > >
> > > When the derived verb is executed, it refers to m and n by name, which
> > > is quite efficient.
> > >
> > > It sounds like you expected the words m and n to be replaced in the body
> > > text of c by the value when the derived verb was created. This would
> > > have ill effects:
> > >
> > > 1. m and n are allowed to be redefined during execution of the derived
> > > verb
> > > 2. there is no word that can replace m/n to define a general noun value
> > > - an expression would be required
> > > 3. J doesn't know about named constants; it knows only nouns. m and n
> > > could be megabytes in size. Installing them into a sentence would be
> > > inefficient.
> > >
> > > Henry Rich
> > >
> > > On 2/16/2020 3:05 AM, Hauke Rehr wrote:
> > >> Hello everybody,
> > >>
> > >> I recently stumbled upon some at least
> > >> for me counterintuitive (read: puzzling) behaviour:
> > >>
> > >> In a verb like (>: X) {~ ], when X is a defined constant,
> > >> the constant expression (>: X) is substituted in the verb (as expected)
> > >> but in a conjunction M c N, when M and N are defined constant nouns,
> > >> constant expressions are not substituted in c’s body (not expected)
> > >>
> > >> I would not want m c n to be evaluated time and again
> > >> when some part of it, just like in the case of the verb above,
> > >> could be evaluated once when defining the derived verb.
> > >> This should result in major savings of computational
> > >> resources so I’d have expected J to do this.
> > >>
> > >> could anyone tell me why this is different from verbs?
> > >>
> > >> kind regards,
> > >> Hauke Rehr
> > >> (Jena, Germany)
> > >>
> > >>
> > >
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> > --
> > ----------------------
> > mail written using NEO
> > neo-layout.org
> >
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
