CGAL users discussion list

[Philipp Moeller <>]

Noel Warren 
<>
 writes:

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

I'd consider this is a bug across CGAL. Your fix only works if the exact
type is streamable, but working that in and falling back to to_double is
possible.

But maybe I overlook some more general problem.

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

-- 
Philipp Moeller 
GeometryFactory