Right, an efficient version of fold is long overdue (it has been mentioned,
at least, since 2003).
Since this is the chat forum I can mention a fork of J. Jx 1.1 conjunction
&:. is a simplified version of the proposed F.; yet, it has satisfied my
particular needs for almost a decade. Its full description is in the
corresponding documentation. Just for the purpose of conveying what it
does, I am using symbolic verbs and nouns here,
X0=. 'X0' [ Y0=. 'Y0'
u=. ('('"_ , 'u '"_ , ] , ')'"_) : ('('"_ , [ , ' u '"_ , ] , ')'"_)
u Y0
(u Y0)
X0 u Y0
(X0 u Y0)
and so on. Also, I am using boxing (and the verb ,.) only for illustration
(beware of wrapping),
JVERSION
Engine: j806/j64/windows
Beta: BEST/2017-10-06T14:44:47
Library: 8.06.09
Qt IDE: 1.6.2/5.6.3
Platform: Win 64
Installer: J806 install
InstallPath: j:/program files/j
Contact: Jx-patches
NB. Use fixed width to display the boxes properly...
,. ( X1;X2;' .. ';XN) ([ (u&.>) &:. (''"_) <@:] ) Y0 NB. No history
┌──────────────────────────────────┐
│┌────────────────────────────────┐│
││(XN u ( .. u (X2 u (X1 u Y0))))││
│└────────────────────────────────┘│
├──────────────────────────────────┤
│ │
│ │
│ │
│ │
│ │
└──────────────────────────────────┘
,. ( X1;X2;' .. ';XN) ([ (u&.>) &:. (] ) <@:] ) Y0 NB. Complete
history
┌───────────────────────────────────────────────────────────
───────────────────────────────┐
│┌────────────────────────────────┐
│
││(XN u ( .. u (X2 u (X1 u Y0))))│
│
│└────────────────────────────────┘
│
├───────────────────────────────────────────────────────────
───────────────────────────────┤
│┌──┬─────────┬────────────────┬─────────────────────────┬──
──────────────────────────────┐│
││Y0│(X1 u Y0)│(X2 u (X1 u Y0))│( .. u (X2 u (X1 u Y0)))│(XN u ( .. u (X2
u (X1 u Y0))))││
│└──┴─────────┴────────────────┴─────────────────────────┴──
──────────────────────────────┘│
└───────────────────────────────────────────────────────────
───────────────────────────────┘
,. ( X1;X2;' .. ';XN) ([ (u&.>) &:. (v&.>) <@:] ) Y0 NB. Partial
history
┌───────────────────────────────────────────────────────────
───────────────────────────────────────────────────┐
│┌────────────────────────────────┐
│
││(XN u ( .. u (X2 u (X1 u Y0))))│
│
│└────────────────────────────────┘
│
├───────────────────────────────────────────────────────────
───────────────────────────────────────────────────┤
│┌──────┬─────────────┬────────────────────┬────────────────
─────────────┬────────────────────────────────────┐│
││(v Y0)│(v (X1 u Y0))│(v (X2 u (X1 u Y0)))│(v ( .. u (X2 u (X1 u
Y0))))│(v (XN u ( .. u (X2 u (X1 u Y0)))))││
│└──────┴─────────────┴────────────────────┴────────────────
─────────────┴────────────────────────────────────┘│
└───────────────────────────────────────────────────────────
───────────────────────────────────────────────────┘
On Sun, Mar 4, 2018 at 9:22 AM, james faure <[email protected]> wrote:
> It's doubtful to me that fold deserves to be a primitive rather than a
> verb in the z_locale. Michael Lochbaum says, quite rightly, that the
> problem with '(> f&.>/ (<"_1 l),<e)' is the inefficiency. To me, this is
> part of a larger problem with uncalled for eager evaluation in the
> interpreter, and I've spent quite a lot of time this week examining the
> jsources and seeing how generators could fit in with this. They would
> address our problem nicely, since they would be able to easily recognize
> (in a far more general way than SC's) and avoid all the cases where boxing
> only exists to modify verbs.
>
> J4
>
> ________________________________
> From: Chat <[email protected]> on behalf of Dabrowski,
> Andrew John <[email protected]>
> Sent: Friday, March 2, 2018 5:17:07 PM
> To: [email protected]
> Subject: Re: [Jchat] [Jprogramming] Insert initialising
>
> This seems to be one of those cases where J was ahead of its time at birth
> but has failed to keep up with industry standards. Mathematica has had
> Fold for over 20 years.
>
> On 03/02/2018 09:12 AM, Raul Miller wrote:
>
> I'm responding on the chat forum, since I'm not sure my thoughts are
> relevant enough for the programming forum:
>
> Reading over that fold proposal, I almost immediately want things to
> be different.
>
> Z: is complicated, the v argument is complicated and relates to Z:'s
> complications, we wind up with a lot of new primitives which work
> almost exactly like existing primitives but there's no visual cues for
> that.
>
> So, my thought experiment goes, let's try to discard some of that and
> see where it leads. Instead of building this up as a system
> independent of J, let's treat J as a specification language and this
> new mechanism as a modifier of those specifications.
>
> In other words, I think we can get away with just one adverb that gets
> the desired behaviors from an existing u/ u/\. u^: expressions.
>
> I am going to propose `. as that adverb. F. is just as viable, but
> having a different name makes it easier to distinguish between the
> proposals in when comparing and contrasting them.
>
> I am going to use U and V to represent verbs here, also, for much the
> same reason: to hopefully avoid some confusions. (I am basing my
> proposal on the original draft, so I want to start by focusing on what
> I propose to change.)
>
> ------------------------------
>
> I think we can discard the v argument to the F... conjunction. For
> example, V@u/`. would replace u F.:v
>
> I know that V@u/`. looks more complicated, but I think we don't really
> need v and u/`. is simpler than u F.:]
>
> Also, my hope here is that the visual similarities will pay off. u/1
> 2 3 works just like u/`.1 2 3 so I think it's good that they are
> visually similar.
>
> With v gone, the left arguments to Z: go away also - we retain the _1
> Z: meaning and get the effect of the 1 Z: meaning by having Z: as the
> final stage of our u verb. (We might even discard Z: itself - for
> example we could use ]:`. - but Z: is a suggestive name, so would keep
> it.) This lets us make Z: be an ambivalent verb. The monad terminates
> unconditionally (for use in @. structures) and the dyad takes a truth
> valued left argument to decide whether or not to terminate.
>
> The iterating folds seem to be motivated by the early termination
> behavior of ^:_ so let's have U^:_`. give us that (or, discard that
> sometimes unwanted feature), but let's revisit this in a moment...
>
> ------------------------------
>
> In other words:
>
> F.: gets replaced by /`.
> F:: gets replaced by /\.`.
>
> Basically, `. does not treat its left argument as a black box (the t.
> model), but instead treats it as a white box (more along the lines of
> some of the d. implementation).
>
> We don't have a left-to-right / adverb, which is a bit awkward, so I
> propose we repurpose another adverb for that, in the context of `.
> expressions. But let's take a step back for a moment:
>
> Keep in mind that `. expressions are symbolic, so if someone did U//`.
> we should expect the (U/) expression to still be a black box. It's
> only the outermost / whose execution properties we're replacing.
>
> With that in mind, I would propose we use ~`. for left-to-right folds.
> It's a different visual pun, but we do at least have the "reverse left
> and right" aspect of the original ~ adverb to help serve our
> instincts:
>
> F.. gets replaced by ~`.
> F:. gets replaced by ~\`.
>
> ------------------------------
>
> I think I've covered most of the possibilities, but I've sort of
> glossed over F. and F: and why they both exist and how to emulate
> them. And, to be honest, I don't really know why those were proposed
> as the most concise folds in the original proposal nor do I understand
> why they should both exist. Hypothetically, u~^:_`. and u^:_`. could
> serve, but there's nothing preventing F. and F: from being
> implemented. Following through on the reasoning which motivated
> proposal might make those be adverbs, but ... I really don't know so
> I'll stop here for now.
>
> 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
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
