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

[Mathieu Bouchard]

On Wed, 8 Sep 2004, ClaudiusMaximus wrote:

> > 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.

Ok. I myself thought about two solutions for this one:

2. A kind of #fold in which there is no seed because the first element
along the folding dimension would be used directly as such. This is like
fold1 except it doesn't involve a unary operator. I would like to have an
example of a situation where that unary operator is not just f(x)=x, aka
'ignore', because else the unary operator is useless.

3. For each binary operator, define a default neutral that may be
queried. Currently, there are functions to test whether a given value x 
is:

  left-neutral    : f(x,y)=y for all y
  right-neutral   : f(y,x)=y for all y
  left-absorbent  : f(x,y)=0 for all y
  right-absorbent : f(y,x)=0 for all y

Now there would be a way for #fold to find out, as a default value for
seed, a given left-neutral or right-neutral appropriate to the given
operator and the given number type.



So which of the three ideas (yours counting as number one) do you prefer?

Besides, I already removed support for unary operators in GridFlow 0.8.
They were a pretty much useless concept. First, only the [@!] object used
them, so having them separate from the [@!] object was a waste of energy,
whereas binary ops are used in at least 8 different classes and more to
come. Second, there were only 4 unaries and over 40 binaries. Third, [@!
abs] and [@! sq] usually came in combination just after a [@ -], so I
added [# abs-] and [# sq-]. So there were only two unaries left, so I
made them binaries in which the second argument is not used.

The new [@!] is written in Ruby and uses [#] to emulate the old [@!].

> 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.

Thanks for that confirmation.

> 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.

I don't know enough GEM to answer that, but chances are that it would be
something painful using very big [for] loops, unless you write a QuickTime
to a RAM disk and reread it immediately using the other plugin and then
erase it immediately and repeat. (!)

Several people are currently talking about creating an actual
[#export_pix]/[#import_pix] that would do this job, but no code has been
written yet.

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju