Code Clarification: Use of < and etc from Intro to PB Code

Patterns and Code
1

Lines 42 - 49 in the Intro to Pixelblaze Code pattern read as follows -

export function render(index) {
red = green = blue = 0
leadPosition = time(0.08) * pixelCount
red = abs(leadPosition - index - 0) < 1
green = abs(leadPosition - index - 4) < 1
blue = abs(leadPosition - index - 8) < 1
rgb(red, green, blue)
}

I get the general drift, and its cool, but I am still puzzled be the following -

  1. The code above lights two pixels for each color… not sure how the code this works (lighting two each as written) unless things go both negative and positive (?), hence or from the “abs”.
  2. The < sign controls/limits the number of pixels lit for each color, but how?
  3. I’d think we would need a “floor” command somewhere…why don’t we need a “floor” command?

It would be great if greater minds helped elucidate these mysteries for me.

Thanks!

2

Hi Gandalf! I wrote this so I should help explain :slight_smile:

A monospaced diagram may help. Let’s examine red, at some point in the animation where leadPosition (time() * pixelCount) happens to equal 1.3:

LED's index             0         1         2         3
leadPosition                        1.3
abs(lP-index)          1.3  1    .3  0     .7  1         2
above is < 1?           nnnnnYYYYYYYYYYYYYYYYYYnnnnnnnnnnn
This LED is on?         No        Yes       Yes       No

So, to answer:

  1. Yes, leadPosition - index will be both negative and positive. The absolute value abs() of it will be v-shaped, and always positive.
  2. The “<1” says we want to define a region of this v-shape that’s about 1.99999 wide - enough to cover 2 pixels almost all the time
  3. You could rewrite it with floor for sure if you wanted to and found that more clear.

Hope this helps!

3

Yup, that was key! Still getting used to waveforms as timers…
Just idly wondering if this is a computationally-costly way to move pixels around.
I’d leave the floor out because… as y’all say, “golfing”!
Thanks!