Skip to Content.
Sympa Menu

cgal-discuss - Re: [cgal-discuss] Conforming triangulaions and kernels

Subject: CGAL users discussion list

List archive

Re: [cgal-discuss] Conforming triangulaions and kernels


Chronological Thread 
  • From: Ben Supnik <>
  • To:
  • Subject: Re: [cgal-discuss] Conforming triangulaions and kernels
  • Date: Wed, 08 Apr 2009 12:19:57 -0400

Hi Y'all,

Thanks - it does look like the sqrt function is used only to construct splits, and I can probably survive with inexactness if my input isn't too horribly degenerate. :-)

One more question: what's the least bad way for me to collect all of the vertices inserted into my triangulation during the make-conforming operation?

I don't see any notifier interface, so it looks like my options would mostly involve overriding, er, something in the TDS to detect vertex creation.

cheers
ben


Fernando Cacciola wrote:
Hi Ben,
Hu Sylvain,

Sylvain Pion wrote:
Ben Supnik wrote:
The docs for make_conforming_Delaunay_2 say that it requires ConformingDelaunayTriangulationTraits_2. traits.

ConformingDelaunayTriangulationTraits_2 is labeled as having "Any model of Kernel concept. In particular, all CGAL kernels."

But...this doesn't seem correct to me - am I right in thinking that some CGAL exact pred exact construction kernels do not have sqrt? The one I was using did not, and I get a compile failure due to being unable to tkae the sqrt of a number.

If sqrt is indeed required and not in all kernels, is there a way to get an exact predicate/exact construction kernel without one of LEDA or GMP?

Known issue (to me at least).

One way to cheat is to define a sqrt() function for the number type
that you use, and make it approximate (convert to double, use std::sqrt,
and convert back). It might work for some/most rational number types,
and hopefully the algorithms won't break too much...


FWIW, the straight skeleton package uses such a cheat.

If you look at the header:

CGAL/constructions/Straight_skeleton_cons_ftC2.h

There is the function:

inexact_sqrt(num)

which does what Sylvain said.

You might wan't to base your version on that one.

It works for arbitrary number types, it uses CORE::BigFloat instead of double if available, and if it uses double, it checks for overflow after the to_double conversion, and for Quotient<NT> it avoids the division.


Best

Fernando Cacciola
www.geometryfactory.com


--
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://xplanescenery.blogspot.com/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
X-Plane Wiki: http://wiki.x-plane.com/
Scenery mailing list:

Developer mailing list:




Archive powered by MHonArc 2.6.16.

Top of Page