Status report

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Status report

Mateusz Loskot
Administrator
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?

Best regards,
--
Mateusz  Łoskot, http://mateusz.loskot.net
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: Status report

Adam Wulkiewicz
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?
Which version of Boost do you have in mind?
Is this assessment based on real usage of the library or just on the
analysis of the results of the support_status program?

According to the docs the combinations of parameters with MultiPoint
wasn't supported in 1.56:
http://www.boost.org/doc/libs/1_56_0/libs/geometry/doc/html/geometry/reference/algorithms/disjoint.html

There is no supported geometries matrix in the docs for 1.55:
http://www.boost.org/doc/libs/1_55_0/libs/geometry/doc/html/geometry/reference/algorithms/disjoint.html
but I checked out this version and e.g. Point/MultiPoint nor
MultiPoint/Point doesn't compile.

The same with 1.54. I didn't check earlier versions.

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.

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

Regards,
Adam
_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry
Reply | Threaded
Open this post in threaded view
|

Re: Status report

Mateusz Loskot
Administrator
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?
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.

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,
--
Mateusz  Łoskot, http://mateusz.loskot.net
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: Status report

Menelaos Karavelas
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,

_______________________________________________
Geometry mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/geometry