On Thu, Mar 6, 2008 at 4:59 PM, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
Hopefully these can avoid the boost minefield relating to 'point'
because trees only work on coordinates (no need to intepret them as
types points"
per se), and meshes are entirely topological.
I don't see anything wrong with a CartesianCoordinateConcept that .....
I see good use for:
IndexablePointConcept - supports runtime indexing (array-like access, e.g. vec[0]) TupleAccessConcept - supports boost::get<N>(vec) syntax at a minimum, and we can probably think of more. --Michael Fawcett
So much for avoiding the minefield! I really did not mean to steer this conversation that way. Anyhow I think we are talking about coordinates and not points. What I got out of the past discussions on points was that a "Point" is completely different than the coordinates used to describe it, and that there is this whole slew of semantic issues verses performance tradeoffs regarding things like the fact that vectors are not points, you can not add points, etc.
I don't think it matters in these algorithms whether it's a "point" or a "vector" or a "coordinate". All the algorithm cares about is, "it must be run-time indexable" or "it only needs to be compile-time indexable." The user of the algorithm must know that data to be spatially partitioned has to be a point in space, and many times there are space and efficiency reasons that these are treated both as vectors and points. Unless there is zero-overhead for going from point->vector and vice-versa, such distinction is worthless (except *maybe* for debugging) except in applications where performance is not important. Leave the rest of the distinctions to algorithms where it matters, and use different Concepts for those distinctions. Sorry for dragging the conversation off-topic, but at least it serves as a backdrop if any student decides to work on spatial partitioning (to the student: we want this, but you are entering a minefield!) --Michael Fawcett