> 1. As defined, u always executes as ((new item) u (previous result))

even when forward?

> (rest_of_u@(1&Z:^:stop_condition))

it would seem like Z: could ignore left argument (if provided) then,

with 

rest_of_u@(Z:^:stop_condition) 

returns last iteration/result

(Z:^:stop_condition)@rest_of_u
returns this iteration

they basically all return y from Z: (and abort F. and any continuation of the 
verb (ie. v in v@Z:) as side effect)

That would seem to offer full functionality such that 1 _1 left args not needed?

> 6. Perhaps there should be a 'continue' left-argument to Z: so that ^: 
wouldn't be needed. 


I think Z: is ok as a verb rather than adverb,

instead of above sequence formulations, there is also

finish_part_of_u`Z:@.test@first_part_of_u

________________________________
From: Henry Rich <henryhr...@gmail.com>
To: programm...@jsoftware.com 
Sent: Friday, March 2, 2018 12:21 PM
Subject: Re: [Jprogramming] Insert initialising



1. As defined, u always executes as ((new item) u (previous result))

2. x, if given, is the first (previous result)

3. The choice of x arguments to Z: should be mnemonic.  I think _1 for 
abort and 1 for normal completion is a little more natural.

4. It would be reasonable to create (i. 0) rather than domain error when 
there are no executions of v .  We can talk about that.

5. (rest_of_u@(1&Z:^:stop_condition)) or 
((1&Z:^:stop_condition)@:rest_of_u)would be normal use

6. Perhaps there should be a 'continue' left-argument to Z: so that ^: 
wouldn't be needed.

Henry Rich



On 3/2/2018 12:02 PM, 'Pascal Jasmin' via Programming wrote:
> 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

----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to