Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-10-15 09:27:11

Hi,

Here are the few answers I can give right now, I let Barend complete
or correct me, and answer the questions for which he has a better view
of the library than me.

> - The names of the geometric objects isn't dimension agnostic, which might
> or might not be a problem. A circle is a circles in 2D, but a sphere in 3D. A
> line, however, is always a line. Same for segment  and polygon (and all
> yet-to-be-implemented objects which are polygons).
> I think naming should try to differentiate objects that stay what they are
> when dimension varies or that evolve with that dimension. Either way, the
> name convention should be clearly explained in the documentation.

Indeed it's something that should be done, we had a quick discussion
about that with Barend and decided to postpone that for now. This kind
of subject is never easy. For example, I'd like to rename circle into
hypersphere or nsphere, but then we'll also have to clarify the
meaning of some algorithms. For example what we currently call the
area of a circle is actually the volume of an hypershere<2>...

> - Also, while most names are 2D-centric, "box" is 3D-centric. This seems
> fairly inconsistent.
> Or maybe it's just me and box is actually dimension agnostic.

box doesn't sound less dimension agnostic than anything else to me,
but this can be discussed...

> - Still about "box", it is really an axis-aligned (whatever that means in
> non-cartesian geometries) hyperrectangle.
> Since "box" can not contain an arbitrary box, maybe it should be called
> minmaxbox or aabox or whatever.

aabox could be good.

> - envelope calculates the minimum bounding axis-aligned hyperrectangle for
> an object.
> It might also be desirable to have a way to calculate the minimum bounding
> hyperrectangle (non necessary axis-aligned) or the minimum bounding sphere.
> What names would those algorithms have if envelope is reserved for AABHR?

Indeed, maybe this name could become minimum_aabox and be accompanied
by other algorithms like minimum_box, minimum_sphere
(minimum_hypersphere??), etc...

> - Modeling sequences of polygons as iterator pairs seems an annoyance to me,
> ranges are much prettier to handle since one variable is thus sufficient to
> represent one object (while two are required for iterators).

Maybe we can double each algorithm to have the choice between passing
a pair and a range. AFAIK, this will be the approach of the algorithms
in C++0x, am I right?

> - Algorithms should be overloaded to handle all geometric objects. I assume
> the reason it wasn't done is simply because of time to do so.

Yes I suppose that we'll be able to add those overloads once the
general design will be validated.

About the default constructors debate: like Mathias I'd be inclined to
have constructors that guarantee the integrity of any existing object
and make checks useless, that's the choice I make in most cases. Luke,
could you give some actual examples of cases where you found really
annoying your legacy polygon class?

Bruno