On Mon, Nov 16, 2009 at 11:16 AM, Stefan Strasser <strasser@uni-bremen.de> wrote:
I think the question of this review is not whether some algorithms in GGL have limitations, as long as they are documented, but if the concepts and algorithm/strategy interface is sufficient to allow the implementation of specialized algorithms. is this the case?
The concepts, interfaces, and algorithms provided by a library are indeed of paramount importance during a review. However, the implementation is also extremely important. Any serious algorithmic bugs identified in the implementation should probably be fixed prior to release (e.g. acceptance is contingent on fixing them). My argument is that numerical stability issues due to floating point limitations are not algorithmic bugs, but rather "properties" of the chosen algorithm(s). </flame_bait> I greatly like the ability to generically pick the representation of my choice, w/ the ability to use a more "robust" algorithm when needed. Any bugs that would prevent the more robust algorithm from being as robust as it claims should be fixed.
luke seems to be willing to integrate his Boost.Robust2DIntegerPolygon into GGL, but he also seems to have some concerns if he'll be able to do that using GGL's polygon representation. those should be addressed before GGL is accepted.
I was under the impression that Luc was basing his reservations on robustness issues due to floating point limitations. Perhaps I misread, or missed a point or two. Jon