Spreads: getting the highest value of a spread

hum… sure that is a newbie one ( damned i m burning the vvvvorum today!)

i would like to try atractor with a trautner grid of 100.
how to get the highest value of this spread of 100 and its index ?
this to determine via movement place of attractor in the frame.

Try The BOUNDS node to get all that info from a spread.

But a quicker way in this case is the SORT node and 2 CDR nodes.

Highest.v4p (6.3 kB)

To get the highest value of a spread, Bounds (Spectral) is your friend.

To retrieve the indice of this use Sift (Value), with the spread as input, and the maximum output from Bounds connected to Sift “Filter” input, then you will have the slice index.

That’s it :)

Hehe, that is 2 nodes, think VUX won this round…

Thnx for mentioning the Sift node :)

bounds is a friend, and west and vux are our vvvvery friends
;-) an happy karistouf !

instead of sifting (precious performance!) you could also just Sort (Spreads) your spread, CDR (Spreads) the ‘original slice’ output and GetSlice (Spreads) it directly.

edit: ai, my keys are too loose again! west said that already! ;)

instead of Sift one can use = and Select after the Bounds, it also outputs the former index, should be faster…

Now I tested all 3 off them, on a 1000 slices randomspread, and the Debug mode gave the following (for me shocking) result.

Sort + CDR + CDR = 0.7 (what ever the unit is for debug)
Bounds + = + Select = 4.5
Bounds + Sift = 1.7

The ‘=’ Node is taking most performance!! Than the ‘Bounds’, and than the ‘Sift’, meaning Sort and CDR combo are best for performance.

I am kind off surprised by this…

have you chaged the values every frame? (e.g. framecounter at the random seed). and it depends on the spreadcount which is the fastest, i would say…

I attached the patch with 3 ways.

My observation in Debug mode:

A static value: sort&CDR is best.
Changing Value: Bounds&Sift is best.

Highest3ways.v4p (10.9 kB)

thx for the patch. indeed, sift is quite fast…

well, thanks for all this replys, guys !

this is vvvvery interresting and surprising also.

about the ‘=’ function, i dont know anything in delphi, but devvvs would perhaps reply that there is an ‘if’ condition in its code and that is not on ‘case’ dependaing, am i right ?

I figured it had to do with the internal resampling off the = (value) Node, like the Inputmorph, but feeding it an equal sicecount for all pins doesn’t seem to help.

Weird that such a basic node has a bit slow performance.