Re: [boost] [geometry] area, length, centroid, behavior

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-03-13 13:03:35

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