Tektosyne 6.3.1 is now available for download. This minor update addresses one small bug discovered by an observant user: an assertion in method
MultiLineIntersection.split was triggered when a collection of split points had a size smaller than three instead of the correct two. The interesting aspect here is how I managed to miss this bug all these years, despite always testing with assertions enabled.
Essentially, what I thought I was testing was different from what I was actually testing. First about that collection size. The minimum size of a non-null set of split points on a line is two: the start and end point of the line, i.e. the “split” line is simply the original line. More than two points occur when there are additional intermediate intersections where the line is split into multiple lines.
I have two ways of testing the multi-line intersection algorithm: with sets of random lines (both in unit tests and in an interactive demo dialog) and with sets of explicitly defined lines (only in unit tests). The intersection splitting algorithm, however, was only tested through the demo dialog. I had forgotten to call it in my unit tests.
The trick is that random lines – if they intersect at all – virtually always have some intermediate intersection point, so the number of split points is always greater than two and the incorrect assertion was never triggered. When I added a
split call to the unit tests with explicitly defined lines that deliberately only intersect at their start and end points, the assertion was triggered immediately.
In summary, I had thought the randomized test in the demo dialog to be comprehensive, but it turned out to virtually eliminate the important case of lines only intersecting with their start and/or end points, thus obscuring a very old bug in the code.