CGAL users discussion list

[Noel Warren <>]

Brilliant!  Changing line 1280 of Lazy_exact_nt.h from

{ return os << CGAL_NTS to_double(a); }

to

{ return os << a.exact(); }

worked for me.

Is this actually a bug or is there some package that depends of the output being a float?  If so, should I file a report or something?

Thanks for the help.  I love it when a plan comes together.

2012/11/19 Philipp Moeller <>

Noel Warren <> writes:

> That worked a charm.  Simple_cartesian does output the right values without
> loss.  Below is a Point_3(0, 0, 1.1)
>
> EPEC
> 3 { 9 11, 18 23, 6 7, -2 | 0 0 2.47698e+15 2.2518e+15 } 1
> Simple_cartesian
> 3 { 9 11, 18 23, 6 7, -2 | 0 0 2476979795053773 2251799813685248 } 1
>
> It does make my processing 50% slower though (50s to 74s).  This is fine to
> start off with but I shall want to improve this sooner or later.  It sounds
> like an easy fix.  I sifted through the code and was conviced the culprit
> was the gmpz << operator.  I guess I was wrong.
>
> Am I right in understanding that the problem lies in Lazy_exact_nt.h
> somewhere?  I might give it a shot if there is any chance you'll use the
> changes.

That sounds about right. You probably need to force all numbers to
exact before pushing them into the stream. It might be possible doing it by
hand (calling exact()), if possible.

> 2012/11/19 Sebastien Loriot (GeometryFactory) <>
>
>> On 11/19/2012 11:04 AM, Noel Warren wrote:
>>
>>> I am working with minkowski sums so EPEC kernel is my only option (I
>>> believe).
>>>
>> It should work fine (even if slower).
>>
>> Sebastien.
>>
>>   If you want me to run a "hello tetrahedron" example just to
>>> compare the two kernels let me know.  I have seen no evidence of EPEC
>>> using doubles as a default in its out stream.  It just seems that when
>>> the integers are too big it decides to convert them to double instead of
>>> printing all the characters representing the integer.
>>>
>>> I had to google IIRC.  I thought it was a kernel or number format of
>>> some sort :D
>>>
>>>
>>> 2012/11/19 Sebastien Loriot (GeometryFactory) <
>>> <mailto:>>
>>>
>>>     Hi Noel,
>>>

>>>     Could you try with CGAL::Simple_cartesian<CGAL::_**_Gmpq> ?

>>>
>>>
>>>     The stream operator with EPEC kernel is using to_double on the
>>>     coordinates IIRC.
>>>
>>>     Sebastien.
>>>
>>>
>>>     On 11/19/2012 09:50 AM, Noel Warren wrote:
>>>

>>>         I'm using the Exact_predicates_exact___**constructions kernel to

>>>
>>>         construct
>>>         my Nef polyhedra and I believe I've run into a bug.  The Nef
>>>         seems to
>>>         have no problem being stringified.  When I try to rebuild the
>>>         nef with
>>>         the string it will often fail.
>>>
>>>         I try a simple tetrahedron with points
>>>         (0,0,0)(1,0,0)(0,1,0)(0,0,1) and
>>>         everything works fine.  But if I change the last point to have a
>>>         value
>>>         of (0,0,1.1) it fails.  You might think that the problem has
>>>         something
>>>         to do with floats, but it doesn't.  1.5 works fine as does 0.75
>>>
>>>         As you probably know, the points are represented as a quotient
>>>         with both
>>>         the numerator and denominator being integers.  The problem seems
>>>         to be
>>>         that when these integers (gmpz) are being output with the <<
>>>         operator
>>>         they get abbreviated when too long (eg: 2.47698e+15).  This not
>>> only
>>>         leads to a loss in precision but means the file can not be read,
>>>         as gmpz
>>>         cannot parse the integer in that format.  Here is my failing
>>>         tetrahedron
>>>         example (see fourth point) ...
>>>
>>>         Selective Nef Complex
>>>         standard
>>>         vertices   4
>>>         halfedges  12
>>>         facets     8
>>>         volumes    2
>>>         shalfedges 24
>>>         shalfloops 0
>>>         sfaces     8
>>>         0 { 0 2, 0 5, 0 1, -2 | 0 0 0 1 } 1
>>>         1 { 3 5, 6 11, 2 3, -2 | 1 0 0 1 } 1
>>>         2 { 6 8, 12 17, 4 5, -2 | 0 1 0 1 } 1
>>>         3 { 9 11, 18 23, 6 7, -2 | 0 0 2.47698e+15 2.2518e+15 } 1
>>>         0 { 4, 0, 0 0 | 1 0 0 1 } 1
>>>         1 { 6, 0, 0 1 | 0 1 0 1 } 1
>>>         2 { 9, 0, 0 3 | 0 0 1 1 } 1
>>>         3 { 7, 1, 0 6 | -1 1 0 1 } 1
>>>         4 { 0, 1, 0 7 | -1 0 0 1 } 1
>>>         5 { 11, 1, 0 9 | -2.2518e+15 0 2.47698e+15 1 } 1
>>>         6 { 1, 2, 0 12 | 0 -1 0 1 } 1
>>>         7 { 3, 2, 0 13 | 1 -1 0 1 } 1
>>>         8 { 10, 2, 0 15 | 0 -2.2518e+15 2.47698e+15 1 } 1
>>>         9 { 2, 3, 0 18 | 0 0 -1 1 } 1
>>>         10 { 8, 3, 0 19 | 0 2.2518e+15 -2.47698e+15 1 } 1
>>>         11 { 5, 3, 0 21 | 2.2518e+15 0 -2.47698e+15 1 } 1
>>>         0 { 1, 4 , , 0 | 0 -1 0 0 } 1
>>>         1 { 0, 5 , , 1 | 0 1 0 0 } 1
>>>         2 { 3, 20 , , 0 | 2.47698e+15 2.47698e+15 2.2518e+15
>>>         -2.47698e+15 } 1
>>>         3 { 2, 21 , , 1 | -2.47698e+15 -2.47698e+15 -2.2518e+15
>>>         2.47698e+15 } 1
>>>         4 { 5, 2 , , 0 | -1 0 0 0 } 1
>>>         5 { 4, 3 , , 1 | 1 0 0 0 } 1
>>>         6 { 7, 0 , , 0 | 0 0 -1 0 } 1
>>>         7 { 6, 1 , , 1 | 0 0 1 0 } 1
>>>         0 { 0 } 0
>>>         1 { 1 } 1
>>>         0 { 1, 4, 2, 0, 1, 6, 12, 6 | 0 0 1 0 } 1
>>>         1 { 0, 3, 5, 1, 0, 13, 7, 7 | 0 0 -1 0 } 1
>>>         2 { 3, 0, 4, 1, 1, 16, 18, 4 | 1 0 0 0 } 1
>>>         3 { 2, 5, 1, 2, 0, 19, 17, 5 | -1 0 0 0 } 1
>>>         4 { 5, 2, 0, 2, 1, 22, 8, 0 | 0 1 0 0 } 1
>>>         5 { 4, 1, 3, 0, 0, 9, 23, 1 | 0 -1 0 0 } 1
>>>         6 { 7, 10, 8, 3, 3, 12, 0, 6 | 0 0 1 0 } 1
>>>         7 { 6, 9, 11, 4, 2, 1, 13, 7 | 0 0 -1 0 } 1
>>>         8 { 9, 6, 10, 4, 3, 4, 22, 0 | 0 1 0 0 } 1
>>>         9 { 8, 11, 7, 5, 2, 23, 5, 1 | 0 -1 0 0 } 1
>>>         10 { 11, 8, 6, 5, 3, 20, 14, 2 | -2.47698e+15 -2.47698e+15
>>>         -2.2518e+15 0 } 1
>>>         11 { 10, 7, 9, 3, 2, 15, 21, 3 | 2.47698e+15 2.47698e+15
>>>         2.2518e+15 0 } 1
>>>         12 { 13, 16, 14, 6, 5, 0, 6, 6 | 0 0 1 0 } 1
>>>         13 { 12, 15, 17, 7, 4, 7, 1, 7 | 0 0 -1 0 } 1
>>>         14 { 15, 12, 16, 7, 5, 10, 20, 2 | -2.47698e+15 -2.47698e+15
>>>         -2.2518e+15
>>>         0 } 1
>>>         15 { 14, 17, 13, 8, 4, 21, 11, 3 | 2.47698e+15 2.47698e+15
>>>         2.2518e+15 0 } 1
>>>         16 { 17, 14, 12, 8, 5, 18, 2, 4 | 1 0 0 0 } 1
>>>         17 { 16, 13, 15, 6, 4, 3, 19, 5 | -1 0 0 0 } 1
>>>         18 { 19, 22, 20, 9, 7, 2, 16, 4 | 1 0 0 0 } 1
>>>         19 { 18, 21, 23, 10, 6, 17, 3, 5 | -1 0 0 0 } 1
>>>         20 { 21, 18, 22, 10, 7, 14, 10, 2 | -2.47698e+15 -2.47698e+15
>>>         -2.2518e+15 0 } 1
>>>         21 { 20, 23, 19, 11, 6, 11, 15, 3 | 2.47698e+15 2.47698e+15
>>>         2.2518e+15 0 } 1
>>>         22 { 23, 20, 18, 11, 7, 8, 4, 0 | 0 1 0 0 } 1
>>>         23 { 22, 19, 21, 9, 6, 5, 9, 1 | 0 -1 0 0 } 1
>>>         0 { 0, 1 , , , 0 } 0
>>>         1 { 0, 0 , , , 1 } 1
>>>         2 { 1, 7 , , , 0 } 0
>>>         3 { 1, 6 , , , 1 } 1
>>>         4 { 2, 13 , , , 0 } 0
>>>         5 { 2, 12 , , , 1 } 1
>>>         6 { 3, 19 , , , 0 } 0
>>>         7 { 3, 18 , , , 1 } 1
>>>         /* end Selective Nef complex */

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to

https://sympa.inria.fr/sympa/info/cgal-discuss