Geometry Boost List: Re: [geometry] point on/intersects linestring?

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