Geometry Boost List: Re: [geometry] Status report

Subject: Re: [geometry] Status report
From: Menelaos Karavelas (menelaos.karavelas_at_[hidden])
Date: 2014-11-03 17:27:31

Hi Mateusz,

On 03/11/2014 09:16 μμ, Mateusz Loskot wrote:
> Adam Wulkiewicz wrote
>> Mateusz Loskot wrote:
>>> Hi,
>>>
>>> Last year, I generated modified version of the support_status report:
>>> https://gist.github.com/mloskot/5821937
>>>
>>> I've just generated the new reports against the current master:
>>> https://gist.github.com/mloskot/993c38232c88675488e8
>>>
>>> Apart from the great progress, I noticed there seem to be a regression
>>> (?)
>>> regarding the disjoint algorithm.
>>>
>>> The disjoint support used to have 100% coverage, but now there are gaps
>>> for some of the combinations.
>>>
>>> How to interpret it?
>> Are you sure that disjoint had 100% coverage in the past?

There was no 100% coverage in the past (not even now, as there are still 
some combinations missing).
If I remember correctly the ones that are missing as the ones involving 
multipoints.
Some of them have been implemented in PR #127 
(https://github.com/boostorg/geometry/pull/129) but not merged yet.

> No, I'm not, hence my question.
>
>
> Adam Wulkiewicz wrote
>> Which version of Boost do you have in mind?
> The old report was generated in June 2013, so it is close to 1.54.
>
>
> Adam Wulkiewicz wrote
>> Is this assessment based on real usage of the library or just on the
>> analysis of the results of the support_status program?
> Just the support_status.
>
>
> Adam Wulkiewicz wrote
>> In the older versions (pre 1.56), instead of failing in the dispatched
>> algorithm as it should it failed in some other algorithm e.g.
>> for_each_xxx, sectionalize, etc. This is probably why it wasn't detected
>> by the support_status since it only checks if the dispatched algorithm
>> is derived from not_implemented<> and in the older versions (pre 1.56)
>> it wasn't. So now it fails to compile in a "right" way.
> It makes sense.

Please take a look at 
https://github.com/boostorg/geometry/blob/boost-1.54.0/include/boost/geometry/algorithms/disjoint.hpp, 
lines 185-195. This is the default dispatch for disjoint. Instead of 
deriving from not_implemented, it derives from general_areal, given the 
impression that all combinations are supported. So the status report was 
wrong.

All the best,

- m.

>
>
> Adam Wulkiewicz wrote
>> Though indeed this change could cause a regression. However we can't say
>> that after the analysis of the support_status results since it gave
>> invalid results for older versions of the library.
> Right. That's good to confirm the old support_status report can be
> disregard.
>
>
> Adam Wulkiewicz wrote
>> I only checked the Pt/Mpt combination. It's probable that for other
>> combinations those
>> internal algorithms failing e.g. for Pt/Mpt compiled before. So this
>> indeed would be a regression. Do you know about such case?
> No, I don't, not yet.
> I just did a quick support_status run (using my modified
> text_outputter.hpp).
>
> Anyway, good to have the support_status double-checked.
>
> Best regards,