Halve a long list

I've a 11700 long array of pixels - what's a nice Snap! way of halving it's length?

My 1st attempt


You want to squish the image or crop it?


I wonder how much faster the 'keep items', that you used, is compared to - I think that the following one is slower - hyperized 'ITEM (numbers from {1} to {length_of_the_list / 2} ) of the_list'.

That's a much Snappier way of doing it. :slight_smile:
I knew I was over overcomplicating it :slight_smile:

Well, to me it is your approach which seems Snappier, not mine. And isn't yours faster than mine? Have you tested both?

Not tested either for speed. I'm just needing it for a one off task to crop a hexagon to make a trapezoid shape

The disagreement about what's "Snappier" is amusing. It's really a question of Snap! Classic vs. New Snap!; HOFs have been around since day one (although not with the value/index/list feature), whereas hyperblocks are new and shiny. My impression is that a hyperblock approach is faster when it works at all, but that HOFs are more general. In this case, the hyperblock approach does the not-strictly-necessary step of making a list of index numbers, but that's really fast (≈33ms on my computer for numbers from 1 to 1,000,000) and it avoids all those < comparisons.

As I learned from Jens just this week, every time you call a ringed function, Snap! makes a deep copy of it, so it's faster if you make a named custom block and call that from the HOF. This change speeds up the Colors and Crayons library by a factor of five or so. (The custom block is still in a ring in the HOF call, but if I'm understanding Jens correctly, a "deep" copy of a single block is much faster than, in your KEEP example, copying a four-deep (<, /, LENGTH, variable) expression. Snap! doesn't have to copy the body of a named custom block.)

TL;DR: What's faster than what is complicated and depends on the details, but hyperblocks often win in situations in which they work at all.

Just for fun - timed both approaches and the item of runs in 2ms and keep takes 70ms

Brian, hyperblocks are just tight JS loops disguised as an abstraction

for (i = 0; i < len; i += 1) {
result[i] = this.hyperDyadic(baseOp, a[i], b[i]);

While HOF's are doing the whole evaluation cycles - pushing contexts, poping element, evaluating blocks for every list item.

untitled script pic (94)

untitled script pic (93)

This gave me a chuckle. What would it mean to be a real abstraction, in your vocabulary? Aren't all abstractions disguises for some concrete operation?

But yeah, as I said, if it works at all, the hyperblock approach is likely to be faster. The pitfall I trip over most often is that custom blocks containing only hyperizable primitives are hyperizable, but ones that contain IF blocks aren't.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.