CGAL users discussion list

[GIS Worx <>]

Thanks for the thread on the other issue. I think I may try avoiding the Lazy_kernel, to see how performance is affected.

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.

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. I also wonder if there is something about my scenario that produces a particularly pathological case for the lazy evaluation.

On Wed, May 25, 2011 at 1:22 PM, Marc Glisse <> wrote:

On Wed, 25 May 2011, GIS Worx wrote:

Increasing the stack size to 20MB from 1MB does not resolve the issue.

Did you check that the way you pass the option works? (usual way to do that is to try with an example that works and reduce the stack size to something ridiculously small to force an overflow) I am asking because the internet is full of reports that /F only works in very specific circumstances whereas /STACK works more often, or the reverse. I don't use that compiler so I wouldn't know.

20MB sounds bad, it indeed seems to indicate an infinite loop. Do you have a longer stack trace in the 20MB case?

The lazy kernel seems to have a DAG underlying it. What checks enforce that it is a DAG, i.e. is it possible I've got a long loop in my 'DAG'?

Well it seems hard from the code to produce a loop (but you never know).

Is there a construction I can use besides Lazy_exact_nt which will side-step
this issue? I want to use a Exact_predicates_exact_constructions_kernel, but
trying all combinations of using the flag CGAL_DONT_USE_LAZY_KERNEL with
CGAL_USE_GMP turned on and off, I run into ambiguous call errors with
CGAL::internal::fit_in_double in Orientation_2.h.

Maybe related to this?
https://lists-sop.inria.fr/sympa/arc/cgal-discuss/2011-01/msg00049.html

If you get different errors, it's worth reporting them.

--
Marc Glisse

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://lists-sop.inria.fr/wws/info/cgal-discuss