I see where you are going with this now. And, I do like the thinking. (I'd have to think a bit more, though, to come up with good examples, for documentation purposes.)
That said, this seems like it would be unnecessary in a good number of cases - only the "scan-like folds" really make good use of it, and then only when v is not an identity function. Perhaps, instead, if we can dip into symbolism a bit more, we could introduce a second conjunction that modifies folds at the "generate intermediate result" stage? [Does this description make sense?] Thanks, -- Raul On Sun, Mar 4, 2018 at 10:27 AM, Henry Rich <[email protected]> wrote: > I will try to make the case here for why v and u need to be separate. > > What I am talking about is saving space for intermediate values. > > Let's say I am working though a maze, a 10000x10000 array. My u verb > figures out a step and modifies the array slightly. Its output is > > (move;new array) > > When I run u/\. array, my result is a table where each row is (move;new > array). I have 10000 copies of the array. > > The result of u cannot be reduced, because each new iteration needs the > modified array. But those copies of the array aren't needed in the final > result. > > This is where v comes in. The result of u is fed into the next computation, > but only the result of v is appended to the growing result. v will normally > be a selection verb. > > Here, v is (0&{::) . The result of the fold will simply be a list of 10000 > moves. > > > I don't see any way to get this economy of space without two verbs. > > > Henry Rich > > > > > On 3/4/2018 5:14 AM, Raul Miller wrote: >> >> Doesn't u`v`:0 already give you this capability? >> >> Put different, I'm not yet convinced that V@(U/\.) -- where U=. u`v`:0 >> and V selects the result of u -- can be significantly more efficient >> than baking some special support for u and v into the fold >> implementation. >> >> Part of this might be that I've yet to see any worked examples of how >> things are supposed to function? >> >> Part of this might be that I'm over optimistic about the efficiencies >> we can expect from boxed data structures? >> >> But, also, the current description of the proposed F:: series of >> conjunctions makes it sound an awful lot like what's being proposed >> would offer behavior exactly like v@u/\. >> >> So maybe what I'm really groping for here is a clearer explanation of >> the proposal? (With some hints, here, about where I think this could >> lead...) >> >> Thanks, >> > > > --- > 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
