Hard disagree with this one.
Summing all numbers from 1 to 100 is easy, summing 1 to a million is also easy, just time consuming. 1+2+3+4....
Coming up with (n*(1+n))/2 is not.
Hard disagree with this one.
Summing all numbers from 1 to 100 is easy, summing 1 to a million is also easy, just time consuming. 1+2+3+4....
Coming up with (n*(1+n))/2 is not.
Also I think that the parent didn't mean "as quickly as possible" in the execution speed or algorithm sense, he meant in the clock time sense: getting it solved quickly and moving on.
So in their (and mine) formulation, the problem is easy by definition. It's not an "easy problem turned had because it has to be optimized for speed".
I thought that your objection was that finding a simple solution would be hard itself (which wouldn't be the case if the problem is easy as in "easy to solve").
[1] not that coming with a basic series summation formula is "hard" (except you're Gauss, and you're the first mathematician doing it, the rest just need to know how to search for it), but I'll accept it as hard for the sake of argument.
That’s exactly what the initial comment said:
> The "solve X as quickly as possible" is now the problem. Not just solve X. I And that sounds like a hard (therefore interesting) problem!
There were two separate points: 1) Finding a simple solution to a problem can be hard 2) Solving an ‘easy’ problem quickly enough can be hard