I'm glad you are having success with Fold. Responding to your points:
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.
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.
1. I have traces from user code where the expense of reversing a list is
important enough to avoid.
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.
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.
5. The notations F:... and Fold Multiple * both are meant to stand in
for 'F:, F:., or F::'
6. If you don't like ((%@[+])~), I suggest (+ %) .
5, 6, 7. It's a Wiki. If you think the documentation could be improved,
go ahead and improve it.
Henry Rich
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