Inconsistent output for Min_sphere_d

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

Inconsistent output for Min_sphere_d

Grimm, Raphael (IAR)
Hi,
i was playing around with Min_sphere_d and encountered some behavior i
do not understand (see attached files).

In both cases my code creates a Min_sphere_d using
Min_sphere_annulus_d_traits_3 and Epick and then it inserts three points
and prints the radius.

In the first case i used doubles to initialize the Point_3 and the
output is correct.
In the second case i used floats to initialize the Point_3 and the
output is nan.

The only difference is the type of the values used to initialize the
Point_3.
This means the error has to be caused by the differences in accuracy,
but this should not really create a difference.

Has anyone any idea why this happens and how i can prevent this problem?
Since the data i am using is represented as floats, I can't really
switch everything to double.

I appreciate any help.

Best regards,

Raphael


PS.: I am on master (54f2a119f9598f884f98df9ee1fa63aa07451c4c).



--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss



code.cpp (2K) Download Attachment
output (662 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent output for Min_sphere_d

Hoffmann  Michael
See the quote from the docs below. Did you try sphere_of_spheres? Or Epeck?

Best, Michael

Please note: This class is (almost) obsolete. The class CGAL::Min_sphere_of_spheres_d<Traits> solves a more general problem and is faster then Min_sphere_deven if used only for points as input. Most importantly, CGAL::Min_sphere_of_spheres_d<Traits> has a specialized implementation for floating-point arithmetic which ensures correct results in a large number of cases (including highly degenerate ones). In contrast, Min_sphere_d is not reliable under floating-point computations. The only advantage of Min_sphere_d over CGAL::Min_sphere_of_spheres_d<Traits> is that the former can deal with points in homogeneous coordinates, in which case the algorithm is division-free. Thus, Min_sphere_d might still be an option in case your input number type cannot (efficiently) divide.

On 19 Aug 2020, at 18:52, Raphael Grimm <[hidden email]> wrote:

Hi,
i was playing around with Min_sphere_d and encountered some behavior i do not understand (see attached files).

In both cases my code creates a Min_sphere_d using Min_sphere_annulus_d_traits_3 and Epick and then it inserts three points and prints the radius.

In the first case i used doubles to initialize the Point_3 and the output is correct.
In the second case i used floats to initialize the Point_3 and the output is nan.

The only difference is the type of the values used to initialize the Point_3.
This means the error has to be caused by the differences in accuracy, but this should not really create a difference.

Has anyone any idea why this happens and how i can prevent this problem?
Since the data i am using is represented as floats, I can't really switch everything to double.

I appreciate any help.

Best regards,

Raphael


PS.: I am on master (54f2a119f9598f884f98df9ee1fa63aa07451c4c).



--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


<code.cpp>
<output>

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent output for Min_sphere_d

Grimm, Raphael (IAR)

Thanks for the help! Using Min_sphere_of_spheres_d fixed this for me. I only skimmed the documentation and did not see the note.

It would be nice if deprecated functions would be decorated with [[deprecated]] (c++14 feature). if macros are used, this can be done conditionally depending on the c++ standard.

On 19.08.20 19:50, Hoffmann Michael wrote:
See the quote from the docs below. Did you try sphere_of_spheres? Or Epeck?

Best, Michael

Please note: This class is (almost) obsolete. The class CGAL::Min_sphere_of_spheres_d<Traits> solves a more general problem and is faster then Min_sphere_deven if used only for points as input. Most importantly, CGAL::Min_sphere_of_spheres_d<Traits> has a specialized implementation for floating-point arithmetic which ensures correct results in a large number of cases (including highly degenerate ones). In contrast, Min_sphere_d is not reliable under floating-point computations. The only advantage of Min_sphere_d over CGAL::Min_sphere_of_spheres_d<Traits> is that the former can deal with points in homogeneous coordinates, in which case the algorithm is division-free. Thus, Min_sphere_d might still be an option in case your input number type cannot (efficiently) divide.

On 19 Aug 2020, at 18:52, Raphael Grimm [hidden email] wrote:

Hi,
i was playing around with Min_sphere_d and encountered some behavior i do not understand (see attached files).

In both cases my code creates a Min_sphere_d using Min_sphere_annulus_d_traits_3 and Epick and then it inserts three points and prints the radius.

In the first case i used doubles to initialize the Point_3 and the output is correct.
In the second case i used floats to initialize the Point_3 and the output is nan.

The only difference is the type of the values used to initialize the Point_3.
This means the error has to be caused by the differences in accuracy, but this should not really create a difference.

Has anyone any idea why this happens and how i can prevent this problem?
Since the data i am using is represented as floats, I can't really switch everything to double.

I appreciate any help.

Best regards,

Raphael


PS.: I am on master (54f2a119f9598f884f98df9ee1fa63aa07451c4c).



--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


<code.cpp>
<output>

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss

Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent output for Min_sphere_d

Hoffmann  Michael
It is not really deprecated in the sense that we plan to remove it eventually, for the reasons given there.

Best, Michael

> On 20 Aug 2020, at 09:04, Raphael Grimm <[hidden email]> wrote:
>
> Thanks for the help! Using Min_sphere_of_spheres_d fixed this for me. I only skimmed the documentation and did not see the note.
>
> It would be nice if deprecated functions would be decorated with [[deprecated]] (c++14 feature). if macros are used, this can be done conditionally depending on the c++ standard.
>
> On 19.08.20 19:50, Hoffmann Michael wrote:
>> See the quote from the docs below. Did you try sphere_of_spheres? Or Epeck?
>>
>> Best, Michael
>>
>> Please note: This class is (almost) obsolete. The class CGAL::Min_sphere_of_spheres_d<Traits> solves a more general problem and is faster then Min_sphere_deven if used only for points as input. Most importantly, CGAL::Min_sphere_of_spheres_d<Traits> has a specialized implementation for floating-point arithmetic which ensures correct results in a large number of cases (including highly degenerate ones). In contrast, Min_sphere_d is not reliable under floating-point computations. The only advantage of Min_sphere_d over CGAL::Min_sphere_of_spheres_d<Traits> is that the former can deal with points in homogeneous coordinates, in which case the algorithm is division-free. Thus, Min_sphere_d might still be an option in case your input number type cannot (efficiently) divide.
>>
>>> On 19 Aug 2020, at 18:52, Raphael Grimm <[hidden email]> wrote:
>>>
>>> Hi,
>>> i was playing around with Min_sphere_d and encountered some behavior i do not understand (see attached files).
>>>
>>> In both cases my code creates a Min_sphere_d using Min_sphere_annulus_d_traits_3 and Epick and then it inserts three points and prints the radius.
>>>
>>> In the first case i used doubles to initialize the Point_3 and the output is correct.
>>> In the second case i used floats to initialize the Point_3 and the output is nan.
>>>
>>> The only difference is the type of the values used to initialize the Point_3.
>>> This means the error has to be caused by the differences in accuracy, but this should not really create a difference.
>>>
>>> Has anyone any idea why this happens and how i can prevent this problem?
>>> Since the data i am using is represented as floats, I can't really switch everything to double.
>>>
>>> I appreciate any help.
>>>
>>> Best regards,
>>>
>>> Raphael
>>>
>>>
>>> PS.: I am on master (54f2a119f9598f884f98df9ee1fa63aa07451c4c).
>>>
>>>
>>>
>>> --
>>> You are currently subscribed to cgal-discuss.
>>> To unsubscribe or access the archives, go to
>>> https://sympa.inria.fr/sympa/info/cgal-discuss
>>>
>>>
>>> <code.cpp>
>>> <output>
>>
>> --
>> You are currently subscribed to cgal-discuss.
>> To unsubscribe or access the archives, go to
>> https://sympa.inria.fr/sympa/info/cgal-discuss
>>


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


Reply | Threaded
Open this post in threaded view
|

Re: Inconsistent output for Min_sphere_d

andreas.fabri

As a follow up I started this WIP pull request. https://github.com/CGAL/cgal/pull/4941

Best,

Andreas

On 8/20/2020 11:22 AM, Hoffmann Michael wrote:
It is not really deprecated in the sense that we plan to remove it eventually, for the reasons given there.

Best, Michael

On 20 Aug 2020, at 09:04, Raphael Grimm [hidden email] wrote:

Thanks for the help! Using Min_sphere_of_spheres_d fixed this for me. I only skimmed the documentation and did not see the note.

It would be nice if deprecated functions would be decorated with [[deprecated]] (c++14 feature). if macros are used, this can be done conditionally depending on the c++ standard.

On 19.08.20 19:50, Hoffmann Michael wrote:
See the quote from the docs below. Did you try sphere_of_spheres? Or Epeck?

Best, Michael

Please note: This class is (almost) obsolete. The class CGAL::Min_sphere_of_spheres_d<Traits> solves a more general problem and is faster then Min_sphere_deven if used only for points as input. Most importantly, CGAL::Min_sphere_of_spheres_d<Traits> has a specialized implementation for floating-point arithmetic which ensures correct results in a large number of cases (including highly degenerate ones). In contrast, Min_sphere_d is not reliable under floating-point computations. The only advantage of Min_sphere_d over CGAL::Min_sphere_of_spheres_d<Traits> is that the former can deal with points in homogeneous coordinates, in which case the algorithm is division-free. Thus, Min_sphere_d might still be an option in case your input number type cannot (efficiently) divide.

On 19 Aug 2020, at 18:52, Raphael Grimm [hidden email] wrote:

Hi,
i was playing around with Min_sphere_d and encountered some behavior i do not understand (see attached files).

In both cases my code creates a Min_sphere_d using Min_sphere_annulus_d_traits_3 and Epick and then it inserts three points and prints the radius.

In the first case i used doubles to initialize the Point_3 and the output is correct.
In the second case i used floats to initialize the Point_3 and the output is nan.

The only difference is the type of the values used to initialize the Point_3.
This means the error has to be caused by the differences in accuracy, but this should not really create a difference.

Has anyone any idea why this happens and how i can prevent this problem?
Since the data i am using is represented as floats, I can't really switch everything to double.

I appreciate any help.

Best regards,

Raphael


PS.: I am on master (54f2a119f9598f884f98df9ee1fa63aa07451c4c).



-- 
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


<code.cpp>
<output>
-- 
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


-- 
Andreas Fabri, PhD
Chief Officer, GeometryFactory
Editor, The CGAL Project

phone: +33.492.954.912    skype: andreas.fabri

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss