CGAL users discussion list

["Sebastien Loriot (GeometryFactory)" <>]

Two questions:

1) Is there a reason why you cannot use 
Exact_predicates_inexact_constructions_kernel?

2)We are really interested by a minimal example showing the problem.
Would be nice to have it (private message is fine).

S.


Marc Glisse wrote:
> On Wed, 25 May 2011, GIS Worx wrote:
>
> > Thanks for the thread on the other issue. I think I may try avoiding the
> > Lazy_kernel, to see how performance is affected.
>
> Note that when you disable the lazy kernel, IIRC, Epeck still uses a 
> lazy number type, which could make it even worse. If you don't want any 
> laziness, you could try something like: 
> Filtered_kernel<Simple_cartesian<Gmpq> >
>
> > Many thanks for the suggestions, with a nudge to the right stack reserve
> > size, it works.
> >
> > Using /F didn't produce results when set to an unreasonably low value. I
> > learned you have to actually modify the .exe for any /STACK option to 
> > work
> > (rather than my little CGAL related DLL). Using a VS2008 build 
> > environment,
> > a stack reserve size of 1750000B succeeds and 1500000B fails. The default
> > for the linker is 1MB.
>
> Less than 2MB, so it's not too wild.
>
> Sometimes, GMP can use quite a bit of stack space itself. I don't know 
> how you got your GMP, but replacing 65536 by something much smaller (say 
> 1024) in the definition of TMP_ALLOC in gmp-impl.h and recompiling can 
> help.
>
> > I know that the Lazy_kernel is supposed to be more efficient, but I 
> > wonder
> > if recursion this deep really be more efficient that simply outright
> > evaluating on the spot.
>
> Well the whole point is that in many cases you don't need the 
> evaluation, and the approximate value stored in each node is sufficient. 
> So in some sense, the deeper the DAG, the larger the potential gain.
>
> > I also wonder if there is something about my scenario that produces a 
> > particularly pathological case for the lazy evaluation.
>
> If you post a full reproducible example, maybe someday someone will look 
> into it.