CGAL users discussion list

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