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