
Geometry : 
Subject: Re: [geometry] point on/intersects linestring?
From: Barend Gehrels (barend_at_[hidden])
Date: 20130904 11:22:31
Hi Adam,
On 492013 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 ifcheck?
>>
>> 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
compiletime or at runtime.
>
> 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
large.
>
> 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 nonstandard 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 loskot.net