I like it when the gloves come off Voile, so now I'll be blunt too. You make an unfounded assertion that I didn't understand the original idea (presumably because it makes you feel all big and superior), and then you write arse-gravy about working code being maintainable by virtue of the fact that it works, kind of imply that it's perfectly fine for developers to write code without any thought for other people who may have to read it, state explicitly that good algorithms must necessarily equate to good code, and you strongly implied that the best solutions must always be highly optimised ones.

As I have said from the very beginning, and to spell it out for the hard of understanding, I LIKE THE SOLUTION but I wanted to make a wider point about professional code.

You can stay in your myopic world, where the lines of code are all that matter. I prefer developers with a bit of balance, a wider view and an ability to make the right compromises. Oh and I definitely prefer developers that have at least a minimal grasp of how to interact with other humans, a skill you are desperately lacking.

Chrus, as I said, I picked a bad example to make a much more general point. However, I stand by the more general idea.

Beautiful

Hmmmmm, good algo != good code. Discuss.

And you should absolutely bash code that isn't clear just by reading it. Most of a developers time is spent reading and maintaining code and this aspect should always be foremost unless there is a compelling reason to have to make it more complex.

Absolutely. It's what I would call premature optimisation. In most circumstances the difference between the O(n) and the O(1) will be negligible in real world scenarios because humans can't tell the difference between a nano-second and a micro-second. Both are instant. So all that has been achieved is to obscure something simple behind some maths that most people will have forgotten, and to make all future developers lives maintaining this code harder than it should be. If it turns out that this bit of code is in a performance critical bit of the application then by all means optimise it to O(1) with relevant comments. But don't write code like that as a first attempt. And the problems solved by being able to quickly sum an arithmetic progression are a tiny fraction as compared to the problems that can be solved by consistently using a technology like Linq. So I'll ignore that.

Clever solutions are interesting, but code like this would not pass a code-review. The purpose is opaque, and code should tell you what it is doing by merely reading it. Plus code like this is a one-off. Knowing this solves a very small and specific subset of problems. Yet this problem, and many others on here, can be solved with very readable Linq expressions with the advantage that knowing Linq is applicable across many problem domains.