Special Cases Are a Code Smell

The first e.g. is relevant to water simulation/CFD, where you estimate derivatives from neighbours. I kinda dislike the (popular) solution of padding, because performance is always an issue, and I don't like wasting memory (worse in a grid), even if maybe it doesn't really matter.

But in CFD, confirming your code is correct can be an issue... There's no formula to check your results against (notwithstanding MMS); flows can be too complicated to tell by eye if they are correct; and intrinsic discretization and round-off errors mean it can never actually be correct anyway. So anything to reduce silly coding errors has got to be a good thing!

These contradictory goals of correctness and performance can be accommodated with two versions: a correct one, to check a performant one.

aka make it right, then make it fast; optimization laws: (1) don't (2) not yet

But in general, I think: If it feels like a special case, make it look like a special case. If the next developer must first be educated about the whole problem, your theory of it, your solution and implementation, it's a Barrier of Abstraction. The last example in the article is very clever, perhaps... too clever. Debugging it might be tricky.

OTOH If your theory really is really good, pretty soon everyone will "feel" in terms of it, and the special case will disappear. e.g. relational algebra, structured programming, modules, objects, fp

\tangent an efficient approach to the 1st example is a running sum: to move right, add the entering cell, and subtract the exiting cell. (2 ops per cell instead of 3)