From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2008-03-06 17:20:29
On Thu, Mar 6, 2008 at 4:59 PM, John Femiani <JOHN.FEMIANI_at_[hidden]> wrote:
> >>>> Hopefully these can avoid the boost minefield relating to 'point'
> >>> because trees only work on coordinates (no need to intepret them as
> >>> 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)
> > 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
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!)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk