Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-10-16 14:13:08

Bruno wrote:
>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>...

My preference would be to have a circle data type, a sphere data type
and a hypersphere data type.  Only the hypersphere would be
parameterized on dimension.  The user would pick the object that is
named for what they want.  If a user wants a circle they are going to be
frustrated and confounded that we provide them nsphere<2>.   There is
something of a conceptual disconnect between circle and sphere.
Perimeter has a non-obvious meaning to a sphere, but has a clear meaning
with a circle.  Area of a circle is more analogous to volume of a
sphere, but it would be confounding to call area(sphere) to get its
volume, and equally confounding to call volume(circle) to get its area.
Just so that everyone who tries to use the library isn't completely
confused I think we should make the naming of things specific, and err
on the side of having more functions, more objects and more concepts in
the library rather than reducing it to something minimalistic but
thoroughly confusing.  Geometry is the ideal thing to apply a concept
based type system to because everyone knows and understands geometry at
a conceptual level.  We have an opportunity to write a library that
provides an intuitive and productive API that results in highly readable
user code.  We don't want to let that opportunity slip through our
fingers chasing some goal of template elegance that only we appreciate.
The goal of templates should not be to save typing implementing the
library, and we should make the user experience we want to achieve with
our library the foremost thought in our minds during its design.

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

How can you model a rectangle that is not axis aligned and is still a
rectangle?  The only way I can thing of is to model it is width, height,
center point and rotation.  If you snap its corners to the coordinate
grid it will, in general, no longer be a rectangle.  Similar to the
circle, I like rectangle, prism and hyperprism for 2D, 3D and ND
rectangles.  While non-axis-aligned rectangles could be useful, you have
the option of modeling them as polygons with 4 vertices that are as
nearly rectangular as you can make them within your coordinate system.

Luke