Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk