Re: [boost] Library Proposal: Boost.Geom 2D and 3D GeometricPrimitives

From: Andy Little (andy_at_[hidden])
Date: 2005-06-26 18:41:18

"Anis Benyelloul" <benyelloul_at_[hidden]> wrote
> Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
>
>> I had a quick look.
> Thanks !
>
>> You would need to change the licence for boost.
> Ahem.. I assume you're talking about the manual, because the code
> *is* under the Boost Licence. And about the manual, I don't recall having
> read something that forbids FDL for manuals ... maybe be I missed it ?

Ok .. I dont know how boost sees this.

>> Not quite sure I understand the reason behind the parameter for points.
> You're talking about the template parameter of geom::point<> ? Well, it is
> an implementation type (as explained in the manual), something that tells
> geom::point<> how you'd like to implement the notion of ``point'' (as XY, as
> XYZ, as polar coordinates ... etc).
The interface is familiar :

url<http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/source/streamlines.hpp>

Recently howver I use a struct with x and y members... its less typing  ;-)

Ok.  I understand the use of a common type for cartesian and polar coordinates.
Alternatively  these two types could be provided as complete useable types, with
a common interface. A viable alternative to the wrapper is simply to provide a
conversion from one to the other type. Specialising the traits class looks to be
nearly the same work as writing  these from scratch with a common interface.
One could provide something similar by overloaded functions:

I dont see the advantage in wrapping other libraries point types. I would want
precisely defined semantics on the parameters of a point. For example I would
expect the semantics of float versus integer value_types to be defined
separately. Allowing use of  user defined point systems would appear to make
this type of control of the specification much more difficult, if not
impossible.

Not sure what units angles are in. Is it degrees or radians? radians is my
preference. FWIW I use specific type safee angle types. This allows conversions
between the two families of angular unit. I also use types representing lengths
in graphics. IOW I use a point<pqs::length::mm> type  etc. This provides
graphics data with unit information independent of the device its currently
being displayed on. Its not a solution for every case but where the units of  an
entity is fixed it provides this information with no runtime space overhead.
See my site at
http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html

I strongly disagree with the statement in the documentation:

" Indeed, a ``2D point'' is just a 3D point whose implementation doesn't
actually reserve memory space for a Z attribute."

2D space has no notion of another dimension. There is no Z attribute.
Projections of 3D objects onto a 2D plane are not limited to truncation of their
z-dimension. Mixing 2D and 3D points doesnt actually happen in my experience.
They live in separate spaces. 3D points are mapped to 2D points by applying a
transform(projection).  Some sort of matrix operations on 2D and 3D points
should also be available(which will require conversion to homogeneous
coordinates).

>> Why no lines?
> Maybe in the next version ? But think of this, what is a line ? isn't it
> a std::pair<point, point> ? Also, I had the idea of geom::region (a region of
> the plan/space) a collection of boxes, geom::polygon<> a collection of
> points  ... etc ... But lets make sure we have the best points and rectangles
> of the planet first :)...

The box here is useful for a GUI viewport or window, an attribute of  the
current output device. IMO Its a mistake for a geometry library to get involved
with this low level stuff too early. Geometrically a box is a 2D region bounded
by  geometric *1*  lines, with no guarantee of its attitude. Why not start with
the most primitive concepts, eg geometric points, lines, circles arcs, curves
and regions? As for lines, one could use std::pair, but  IMO a 'line'  type is a
clearer statement when reading code.

That said, there should be some form of  mechanism for graphical output on
various platforms/ devices, but again without this affecting the core geometry
library. generically this requires some means of converting points between
various coordinate systems.

Sorry for all the criticism. As you may gather I have my own ideas on what I
want from a geometry library... looking forward to hearing your views ...

* 1* as opposed to  lines which have colour and thickness. These attributes,
though required for output are not necessary from a geometric viewpoint

Andy Little