Skip to Content.
Sympa Menu

cgal-discuss - Re: [cgal-discuss] Using Nef polyhedra with builtin 'double' number type

Subject: CGAL users discussion list

List archive

Re: [cgal-discuss] Using Nef polyhedra with builtin 'double' number type


Chronological Thread 
  • From: "Sebastien Loriot (GeometryFactory)" <>
  • To:
  • Subject: Re: [cgal-discuss] Using Nef polyhedra with builtin 'double' number type
  • Date: Wed, 16 Mar 2011 18:22:51 +0100

sander wrote:
Dear cgal!
I have an application where I need to compute the intersections of small
polyhedra, mainly tetrahedra and hexahedra. I have implemented a solution
using Polyhedron_3 and Nef_Polyhedron_3, and it works like a charm. The
problem is that I have to compute many such intersections (think hundreds of
thousands, these polyhedra are elements in finite element grids). Therefore, speed is important, and the price of exact number types is too
high. On the other hand, perfect precision is not needed, and therefore I
want to use the builtin 'double' type. I was hoping that if there is a
stability problem in a degenerate case that would throw an exception (is
that true). I would catch that and use an exact type then.

The problem is that the code doesn't compile with the kernel
CGAL::Cartesian. Nef_Polyhedron expects the number type to be a quotient. This appears to be a known issue, at least it is mentioned here:
http://cgal-discuss.949826.n4.nabble.com/Operator-Overloading-problem-for-Vector-in-Gmpzf-Kernel-td2548286.html
Therefore I don't submit a formal bug report (yet).

- is there a workaround? Some trick that I can do to get Nef_Polyhedra with
the speed of 'double'?
- Is this considered a bug that should be fixed?
- I am using cgal 3.6.1, the one in current Debian. Is it maybe even fixed
in later versions?

Thank you for your help
Oliver Sander
FU Berlin

--
View this message in context:
http://cgal-discuss.949826.n4.nabble.com/Using-Nef-polyhedra-with-builtin-double-number-type-tp3382392p3382392.html
Sent from the cgal-discuss mailing list archive at Nabble.com.

try with Simple_cartesian< Quotient< Interval_nt<true> > > and catch CGAL::Uncertain_conversion_exception.

Note that if at some point you have a non triangular face (even in the intersection) it will highly probably fail as coplanarity test are often
done.

see documentation of Interval_nt here:
http://www.cgal.org/Manual/latest/doc_html/cgal_manual/NumberTypeSupport_ref/Class_Interval_nt.html

S.



Archive powered by MHonArc 2.6.16.

Top of Page