Barend Gehrels wrote:
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.
Doesn't it make more sense to make this a trait of the coordinate concept than adding it onto a specific geometry concept? You could then use the trait of the coordinate for all coordinate comparisions. I would expect there are cases where you need to compare two x values and don't care about the y and it would be awkward to construct points to use the traits of the point for this. Luke