Boost logo

Geometry :

Subject: Re: [geometry] point on/intersects linestring?
From: Barend Gehrels (barend_at_[hidden])
Date: 2013-09-04 11:22:31

Hi Adam,

On 4-9-2013 4:14, Adam Wulkiewicz wrote:
> Barend Gehrels wrote:
>>> Also is it defined in the C++ standard what should be the
>>> representation of floating point numbers? Are special values like
>>> INF always available? On some compilers it's possible to enable
>>> exception throwing for cases like division by 0 (I remember that
>>> e.g. Borland Builder had those). Not to mention that probably in the
>>> whole Boost.Geometry operations like division by 0 are avoided. So
>>> maybe it would be safer to add an if-check?
>> Yes, please, we indeed always do that...
> Ok, done. I've moved it from strategies to detail::disjoint, I hope
> it's ok. I added tests in intersects.cpp. Should I also add them for
> disjoint.cpp?

Thanks! Tests are only necessary if they add something, either at
compile-time or at run-time.

> However there is a little issue. std::numeric_limits<> isn't
> specialized for boost::rationale<> (there is already a ticket for
> this) so this algorithm won't work properly since min, max and epsilon
> are equal to 0. This probably isn't a problem because in other places
> of BG those values are also used so currently boost::rationale<>
> shouldn't work properly with BG in general.

Yes, boost::rationale<> works quite limited. Main reason is the high
probability of numerical overflow, numerator and denumerator grow quite

> Btw, shouldn't geometry::promote_floating_point<> always promote to
> raw floating point type? Currently boost::is_integral<T> trait is used
> to check if this type should be promoted. If this type is some class
> which means it's not intergal type, it isn't promoted to floating
> point type. Shouldn't the test be changed to !boost::is_float<T> ?

No, because GMP or ttmath or any other floating point high precision
number are not catched by that.

If there is any Integral high precision number, it is indeed a problem -
is_integral will probably return false... That can be helped by (did not
try) specializing that yourself. The library is as far as I know never
tested for non-standard integral types.

Of course we could do the same trick for floating point... (specialize
is_float for ttmath). Then indeed we could change the test.

Regards, Barend

Geometry list run by mateusz at