I find it interesting how a KEEP ITEMS block can be used to show dynamic (ie. changing with time) (sub-)subsets of another sprite's clones.
Here in a remixed 'Water simulation project' (orig by fridolinux) it can be seen how implicit parameters being fed into a TOUCHING <...> block can create a subset of clones (let's call it 'semi-product', not in a mathematical sense) that the shape sprite is touching, and - additionally - implicit parameters being fed into an ASK <...> FOR block can create a sub-subset (let's call it 'final product', again not in a mathematical sense), based on an additional criterion, i.e. having been 'bounced' from obstacles, using a sprite-local variable's value by the Water clone.
I know that niceness is one of your qualities and that you seem to value this quality very high, and - don't get me wrong - I do appreciate it.
Still, however, even if you really find it nice to look at, this doesn't necessarily mean that you also find it interesting.
What do I mean by that?
I mean what I find interesting about it it's that it is a kind of a Venn diagram, not a static kind of it (that we learned at math in school), but both a dynamic & still a Venn diagram, showing a set and it's (dynamic, i.e. changing with time) sub-set.
I do get what you mean. I think everything is interesting....even life alone....it has so many wonders...so many mysteries....oh jeez, I feel like I am starting to get off-topic. I tend to do that a lot.
Yeah, but if I did that, I would not be able to know a) how many clones meet the first criterion, and b) how many meet the second criterion. And I needed to know a) and b) in order to calculate and SAY the percentage at any moment.
They say that in order for something to be interesting, it has to fall on a sweet-spot between too-regular (too-simple/too-ordered), on one hand, and too-complex (too-chaotic/too-'noisy'), on the other hand.
Yes! That's precisely the idea behind pipe! It relieves you from having to use variables to store intermediate results. I used it in my example so I could use and intermediate result (the filtered list of solid pixels) twice in the following step: To add them all up and to divide the result by the length (of the filtered list).
Your English is at the native-speaker level and I've just learned from you that 'solid color pixels' means 'non-transparent' (ok, more precisely, as I can understand from the code, having opacity greater than zero) pixels?
And I should be saying 'intermediate results' instead of 'semi-product', I guess.
Since when does PIPE block exist, I'm asking because I can't remember seeing it, or was I blind?
Thanks! I might be wrong about "solid", because - as you correctly point out - I'm not checking for full solidity but only excluding fully transparent pixels
The pipe block is a user-defined block in the "Frequency Distribution Analysis" library. It's one my favorite examples for a custom control structure (look at its definition! Isn't it just the most beautiful thing?), and I'm finding it incredibly useful, but so far have resisted the urge to add it to the list of always-present primitives.
As a native speaker of American, I would use "solid" only for fully opaque pixels.
@kinestheticlearning, the situation in which you'd still need an intermediate result in a variable would be if you want to use that result more than once without recomputing it each time. PIPE doesn't solve that problem.
I guess in the whole world there's no natural language that would have in its vocabulary a word for 'NOT(100% transparent), yet. They say that some Inuit (Eskimo) languages have special words for all the different types of snow (because their survival depended on it). Different types of transparency probably aren't that important for languages to invent a special words for them.