im ok with all 6 versions as defined.
for F.. (forward definition), first execution
dyad should be x u 0 { y
monad can be in the same spirit as your original (0{y) u 1{y
this is consistent with the next iteration(s) being result u 2{y
A question on Z:,
_1 argument might more common than 1? and if so, parameters should have reverse
meanings.
it is expected that u will contain Z: as an exit condition... and so included
as:
(1 ]`Z:@.condition rest_of_u) F. v
or
(x ]`(1&Z:)@.condition rest_of_u ) F. v
if the condition trips on the "first run", an x argument of 1 returns the
result of rest_of_u. _1 returns result of previous iteration?
A very natural alternative to returning a domain error, would be to return "the
initial result" which is often x. Just because the first item of y argument
tripped the exit condition shouldn't need a special handler.
________________________________
From: Henry Rich <henryhr...@gmail.com>
To: programm...@jsoftware.com
Sent: Friday, March 2, 2018 11:09 AM
Subject: Re: [Jprogramming] Insert initialising
When x is given, only the dyadic valence of u is executed. The
definition of what happens there is open to improvement.
I think mnemonic value is far more important than typing speed. I chose
the first character ./.. to mean Single/Multiple (number of results,
that is) and the second ./..// to be forward/backward/no direction.
Henry Rich
On 3/2/2018 10:53 AM, 'Pascal Jasmin' via Programming wrote:
> The alternative to the monad version is
>
> (u0 x) u1 F. v y
>
> instead of
>
> x u0@[ : (u1) F. v y
>
> I put u1 in parens because it is likely a compound verb.
>
> I've written both a "forward" explicit version of this and a tacit boxed
> version of "reverse", and favouring the tacit version, found I had no
> difficulty using only the tacit one. I'd probably be fine if the short ops
> (F. and F:) where the forward or reverse one.
>
> The issue I am bringing up is one of optimizing for typing speed. Perhaps
> there is no important software cost to having 6 instead of 2 ops. The ones
> that get the F. and F: mnemonics should be the best ones (from a typing
> efficiency perspective).
>
> Maybe there is a case that current F. definition meets this criteria?
>
>
> On the other hand, its important that F.. and F:. are effectively the same.
> And so if there are 6 ops, the existing assignment is ok.
> ________________________________
> From: Henry Rich <henryhr...@gmail.com>
> To: programm...@jsoftware.com
> Sent: Friday, March 2, 2018 9:32 AM
> Subject: Re: [Jprogramming] Insert initialising
>
>
>
> From my own use, I use the Forward versions more than the Reverse, by a
> large margin, and I don't want to force the user to use |. needlessly.
>
> Henry Rich
>
> On 3/2/2018 9:12 AM, 'Pascal Jasmin' via Programming wrote:
>> Very useful overall, but may I suggest 4 F. family versions (ommitting the
>> forward version). This improves editability among variations, IMO, and
>> makes the operator codes easier to remember.
>> With the above change, F. and F.. mnemonics should be swapped. The "monad
>> first execution" has fewer applications than "initial value for reduce".
>>
>> From: Henry Rich <henryhr...@gmail.com>
>> To: programm...@jsoftware.com
>> Sent: Friday, March 2, 2018 5:11 AM
>> Subject: Re: [Jprogramming] Insert initialising
>>
>> Marshall, please criticize the proposal at
>>
>> http://code.jsoftware.com/wiki/System/Interpreter/Requests#Fold_.28strawman.29
>>
>> Others' criticism welcome too.
>>
>> Henry Rich
>>
>> On 3/2/2018 3:38 AM, Marshall Lochbaum wrote:
>>> There's no clean way to do it. If the result of the first invocation of
>>> f has the same type as the rest of the list elements, you can do
>>>
>>> f/ _2 (}. , f0/@:{.) l
>>>
>>> and if it has a different type you can check whether the right argument
>>> has this type (like your "signature structure", but implicit).
>>>
>>> One of my most missed features in J is a reduce with a specified initial
>>> element. Thus (l f/ e) would be equivalent to (> f&.>/ (<"_1 l),<e) but
>>> without the very large inefficiency of boxing everything. Of course
>>> dyadic f/ is already taken, so it would need another symbol. With this
>>> feature, you could use (_2 (}. f/ f0/@:{.) l) regardless of the
>>> properties of f.
>>>
>>> If your initialization comes before any of the processing and doesn't
>>> change the arguments (so that the first function invocation f0 is
>>> equivalent to (f[i0) for some initializer i0), then you can use
>>> (f/ l [ i0/ _2{.l), that is, separate the initialization from the
>>> function application completely.
>>>
>>> Marshall
>>>
>>> On Fri, Mar 02, 2018 at 01:51:39PM +0530, Arnab Chakraborty wrote:
>>>> Hi,
>>>>
>>>> If f is a dyad, then
>>>>
>>>> f/ 2 4 5
>>>>
>>>> means
>>>>
>>>> 2 f 4 f 5
>>>>
>>>> where the rightmost occurence of f is invoked first. I am wondering if
>>>> there is a smart way to recognize this first invocation separately from the
>>>> rest. This will enable me to perform some initialization inside f. By
>>>> "smart" I mean something smarter than the followung two:
>>>>
>>>> 1) using side effect like setting a global flag.
>>>> 2) adding some signature structure to the output of f (eg, 'inited';
>>>> result),
>>>> and then checking the absence of this signature.
>>>>
>>>> Thanks.
>>>> ----------------------------------------------------------------------
>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>> ---
>> This email has been checked for viruses by AVG.
>> http://www.avg.com
>> ----------------------------------------------------------------------
>> 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
