Steve M. Robbins wrote:
Can the proposed Boost libraries support this kind of exact Predicates with approximate Constructions paradigm?
OK. But I'm assuming that I can define my own point class and use my favourite number type for the coordinate values. (I admit that I haven't been looking closely at the current proposed library code, so that may be a mistaken assumption.) If I use doubles for the coordinate values, then the slope comparison trick needs more precision.
Basically, the intersection test is a degree 2 predicate so it needs about double the precision of the input (coordinate) data types. So each predicate needs to be templated over the coordinate number type. Or something similar. How is this achieved in the proposed libraries Currently we concentrated on concepts and the core of the library, and still have the original (naive) approach to floating point comparisons. However we had discussed internally to enhance this by providing a
traits-based solution. Users often need to define there own tolerance, especially when it comes to use an algorithm such as intersection or neighbourhood detection. Others want only performance. So we will let them define the way in which they want comparisons to be made (strict or tolerant) via the geometry traits already in place. The Point Concept will have a traits class e.g. "comparison". This will be an enhanced version of the "equals" function used now. However, library users can implement another comparison class, and attach this via traits to their point type. Which will be used by floating point equality evaluation. This way we handle the defaults correctly, we enable matching of points which are more distant and still to be considered as equal, and enable configurable floating point (comparison) models. If other things then equality will be checked, those cases would be handled in the same way. So, in summary, it will be part of the concept, configurable. How FP equality then implemented is to be defined, it would be useful if it is somewhere within Boost because its scope is broader then geometry alone. Regards, Barend