Deane Yang wrote:
Noah Stein wrote: (more snipping)
Others, such as I, view the natural geometry to be a Grassmann space which 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 Little.)
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. -- Noah