> 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
