From: Noah Stein (noah_at_[hidden])
Date: 2005-10-12 21:01:54
> Deane Yang wrote:
> Noah Stein wrote:
> (more snipping)
> > Others, such as I, view the natural geometry to be a Grassmann space
> > http://portal.acm.org/citation.cfm?id=504792 .
> (long discussion omitted)
> This is a very cool idea for those who are willing to understand the
> geometry behind it all, but I suspect it's a little too mysterious for
> most users of the units library. Also, don't you need to store two
> numbers for each scalar quantity? Isn't that a little costly in both
> space and computation time? I think your approach makes more sense for
> points in more than one dimension, where storing n-dimensional points as
> (n+1)-vectors is less costly.
The amount of mystery IMHO is minimal. The idea introduces one new class,
possibly two. The grassman_point code would look almost identical to the
regular vector code. The extra overhead is that you get one extra term per
vector. In the case of quantities, you go from 1D to 2D. The new term is
an accumulator for the addition of weights. This information has to be
tracked in the two point combination functions anyhow. If you only promote
up to the grassman_point for point-point and scalar-point operations, you
have no overhead. The data is 1D except on the two functions that require
an accumulator at which time the extra datum appears in the point object
instead of a local in the function.
> I don't really remember exactly what happened, but I think the last time
> we discussed this, I finally decided that it would be best to just
> implement a pure "vector quantity" library first. The "point quantity"
> interface could be added later, if a consensus develops. Otherwise, each
> of us can easily add our own layer on top of the vector quantity
> library. (So I'm retracting what I said in my post responding to Andy
A fine point indeed. This could be the best course of action. The
grassman_point idea could be layered cleanly on top of a vector-only or even
a vector/point solution.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk