[Gridflow-dev] feature requests: @fold1, @foldr, @foldr1, @scan1. @scanr, @scanr1, unary ignore

[ClaudiusMaximus]

Mathieu Bouchard wrote:
> On Tue, 7 Sep 2004, ClaudiusMaximus wrote:
> 
> 
>>@fold1 binop unop [ x y z ... w ] := @fold binop (unop(x)) [ y z ... w ]
>>@fold  op e [ x y z ... w ]  = ((...(((e op x) op y) op z) ... ) op w)
>>@foldr op e [ x y z ... w ] := (x op (y op (z op ( ... (w op e)...))))
>>similarly for the rest.  "1" require dimension 1 or greater , "r"
>>associates the other way.   @scan1 and @scanr1 reduce dimension by one.
>>[@for ( 0 0 ) ( 4 4 ) ( 1 1 )]
>>  |
>>[@fold1 == ignore]
>>would result in an identity matrix, this would also require "ignore" as
>>an unary operator.
> 
> 
> ok, but
> 
>   [@for ( 0 0 ) ( 4 4 ) ( 1 1 )]
>    |
>   [@fold -]
>    |
>   [@ == 0]
> 
> already results in an identity matrix, and when i know the size of the
> matrix i even do just
> 
>   "4 4 # 1 0 0 0 0"

That's a lot simpler - I always forget about the redim copying shortcut 
and type out the whole grid.

> 
> So I would enjoy another example for @fold1 because progress in GridFlow
> tend to be somewhat pragmatics-driven (even though there's also a lot of
> theory behind it)

The classic example that I couldn't think of at the time is [fold1 max] 
or [fold1 min], because different types of numbers have different ranges 
so the seed would have to depend on the type.

> Besides, I'm currently changing all the prefixes of @-objects so that they
> become #-objects (this is the first and last such change this decade, i
> promise). The ones starting with @ will stay for backwards compatibility.
> Incompatibilities are introduced in a nonintrusive fashion. For example,
> my plan is to make [#fold] have one inlet and one operand, while [@fold]
> stays as it is. The point is that the "seed" argument is almost never used
> so the syntax to specify it would look like:
> 
>   [#fold +, seed 42]   instead of   [@fold 42]
> 
> It appears like it only makes things longer, but actually I want to
> parallel that change in all classes that have some kind of seed in them,
> and overall, it simplifies things. Those other classes mainly are [#scan],
> [#inner] and [#convolve]. In the latter two cases, it makes things somehow
> less annoying.
> 
> I was also thinking that, in the latter two cases, since the operators
> being used are almost always * and +, they could also become
> "attributes" and so disappear from the arglist. The second most common
> operator combination for it, & and ^, is exceedingly rare, and all other
> operator combinations i've ever used with @convolve and @inner were
> hacks for accelerations that those objects don't know how to do themselves
> yet (e.g. >> and +). Example syntaxes for #convolve could be:
> 
>   [#convolve ( 3 3 # 0 1 0 1 -4 1 )]       <--- Laplacian
>   [#convolve ( 3 3 # 1 2 1 2 4 2 )]        <--- some blur
>   [#convolve ( 3 3 # 0 1 0 1 2 1 ), op <<] <--- same blur, faster
>   [#convolve ( 1 2 # 1 ), op &, fold ^]
> 
> I've thought about [#foldr] or alternately [#fold, reverse] but I again I
> wonder what you'd use it for. Something I want to add very soon is
> [#reverse], and then [#foldr -] becomes [#reverse]->[#fold inv+] and I was
> thinking about adding an attribute like [#fold -, swap] where "swap" would
> apply to any operator, making it work like f(y,x) instead of f(x,y), which
> would uniformize things (several noncommutative ops have their swapped op,
> but several also don't). What do you think?

I think the "seed", "swap", and "reverse" ideas are good, uniformity is 
a good thing and the conciseness for common usage would save typing overall.

> BTW Are you coming to PdConvention04 ?

Most likely not, but I am working on a patch for Puredata Trigger Gang 
Bang 1 - have you any tips for connecting Gem with Gridflow?  I'm 
experimenting with pix_snap, pix_dump and pix_set, but unsuccessful so 
far in the 45mins I've spent on that aspect.