Talk:Straddling checkerboard: Difference between revisions
→Bug: The bug is still a bug
(→Min/max: Leave it in, for portablility) |
(→Bug: The bug is still a bug) |
||
Line 57:
: You mentioned this again above, so I'm guessing you changed your mind about it being a bug? Anyway, I made it so that 3,7 and 7,3 gave identical results on purpose. You can achieve the same thing by rearranging the alphabet, and I thought it might make some other parts of the code a little simpler. (I'm not sure it actually did though.) [[User:MagiMaster|MagiMaster]] 18:15, 9 June 2011 (UTC)
::No, I have not changed my mind; I mentioned it again as the rationale for my recommendation for a change to the task.
::The only reason you are getting away with `exchange(u,v) when u>v` is because you are using the same program to encode and decode. If one program changes (7,3) into (3,7) and encodes, and then a correct program (that does not exchange()) tries to decode using (7,3), FAIL.
::Also, since you are building the first[] row in a straight loop, skipping the gaps with "(i != u && i != v)", you should not need to reorder (u,v) at all! [ Which also makes moot the whole `#include algorithm` issue :) ] Using the current C++ code, when I change "rowU = min(u, v); rowV = max(u, v);" to "rowU = u; rowV = v;", the program works correctly for (3,7) and (7,3). --[[User:Util|Util]] 16:52, 11 June 2011 (UTC)
| |||