"The Stencil operator: ⌺" revision

[rodrigogiraoserrao]

Revision

Here I include all of the things that, to the best of my knowledge and experience, should be changed/corrected.

• "but instead of moving it one step (the default) we want to shift it three steps each time:" → "but instead of moving it one step (the default), we want to shift it three steps each time:"

To consider

In here I include things that, from my point of view, would be nice additions/modifications. Tick them as you ponder on them, feel free to disregard.

• You write "2D" in here, but "2-D" in other places; consider sticking to a single one?
• "But now look what happens if we increase the window size to 3, which does not divide cleanly the operand array:" I don't understand the sentence, especially the phrase "does not divide cleanly the operand array".

You could very well only have runs of length 3 with elements from the vector:

      3 ,/ ⍳10
┌─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┐
│0 1 2│1 2 3│2 3 4│3 4 5│4 5 6│5 6 7│6 7 8│7 8 9│
└─────┴─────┴─────┴─────┴─────┴─────┴─────┴─────┘

What's happening here is that stencil goes farther than just the argument. Stencil goes up to the point where the original array ends at the centre of the window, regardless of that window size dividing the original vector length or not.
For example, with windows of size 7, the final window will be 6 7 8 9 0 0 0:

      ⊂⍤⊢⌺7⊢⍳10
┌─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐
│0 0 0 0 1 2 3│0 0 0 1 2 3 4│0 0 1 2 3 4 5│0 1 2 3 4 5 6│1 2 3 4 5 6 7│2 3 4 5 6 7 8│3 4 5 6 7 8 9│4 5 6 7 8 9 0│5 6 7 8 9 0 0│6 7 8 9 0 0 0│
└─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘

For even lengths, stencil goes up until the element to the right of the centre, and that's why there's no padding on windows of size 2.

• "The way to think of it is that given an odd-size window, each data point in the argument array must line up with the centre of the window. With even-sized windows, we have no choice, as we can’t have fractional indexing." this makes it a bit clearer what you meant above, maybe..? But IMO you could make it clearer that there will be padding always, not just for odd numbers, or something like that.
• "With an even size we can create non-overlapping windows that don’t “overhang”:" → here's an even-sized window with overhang

      ⊂⍤⊢⌺(⍪4 4)⊢⍳10
┌───────┬───────┬───────┐
│0 0 1 2│3 4 5 6│7 8 9 0│
└───────┴───────┴───────┘

[xpqz]

Fixed in b35e668 (deployed)