Edit: I see you've updated your code susam.
Edit: I see you've updated your code susam.
Edit: I see you've updated your comment geocar.
Isn’t it funny how a python one liner required two edits to produce the correct result? (The summary description still matches the old incorrect code)
The summary description matches the current correct code. So it could not possibly match any incorrect code (if it really existed).
Incorrect. Here's the summary reproduced (in case susam edits again):
>>> There are 500 doors numbered 1, 2, ..., 500. All doors are closed initially. In iteration k, we toggle the states of doors k, 2k, ..., floor(500/k) * k where k runs from 1 to 500
Note the "floor(500/k)" statement. That matched the original code fragment (and what is still sitting in a terminal on my laptop):
>>> [k**2 for k in range(1, int(500**0.5))]
but not the new one which includes a +1. int(…) is floor. int(…)+1 isn't, and it's wrong: It works for 500, but not for other values. math.ceil would have been more correct, but it might've been more obvious that it doesn't match the "summary".> (if it really existed).
Let me make sure I understand what you mean here: You actually think it more likely that my two implementations, written in a comment [1] with a lower timestamp than [2], and the perl6 implementation on the linked article all include 484 as part of the valid result, and yet my comment [2] that calls on this value specifically, was somehow meant to indicate that 484 is not part of the valid result?
Ha.
[k**2 for k in range(1, ceil(484**0.5))]
does not return 484.I can't amend my comment to that point, but the original comment didn't have +1 in there anyway.