Skip to Content.
Sympa Menu

cgal-discuss - Re: [cgal-discuss] Possible bug (Nef_polyhedron_3 stream)

Subject: CGAL users discussion list

List archive

Re: [cgal-discuss] Possible bug (Nef_polyhedron_3 stream)


Chronological Thread 
  • From: Andreas Fabri <>
  • To:
  • Subject: Re: [cgal-discuss] Possible bug (Nef_polyhedron_3 stream)
  • Date: Mon, 19 Nov 2012 16:44:03 +0100
  • Organization: GeometryFactory

Your solution is not really one, as the whole
point of the lazy constructions is not to make
them exactly, but only symbolically.
When you call exact(), you trigger to redo the
construction with an exact number type.

The real solution is to do a topology preserving
snap rounding for a user specified tolerance.

andreas


On 19/11/2012 16:24, Philipp Moeller wrote:
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






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

phone: +33.492.954.912 skype: andreas.fabri

Archive powered by MHonArc 2.6.18.

Top of Page