CGAL users discussion list

[Peter Hachenberger <>]

Hi Fred,

> Yes, I refer to Nef_nary_union_3. It only stores log(n) of n given
> polyhedra.
> I know that it looks very simple, but there is more to it than you see on
> first sight.

Alright, my apologies! I gave it a better look and there is certainly a
lot of cleverness in there. And it performs much, much better than a naive
accumulation. Although, if I may pick on a point, I can't see that this is
due to any great memory advantage: I can see that there are log(n) Nefs,
but their total size should be proportional to the size of a "naive
accumulation" at the same stage.

OK, I did not explain what algorithms I compare. If you compare mine to the naive consecutive approach, then mine has a
little more memory overhead. But the naive approach is unacceptable either way. Intermediate versions of my approach
needed to have all the input in memory to begin with. That's not necessary any more.

Since you started experimenting with the nary union, here is one more advice. If you find a way to load and add the input polyhedra
in a sorted fashion, e.g., sort the smallest points of the polyhedra lexicographically, the nary union will be faster.

Meanwhile, any word on whether it makes sense to perform nary overlays and
nary marking? Is there a theoretical issue with this?

What do you mean by nary marking?

BTW, I'm still not sure whether you are Fred Dorosh and just changed your email address, or are a different Fred.

Peter