Re: [boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale

Subject: Re: [boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2009-11-15 11:12:40

Jose wrote:
> Did someone decide that it was not possible to have a single GENERIC
> GEOMETRY library and we should have two ?

Somebody that studied informatics might like the term "GENERIC GEOMETRY", but somebody that actually took lessons in geometry might have a different opinion.

A look at my book shelf reveals that I own at least the following books on geometry:

Jean Fresnel; "Méthodes modernes en géométrie"
Marcel Berger; "Géométrie 1"
Marcel Berger; "Géométrie 2"
Marcel Berger, Bernard Gostiaux; "Géométrie différentielle: variétés, courbes et surfaces"
Marcel Berger; "A Panoramic View of Riemannian Geometry"
Günter Aumann, Klaus Spitzmüller; "Computerorientierte Geometrie"
Oswald Giering, Hans Seybold; "Konstruktive Ingenieursgeometrie"

OK, most of all this shows that I like the books of Marcel Berger, but that is not the point I want to make. A bird eyes view on the "Table des matières" of Jean Fresnel's book can be summarized as follows

A. Géométrie affine
B. Géométrie projective
C. Géométrie euclidienne
D. Géométrie non euclidienne

Is there something that these different geometries have in common? I guess a very good answer to this question is the "Erlangen program" by Felix Klein (http://en.wikipedia.org/wiki/Erlangen_program). The essence is that you could look at the hierarchy of their "group of symmetries" and study their invariants.

However, there is also "convex geometry" (Chapitre 11. Ensemble convexes and Chapitre 12. Polytopes. Convexes compacts in Marcel Berger; "Géométrie 2") which is probably not well covered by the "Erlangen program", so I'm not completely sure about this.

The point I want to make is that if somebody requested a single "GENERIC INFORMATIC" library, you would probably realize that this request is not reasonable. However, to request a single "GENERIC GEOMETRY" library is probably not significantly more reasonable. So what about CGAL? The "Computational Geometry Algorithms Library" (CGAL) is a collection of data structures and algorithms that cover much ground. However, would you call CGAL a "GENERIC GEOMETRY" library? Or even a "GENERIC COMPUTATIONAL GEOMETRY" library?

Now Boost.Polygon has a set of algorithms that make sense in a VLSI context, and tried to build up a hierarchy of geometrical concepts well suited for the set of available algorithms. The implementations of these algorithms in Boost.Polygon often won't work well with floating point coordinates, because these algorithms were developed with fixed point coordinates in mind. (Because everybody pushes him, Luke tries to come up with some solution for the "floating point issue", but we should realize that this is a really difficult problem. So I can understand that Luke points out problems in the floating point code of GGL, because he doubts that they could solve the problems that are nearly unsolvable for him.) The concepts themselves have no problems with floating point coordinates, but does this really matter?

Now GGL on the other hand excluded most of the implemented algorithms from the review by declaring them as extensions, and focused on providing a "dimension-agnostic, coordinate-system-agnostic and scalable kernel". Boost.Polygon obviously focused on fixed point coordinates in 2D, but is GGL really significantly less focused on 2D? I don't know. At least it is not focused on fixed point coordinates.

Regards,
Thomas