CGAL users discussion list

["Jens K. Becker" <>]

Ok, the function join_facet for a polyhedron does not work on 32-bit systems
(tried rpm-based ones too now). At least not with double as a number type.

Any ideas?

Jens

--
Dr. J.K. Becker
University of Tuebingen - Institute for Geoscience
Sigwartst. 10 - 72076 Tuebingen (Germany)
Tel.: ++49 7071 29 73139   Fax: +49 7071 5059
web: http://www.jkbecker.de


Quoting "Jens K. Becker" 
<>:

> Hmm..
>
> I guess a was a bit quick stating that I am happy that it works and dont
> care...I tried different distributions of Linux now (all Debian based), all
> 32-bit. Always the same, in valgrind it works, outside it does not. Is it
> possible that parts of CGAL really need a 64-bit machine? Dont think so, but
> you never know...
>
>
> Jens
>
> --
> Dr. J.K. Becker
> University of Tuebingen - Institute for Geoscience
> Sigwartst. 10 - 72076 Tuebingen (Germany)
> Tel.: ++49 7071 29 73139   Fax: +49 7071 5059
> web: http://www.jkbecker.de
>
>
> Quoting "Jens K. Becker" 
> <>:
>
> > Hi all,
> >
> > I did try out the code on 2 different machines over the weekend:
> >
> > 1. machine: Older version of CGAl and Linux (32-bit Ubuntu): Same errors
> > 2. machine: Same version of CGAL and Linux but this time 64-bit 
> > Ubuntu: works
> > flawlessly.
> >
> > So I guess it has got nothing to do with the code itself but with 
> > internals of
> > the respective Linux (Ubuntu?) version, as Sebastian wrote. It is still a
> > strange thing, but there is not really anything I can do about it. 
> > If some of
> > you are interested in this problem, let me know and I can give you 
> > all the info
> > you may need. I myself will not go into it, I am just happy that it works.
> >
> > Sylvain, I had problems with construction of things before and never really
> > understood what the problem is. Therefore, I wrote my own checks for 
> > these (and
> > other things such as angle between facets, plane normal, halfedge 
> > length etc.).
> > I dont mind to do that since it is only standard math and easy 
> > enough to write
> > (thanks to the clever design of teh hds, I really like it), but I never
> > understood why my checks work and are stable while the build-in checks from
> > CGAL have problems (using double as a number type). Granted, my
> > checks/functions are probably not mathematically precise and I have 
> > to do some
> > extra checks (e.g. if the calculated cosine is <=1, it sometimes is 
> > 1.000000002
> > due to rounding), but they work good enough for me (and I suspect 
> > would be good
> > enough for other people using doubles).
> >
> > Thanks for your help and suggestions,
> >
> > Jens
> >
> > --
> > Dr. J.K. Becker
> > University of Tuebingen - Institute for Geoscience
> > Sigwartst. 10 - 72076 Tuebingen (Germany)
> > Tel.: ++49 7071 29 73139   Fax: +49 7071 5059
> > web: http://www.jkbecker.de
> >
> >
> > Quoting Sebastian Marino 
> > <>:
> >
> > > Stepping back from the geometric problem, if your code does execute
> > > correctly in under valgrid this is generally symptomatic of a memory
> > > management error.  It is also possible, I suppose, that you have
> > > different compiler settings between the valgrid build and the build
> > > that is executed and fails, although that is most likely not the
> > > problem at least in my experience.
> > >
> > > -Sebastian.
> > >
> > > On Fri, Nov 28, 2008 at 7:21 AM, Jens K. Becker 
> > > <>
> > >  wrote:
> > > > Hi all,
> > > >
> > > > I am very happy to give any information you need to solve the problem (and
> > > > am
> > > > quite sure that in the end I did something wrong somewhere). Here 
> > > > is what I
> > > > am
> > > > trying to do:
> > > >
> > > > 1. Make a polyhedron
> > > > 2. Delete all halfedges that separate facets that are in one plane
> > > >  - check if the facet halfedge->facet() and halfedge->opposite()->facet()
> > > > are
> > > > coplanar
> > > >  - if they are, use join_facet(halfedge) to delete the corresponding edge
> > > > and
> > > > therewith merge the two facets
> > > > 3. Retriangulate the polyhedron so that each facet is a triangle
> > > >
> > > > all of that using:
> > > > typedef CGAL::Exact_predicates_inexact_constructions_kernel K;
> > > > (me and Gmpq do not work together very well so I try with doubles)
> > > >
> > > > This works OUTSIDE of valgrind only if the polyhedra are cubes. If 
> > > > they are
> > > > anything else, it works only INSIDE of valgrind.
> > > >
> > > > If I start the program OUTSIDE of valgrind, it stops with:
> > > >
> > > > CGAL error: precondition violation!
> > > > Expr: circulator_size(h->vertex_begin()) >= size_type(3)
> > > > File: /home/jkbecker/Code/eKolos/src/eKolos/core/aPolyhedron_3.h
> > > > Line: 1196
> > > > Explanation:
> > > > terminate called after throwing an instance of
> > > > 'CGAL::Precondition_exception'
> > > >  what():  CGAL ERROR: precondition violation!
> > > > Expr: circulator_size(h->vertex_begin()) >= size_type(3)
> > > > File: /home/jkbecker/Code/eKolos/src/eKolos/core/aPolyhedron_3.h
> > > > Line: 1196
> > > >
> > > > CGAL probably produces antennas and at a later stage bails out because of
> > > > it.
> > > >
> > > > INSIDE of valgrind, it works fine.
> > > >
> > > > The polyhedra check out ok using p.is_valid(), they fail the higher tests
> > > > (p.is_valid(true,1)), but I am not sure about the real meaning of this yet
> > > > (I
> > > > will send output if needed).
> > > >
> > > >
> > > > Any ideas? Let me know if you need more info.
> > > >
> > > > Jens
> > > >
> > > >
> > > > jkbecker@tiny:~$
> > > >  gcc -v
> > > > Using built-in specs.
> > > > Target: i486-linux-gnu
> > > > Configured with: ../src/configure -v
> > > > --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
> > > > --enable-shared --with-system-zlib --libexecdir=/usr/lib
> > > > --without-included-gettext --enable-threads=posix --enable-nls
> > > > --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
> > > > --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc 
> > > > --enable-mpfr
> > > > --enable-targets=all --enable-checking=release --build=i486-linux-gnu
> > > > --host=i486-linux-gnu --target=i486-linux-gnu
> > > > Thread model: posix
> > > > gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
> > > >
> > > >
> > > > --
> > > > Dr. J.K. Becker
> > > > University of Tuebingen - Institute for Geoscience
> > > > Sigwartst. 10 - 72076 Tuebingen (Germany)
> > > > Tel.: ++49 7071 29 73139   Fax: +49 7071 5059
> > > > web: http://www.jkbecker.de
> > > >
> > > >
> > > > Quoting Sylvain Pion 
> > > > <>:
> > > >
> > > > > Laurent Rineau wrote:
> > > > > > On Friday 28 November 2008 14:17:06 Sylvain Pion wrote:
> > > > > > > Jens K. Becker wrote:
> > > > > > > > The program compiles fine but does
> > > > > > > > not work (it always crashes when trying to remove halfedges (using
> > > > > > > > join_facets). If I run it in valgrind, it perfectly works.
> > > > > >
> > > > > > > Valgrind does not emulate FPU rounding modes which are used to 
> > > > > > > implement
> > > > > > > interval arithmetic.  The later being used in filtered kernels 
> > > > > > > which you
> > > > > > > can find in many places in CGAL.  A solution is to used either inexact
> > > > > > > fast non-robust, risky, use-at-your-own-risk,
> > > > > > > may-or-may-not-work-for-you
> > > > > > > kernels e.g. Simple_cartesian<double>, or a slow exact kernel, e.g.
> > > > > > > Simple_cartesian<Gmpq>.  That may be enough for debugging.
> > > > > > >
> > > > > > > The ideal solution would be to ping the valgrind developers (again),
> > > > > > > so that they work on supporting this missing feature.
> > > > > >
> > > > > > Sylvain, you missed a point: Jens program works only *IN* valgrind, and
> > > > > > *that* is strange. What sort of CGAL can work only if rounding mode are
> > > > > > never changed?
> > > > >
> > > > > OK, then I guess we need more details about "does not work".
> > > > >
> > > > > But valgrind is quite bad at emulating the FPU.  For example I think
> > > > > it emulates 64-bit only FPU instructions, so it truncates the additional
> > > > > precision on x86.  This can affect the result, in which ever direction.
> > > > > Similarly, not emulating the rounding mode makes all intervals singleton,
> > > > > which prevents any filter failure, hence no costly computation, and so
> > > > > might make a program look like it works whereas the too costly
> > > > > computations
> > > > > might kill it for performance/memory reasons.
> > > > >
> > > > > Again, more details are needed, but my gut feeling is that it's most
> > > > > probably something around this problem.
> > > > >
> > > > > --
> > > > > Sylvain Pion
> > > > > INRIA Sophia-Antipolis
> > > > > Geometrica Project-Team
> > > > > CGAL, http://cgal.org/
> > > >
> > > >
> > > >
> > > > --
> > > > You are currently subscribed to cgal-discuss.
> > > > To unsubscribe or access the archives, go to
> > > > https://lists-sop.inria.fr/wws/info/cgal-discuss
> > >
> > >
> > >
> > > --
> > > Sebastian Marino
> > > Chief Software Architect
> > > Makani Power, Inc., Alameda, Ca.
> > > www.makanipower.com
> > > 510.387.8077
> > > --
> > > You are currently subscribed to cgal-discuss.
> > > To unsubscribe or access the archives, go to
> > > https://lists-sop.inria.fr/wws/info/cgal-discuss
> >
> >
> >
> > --
> > You are currently subscribed to cgal-discuss.
> > To unsubscribe or access the archives, go to
> > https://lists-sop.inria.fr/wws/info/cgal-discuss
>
>
>
> --
> You are currently subscribed to cgal-discuss.
> To unsubscribe or access the archives, go to
> https://lists-sop.inria.fr/wws/info/cgal-discuss