Re: [boost] [GTL] redesign checked into sandbox

From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-05-10 05:39:03

Hi,

>> Yes, my own is very similar to what you show, except that I
>> think n-dimensional point classes are pointless exercise, if
>> you'll excuse the bad pun.  What exactly is the benefit of
>> making the order of the point data type generic?  Are we
>> saving typing in the library by merging the 2D and 3D point
>> concepts?  Do we pay a penalty for that?
>
> By order you mean the number of coordinates right?
>
> This is actually really important to me. Coordinates in 2D and 3D are
> important, but 4D coordinates are too (eg, homogeneous or projective
> coordinate). Quaternians are 4D (well, 4 coordinates),  and Plucker
> cordinates have 5 coordinates.  Those are cases I came up with off the
> top of my head, but I know there are more examples I did not think of
> yet. There are very valid reasons that the size of a coordinate set
> should be specified at compile time for cases other than 2 or 3.

Yep this is my point of view too. We're not talking about "merging 2D
and 3D" but making generic algorithms Some very simple algorithms like
distance or dot product, or even addition and subtraction, have to be
implemented in a dimension-agnostic manner. BTW, that was exactly the
purpose of my first submission to Barend, when I extrapolated his
pythagoras algorithm to make it work with any number of dimensions. As
a potential user, it's my first requirement.

Some algorithms only make sense for a precise number of dimensions. I
guess those ones can just statically check if the point that has the
right coordinate_count (or "at least enough" coordinates, don't know
yet).

If your library is 2D-oriented, I'm obviously not asking you to put
the coordinate_count requirement into your concept since you wouldn't
use it anyway. It's always the same principle: the concept represents
the minimal set of requirements, so it's OK for me like that.

Regards
Bruno