Apologies for not considering that y was a boolean list.
You expressed a dislike for the presented gerund solution.
The gerund form of amend } is one of the more powerful J constructs because
replacing elements is a core data processing function, and the gerund version
covers all needed flexibility. It is difficult, imo, primarily due to careful
parentheses requirements of gerund building, and only verbs are permitted as
gerund parameters to } .
I recently posted a front end to } that does not require gerunds or verb
arguments and covers a broad framework for how } would be applied. v is an
index selection verb, and u a modification function. (new version correcting
for previous "bug")
ar =: 1 : '5!:1 <''u'''
amend =: [` ([. ` ar) `{`] `: 6 ` (]."_) `] }~~
a variation that applies if v is a boolean function, and I.@: should be applied
to it to create indexes to update:
amendI =: ]: amend (I.@:) NB. new tacit enhancement of (tacit) conjunction
+:@] amendI > NB. double items where x>y
([ +:@] I.@:> { ])`(I.@:>)`]} ~~
3 +:@] amendI > i.5
0 2 4 3 4
I brought this up, because it is a cool way to create in J an "update where"
(sql) function, and might be a useful approach to what you wanted to do.
On Thursday, December 23, 2021, 09:01:38 p.m. EST, Elijah Stone
<[email protected]> wrote:
On Thu, 23 Dec 2021, 'Pascal Jasmin' via Programming wrote:
> nn is an adverb that lets the passed in verb access x and y.
But x and y are a verb's arguments, which it has access to anyway. And
your examples seem to work exactly the same if one removes 'nn' from them.
I think I am still missing something.
> {{1 (,y#x)} y}}
>
> 1:`(,@#~)`]}
Yes, I mentioned this approach; it is not general, and I think it obscures
intent.
> but its not an obviously useful verb
It traces a subgraph. x is a list of pointers (i.e. indices into itself),
and y is a mask which selects some of those pointers. Then the result is
a mask which selects all the nodes y selects, and all the nodes pointed to
by those nodes. (I ravel because in this case x was a matrix, each row of
which was a list of pointers.)
-EB
> 2 (,@#~) i.3
>
> 2 2 2
>
> this is just going to amend the x index multiple times.
>
>
> 2 1:`(,@#~)`]} i.3
>
> 0 1 1
>
>
> On Thursday, December 23, 2021, 03:05:45 a.m. EST, Elijah Stone
> <[email protected]> wrote:
>
>
>
>
>
> I am not sure quite what you are getting at. (And I do not understand the
> difference between nn and ]:, unless it is to do with namespacing?)
>
> Here is a verb I wrote recently that I would like to be able to make
> tacit: {{1 (,y#x)} y}}
>
> It can be written as a tacit conjunction, but I would prefer the explicit
> verb, as verbs are easier to compose. (And in this particular instance,
> it was taken to a fixedpoint, so a conjunction would not work at all.)
>
> -E
>
> On Wed, 22 Dec 2021, 'Pascal Jasmin' via Programming wrote:
>
>>
>> This seems to work as a general approach?
>>
>> nn =. 1 : 'x u y'
>>
>> The new-old trains cover pretty completely your use scenarios
>> ACC
>> CCA
>> VCC
>> CCV
>> VCA
>> ACV
>>
>> 5 ([ 2 : 'u+v' -nn + ]) 3
>>
>> 10
>>
>> 5 ([ 2 : 'u+v' -@]nn + ]) 3
>>
>> 5
>>
>>
>> or with my compound modifier train framework
>>
>> 5 [ +F1 -nn +F ] 3
>>
>> 10
>>
>>
>> On Tuesday, December 21, 2021, 11:53:05 p.m. EST, 'Pascal Jasmin' via
>> Programming <[email protected]> wrote:
>>
>>
>>
>>
>>
>>>>
>> x] u C (v n.) y
>> [x] u C ([x] v y) y
>>
>> [x] u n. C v y
>> [x] ([x] u y) C v y
>>
>> [x] u n. A y
>> [x] ([x] u y) A y
>>
>>
>> you want n. to "dig through" the function to calculate a result using xy
>> before passing it to modifier without consuming/removing the xy arguments.
>>
>> For a specific (CA in your examples) modifier, this is easy as an explicit
>> definition.
>>
>> For a general function, you need to access x and y, and explicit seems like
>> the best bet with passing in a representation of the modifier.
>>
>>
>>
>> On Tuesday, December 21, 2021, 09:24:58 p.m. EST, Elijah Stone
>> <[email protected]> wrote:
>>
>>
>>
>>
>>
>> With all this discussion of tacit modifiers, I fear their lower-order
>> cousins are going out of style!
>>
>> The proof of completeness for trains
>> (https://code.jsoftware.com/wiki/Essays/Trains#Proof_of_Completeness)
>> contains two concerning notes:
>>
>>> Without loss of generality, assume that [sentence] s contains no
>>> copulae; for if it does, d=.rhs (say), recursively replace instances of
>>> d by (rhs)
>>
>> This transformation is problematic if rhs performs side effects; for it
>> may cause those effects to be performed more than once, or not at all; or
>> to be sequenced differently relatively to other side effects.
>>
>> In some cases, it may nevertheless possible to straightforwardly express
>> an effectful verb tacitly. For instance:
>>
>> {{ a=. 0 [ echo y
>> a + y + a }}
>>
>> becomes:
>>
>> (] + [ + ]) (0 [ echo)
>>
>> but some are not so straightforward
>>
>> {{ a=. 0 [ echo y
>> b=. 0 [ echo y
>> a + b + y + a + b }}
>>
>> It can be done, of course, but not without cheating (e.g. by using boxes,
>> or by observing that + is commutative).
>>
>> Question: what is a clear and concise definition of the subset of
>> effectful explicit verbs which may be made tacit without cheating?
>>
>>
>>> Suppose s is a sentence [that] makes no use of x. or y. as arguments to
>>> an adverb or conjunction
>>
>> A shame; on multiple occasions, I have wanted to do exactly this, and have
>> had to write explicit code. (In some cases, it is possible to get around
>> the problem by passing a gerund to the conjunction; but that is not
>> general; it is somewhat obscure; and frequently requires redundant [ or ].)
>>
>> Suggestion: a new primitive adverb. Call it 'n.'. Like [:, it is
>> syntactically regular, but semantically irregular. Just as there is a
>> rule for the evaluation of forks whose left tines are [: which takes
>> precedence over the regular rule for the evaluation of forks, so are there
>> rules for the evaluation of sentences containing n. which take precedence
>> over the rules for evaluation of ordinary sentences:
>>
>> [x] u C (v n.) y
>> [x] u C ([x] v y) y
>>
>> [x] u n. C v y
>> [x] ([x] u y) C v y
>>
>> [x] u n. A y
>> [x] ([x] u y) A y
>>
>> Objections:
>>
>> - n. assumes that modifiers return verbs. Something like 'u n. A'
>> _must_ be assumed to be a verb for this mechanism to make any sense.
>> Evaluation of A must be deferred, which is even more irregular than [:.
>>
>> - The common case of u C (f y) requires many parentheses if the input is
>> modified by a train: u C ((f g h)n.). (On the other hand, this is no
>> worse than the explicit code, which must write u C ((f g h) y).
>> NARS2000 suggests a mitigation in the form of higher-order modifiers:
>> assuming a higher-order ~, one might write (f g h)n. ~C u. This is not
>> a serious suggestion.)
>>
>> -E
>> ----------------------------------------------------------------------
>> 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