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