Halve a long list

[cymplecy]

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

My 1st attempt

[silver_star]

You want to squish the image or crop it?

[cymplecy]

crop
.....

[kinestheticlearning]

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'.

[cymplecy]

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

[kinestheticlearning]

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

[cymplecy]

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

[bh]

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.

[cymplecy]

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

[dardoro]

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

Process.prototype.hyperDyadic
...
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.

[bh]

@dardoro

disguised as an abstraction

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.