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
