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

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-10 03:00:40

Luke wrote:
>> 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?  

John wrote:
>By order you mean the number of coordinates right?

Right.

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

You would not be using my library with these types, or if you did, you
would need to project it into a plane to provide a 2D view of it or
similarly reduce it to 3D.  In fact, my library is primarily concerned
with planar geometry, so might be ill suited to your math.  If you want
a 4D quaternian wouldn't you just define your own class for that instead
of using an n-dimensional hyper point that doesn't encapsulate any of
the semantics of a quaternian except that it has 4 coordinate values?
Better still, you create your own generic library for these geometric
concepts? 

Luke wrote:
>> In my case, I have the rich language of isotropy that 
>> performs runtime indexing.  There are separate index types 
>> for 2 and 3d geometry and type safety prevents an invalid 3d 
>> index from being used with a 2d type. The language of 
>> isotropy provides a different kind of abstraction than what 
>> you are doing abstracting away the order of the point.  The 
>> question that leaves us with is which abstraction is more 
>> valuable to the user, since they are mutually exclusive.

John wrote:
>Huh? I think 'Isotropic' may need some clarification, I thought you
>meant just that distances in each coordinate's direction have the same
>unit of measurement. Your comments make me wonder if there is something
>more...?

I do, of course, mean that distances in each coordinate's direction have
the same unit of measurement, but I mean more than that.  Because the
geometry is symmetric, user code can be refactored to be parameterized
based upon abstract concepts such as horizontal/vertical orientation,
positive/negative direction on the number line, up, down, left, right,
positive X, negative Y directions etc.  In this way poor quality code
with lots of flow control that is used to call the different named
function for accessing x, y and z values of a data type can be
parameterized by the runtime condition of what orientation/direction is
dictated.  This is what I mean by compile time accessors (implied by
generic order of the point) are mutually exclusive with istropic style,
since it forces there to be flow control to choose between symmetric
behaviors.

Thanks,
Luke