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

Subject: Re: [boost] [geometry] area, length, centroid, behavior
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-03-13 11:27:38

>> 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