Thanks for comments and patience with me.
> 3. To me, right-to-left, as in u/, has become 'natural'. So we just disagree
> on that point. I would change it only if there is an immediate and
> overwhelming call by users to do so. If we were having this discussion
> during the beta period, I would be less resistant to changing it.
The u/ right-to-left is natural to me as well. But I can’t see (at the
moment anyway) how Fold can be thought of or construed as as in “insert and
evaluate" operation on a list. After all F:. specifically moves forward
through the items of y (left to right, if you will). Ok I will keep wracking
my brain to try and make it “natural” to flip x an y once they are passed
inside to v.
> 0. I expect that most iterations with Fold will have an initial value, but I
> don't see why that should be enforced. Can allowing omission of an argument
> really be said to cause 'clutter'? I think that once a user understands the
> operation of Fold, the optionality of x will not cause misunderstanding.
I see your point. But my issue was more related to how x (u F:. v) y matches
(u F:. v) x,y and that seems superfluous/not useful to me. Perhaps there is
another use of monadic (u F:. v) that would be natural/useful (Although, at
this stage, I have no idea of what that might be)
> 1. I have traces from user code where the expense of reversing a list is
> important enough to avoid.
I can appreciate this might happen. Thanks.
> 2. Currently Fold is implemented in a J script. You are seeing that script.
> I agree that's ugly. But the script is temporary anyway - once the spec has
> seen enough use to convince us it is right, I will code it inside the JE.
Ok. Thanks for the explanation. I thought it was some kind of “bug."
> 4. If the result of each calculation is big, it is important not to have to
> save them all. For example, each step may pass a large table to the next
> step.
>
Again, I agree this can happen.
> 5. The notations F:... and Fold Multiple * both are meant to stand in for
> 'F:, F:., or F::'
Thanks.
>
> 6. If you don't like ((%@[+])~), I suggest (+ %) .
With (+%) you have to mentally switch x and y in that the previous result is
reciprocated prior to the addition of the latest y (now appearing on the left).
With the awkward ((%@[+])~) the (%@[+]) tells you are adding the latest y
to the reciprocal of the previous iteration result and the ~ has to be used as
an “anti switch” to counter the switch performed by fold. (Ok. This is all
very convoluted but illustrates how I don’t (yet?) find your way of thinking as
“natural."
> 5, 6, 7. It's a Wiki. If you think the documentation could be improved, go
> ahead and improve it.
Not familiar with how I can edit the documentation and would not be comfortable
doing without some reassurance that my suggested changes would in fact be an
improvement.
>
> On 7/8/2020 8:13 AM, Piet de Jong wrote:
>> I've been experimenting with the new fold conjunction F:. . I think it's
>> a very useful addition to J and thank all those who have made this
>> possible. Nevertheless I have some comments/reactions. These are made
>> in a constructive spirit. Perhaps these comments just display my own
>> ignorance and J ineptitude. I make these comments as someone who has
>> worked in Kalman filtering and smoothing which seem perfect candidates for
>> Fold. In fact I implemented Kalman filtering with F:. and found a dramatic
>> increase in both computational speed and ease of coding, and a drastic
>> reduction in J code clutter.
>>
>> 0) Is the monadic case useful? To my mind it just creates potential
>> confusion and "clutter": most iterations can be thought of as an initial
>> condition (x) with iterations which consume y.
>> 1) Why have Fold forward AND Fold reverse. Can't you just have Fold
>> forward leaving the reverse to be treated as (u F:. v |.) I realise this
>> assumes the dyadic case (see 0)
>> 2) When you type u F:. v into the interpreter I get a whole lot of "code"
>> rather than the usual boxed representation. Is this intentional?
>> 3) I made the comment in a previous post that the switching of x an y
>> between (u F:. v) and v is very confusing to me. It just doesn't seem
>> natural. The x in x (u F:. v) y is the natural "initial condition". In
>> each iteration the "natural" initial condition is the output of the previous
>> iteration and I suspect most people would think this way.
>> 4) Is F.. really useful? Why can't users just implement {:@(u F:. v),
>> picking off the last result.
>> 5) The documentation section "which primitive should I use", refers to
>> F:... -- I don't understand what the three dots stand for. Nor do I
>> understand what eg "Fold Multiple *" means (ie the *).
>> 6) The documentation section "Common uses" part 1, gives, according to me a
>> confusing and perhaps non constructive example. The y (from the point of
>> view of u F:. v ) sequence is not used at all other than being printed out
>> (as the x of v). Perhaps a more instructive example would be iteration
>> of the form z_t=1/z_{t-1} + y_t.
>> implemented as (]F:.((%@[+])~)). (As per 3 I really dislike having to use
>> ~)
>> 7) Somewhere in the documentation it states that "The first application of
>> v consumes 2 items of y." If I understand things correctly this is only
>> true for the monadic case.
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
>
> --
> This email has been checked for viruses by AVG.
> https://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
