[Gridflow-dev] feature requests: @fold1, @foldr, @foldr1, @scan1.
@scanr, @scanr1, unary ignore
matju at sympatico.ca
Wed Sep 8 22:43:46 EDT 2004
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
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
Mathieu Bouchard http://artengine.ca/matju
More information about the Gridflow-dev