Boost logo

Boost :

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?


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

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

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

