Error with natural_neighbor_coordinates_2

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Error with natural_neighbor_coordinates_2

David Reis-2
Hello folks,

I´m using the natural_neighbor_coordinates_2 function as:

----------------------------------
typedef CGAL::Exact_predicates_inexact_constructions_kernel Kernel;
typedef CGAL::Delaunay_triangulation_2<Kernel>  Delaunay_triangulation;
typedef Kernel::Point_2 Point;
typedef Kernel::FT Number;
typedef std::pair< Point, Number > Point_coordinate;
typedef boost::numeric::ublas::matrix<Point_coordinate> Point_coordinate_matrix;

Point_coordinate_matrix shape_functions(support_domain_size,support_domain_size);

Point_coordinate_matrix::iterator1 it_row = shape_functions.begin1();
CGAL::Triple <Point_coordinate_matrix::iterator1,Number, bool>
   result = CGAL::natural_neighbor_coordinates_2(support_domain_dt, test_number, it_row);
----------------------------------

The objective here is to put the natural neigbhor coordinates at the current row in the boost matrix.

The VC++ 9.0 compiler generates this error:
error C2679: binary '=' : no operator found which takes a right-hand operand of type 'std::pair<_Ty1,_Ty2>' (or there is no acceptable conversion)    c:\arquivos de programas\cgal-3.3.1\include\cgal\natural_neighbor_coordinates_2.h    62

Isn´ the matrix row operator a valid output operator?

Thanks,

David Reis
Cel: (31) 9608-8138
Tel: (31) 2526-2091
Reply | Threaded
Open this post in threaded view
|

CGAL and valgrind

Dr. J.K. Becker
Hi all,

I have a pretty strange problem. I have written a numerical simulation
software (or better I am trying to) that uses CGAl (especially the
polyhedra and therewith hds) a lot. 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 is a software that can be used to check for memory-leaks (there
are none) etc..

 From wikipedia.org:
...
Valgrind is in essence a virtual machine using just-in-time (JIT) (aka
binary translation) compilation techniques. Nothing from the original
program ever gets run directly on the host processor.
...


So far so good, but now I have absolutely NO idea where to look for what
goes wrong (and why). Any ideas?

Thanks for any hints,

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



--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://lists-sop.inria.fr/wws/info/cgal-discuss
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Sylvain Pion
Administrator
Jens K. Becker wrote:

> I have a pretty strange problem. I have written a numerical simulation
> software (or better I am trying to) that uses CGAl (especially the
> polyhedra and therewith hds) a lot. 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 is a software that can be used to check for memory-leaks (there
> are none) etc..
>
>  From wikipedia.org:
> ...
> Valgrind is in essence a virtual machine using just-in-time (JIT) (aka
> binary translation) compilation techniques. Nothing from the original
> program ever gets run directly on the host processor.
> ...
>
>
> So far so good, but now I have absolutely NO idea where to look for what
> goes wrong (and why). Any ideas?
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 Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Laurent Rineau (GeometryFactory)
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?

--
Laurent Rineau, PhD
Engineer at GeometryFactory
http://www.geometryfactory.com/
--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://lists-sop.inria.fr/wws/info/cgal-discuss
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Sylvain Pion
Administrator
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/

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Dr. J.K. Becker
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 <[hidden email]>:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Dr. J.K. Becker
In reply to this post by Dr. J.K. Becker

-- Sorry, forgot...

I tried using Gmpq before but had lots of problems with it. Passing around
pointers to Gmpqs, they sometimes (random) ended up being NULL (0x0). This
seems to be a problem with Ubuntu and/or the versions of Gmpq it uses
(I am not
the only one who had this problem, see previous post 6 months ago or
so) but it
was never solved. I tried to install and compile the sources for mpf gmpq etc.
(which worked) but the problem remained. So I switched to double with which I
am much more familiar (being a geologist).
This is why me and Gmpq do not work together very well but it seems
that I just
exchanged one problem against the other.

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
>
>
>

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://lists-sop.inria.fr/wws/info/cgal-discuss
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Bernd Gaertner
Jens K. Becker wrote:
> So I switched to double with
> which I
> am much more familiar (being a geologist).
> This is why me and Gmpq do not work together very well but it seems that
> I just
> exchanged one problem against the other.

I didn't follow the thread, so I'm sorry if this has ben discussed/is
not helpful: there are also CGAL::MP_Float and CGAL:Gmpzf which are
closer to double in some sense than Gmpq.

Best,
Bernd.
--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://lists-sop.inria.fr/wws/info/cgal-discuss
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Sylvain Pion
Administrator
In reply to this post by Dr. J.K. Becker
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).
Depending on how the coplanarity test is performed, you may internally use
geometric constructions.  I'm not that familiar with the Polyhedron, but I
believe it stores a plane in each facet, and constructing a plane from
the vertices is a construction.  Therefore you may run into a robustness
issue that involves constructions, requiring exact constructions, so
either Cartesian<Gmpq>, or the hopefully faster
Exact_predicates_exact_constructions_kernel (EPECK).
Note that converting between Gmpq (or the exact number type of the EPECK
kernel) to double can easily be done with the CGAL::to_double function.

Another approach may be to not rely on the plane, and perform coplanarity
tests based only on points, which uses only a predicate, and therefore the
Exact_predicates_inexact_constructions_kernel (EPICK) might be enough to
ensure robustness.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Sebastian Marino
In reply to this post by Dr. J.K. Becker
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 <[hidden email]> 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 <[hidden email]>:
>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Dr. J.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 <[hidden email]>:

> 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 <[hidden email]> 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 <[hidden email]>:
>>
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Dr. J.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" <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: CGAL and valgrind

Dr. J.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" <[hidden email]>:

> 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" <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]> 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 <[hidden email]>:
>>>>
>>>>> 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
>



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