3 ms·

I just fixed a "should be || was &&" logic error that manifested itself fairly mysteriously in a one-dimensional partitioning data structure I had made(meant fo

by chipsy 17y ago

I just fixed a "should be || was &&" logic error that manifested itself fairly mysteriously in a one-dimensional partitioning data structure I had made(meant for indexing things like collision rectangles that have a "canonical value" and a "represented value" which need to be synchronized). When it removed elements, it was matching both the represented value(an integer) and the node(an object reference). Using && meant that it removed too greedily. Because updates always went "remove then add," this error went undetected until I hit the case where two or more objects shared an identical reprval. Then it removed all of the shared objects, leaving only one behind when I went to query the partition. After going through "Does my query function work right, does my list implementation work right, " I finally narrowed it down to the add/delete functions.

mleonhard 17y ago
That sounds like an error that would have been detected by a unit test.
- holygoat 17y ago
  Being a little snide... that sounds like a unit test that occurs to you after encountering that bug.
  - chipsy 17y ago
    It's a conceptual error with the problem, which means that it indeed WAS missed by unit tests. I wrote some of those and checked the "overlapping numbers" case; the difference was that I did so in a naive situation where the values were inserted once and never updated. Now, it would have gone from a "mysterious" error to an obvious one had I done an academic-style step-by-step visualization applet of the entire structure's processes before integration, but I had confidence when the code was first written that because this structure was being used with extremely high frequency, the only thing I had to write an explicit test for off the bat was off-by-one ranges causing edge-case "near misses"; anything else would make itself known at runtime after integration. Time it would have taken for a visualization applet: ~3-6 hours? Time it took to solve the bug: ~3 hours It's placing a bet - and the bet is that the bugs are limited to a specific segment of code that can be narrowed down easily; if the problem were architectural in nature I'd be in far deeper shit because that would make the same class of bug appear all over, with any number of different symptoms.

by chipsy 17y ago

mleonhard 17y ago

That sounds like an error that would have been detected by a unit test.

holygoat 17y ago
Being a little snide... that sounds like a unit test that occurs to you after encountering that bug.
- chipsy 17y ago
  It's a conceptual error with the problem, which means that it indeed WAS missed by unit tests. I wrote some of those and checked the "overlapping numbers" case; the difference was that I did so in a naive situation where the values were inserted once and never updated. Now, it would have gone from a "mysterious" error to an obvious one had I done an academic-style step-by-step visualization applet of the entire structure's processes before integration, but I had confidence when the code was first written that because this structure was being used with extremely high frequency, the only thing I had to write an explicit test for off the bat was off-by-one ranges causing edge-case "near misses"; anything else would make itself known at runtime after integration. Time it would have taken for a visualization applet: ~3-6 hours? Time it took to solve the bug: ~3 hours It's placing a bet - and the bet is that the bugs are limited to a specific segment of code that can be narrowed down easily; if the problem were architectural in nature I'd be in far deeper shit because that would make the same class of bug appear all over, with any number of different symptoms.