Andreas; The cgal kernel makes a distinction between point and vector at compile time, and provides a CGAL_ORIGIN constant of type cgal::Origin with linear-to-affine conversions overloads cgal::Point operator+(cgal::Origin const&, cgal::Vector const&); cgal::Point operator+(cgal::Point const&, cgal::Vector const&); where the second overload involves component-wise addition, but the first is runtime-free. Perhaps it is what you already described, I haven't followed the whole discussion. In any case, it probably would be a good idea to check the CGAL kernel out. Nevertheless, it is still up to the CGAL programmer to keep track of to which affine frame (coordinate system) any point belongs. It would be a nice project to register frames and automatically handle the conversions between the frames via the registered transformations (and even combine transformations transitively), but that might be too much of the automated... plus for high-performance applications, I believe the compile-time safety such afforded would only be worthwhile if it could be done at no (or extremely little) cost to runtime performance. A tall order. My two cents, -- Herve On 3/9/07, Matthias Schabel <boost@schabel-family.org> wrote:
representation (i.e. a dimension). I just couldn't think of any other meaningful operation.
I believe that vector operator-(point,point) is sensible...
space. You can add Kelvin to Kelvin and Celsius to Celsius, but you can't mix them. The corresponding results are either in
In this case, since the metric is degenerate, they can be implicitly converted to one another if you're talking about temperature differences.
293.15 Kelvin represent the same temperature as 20 degrees Celsius, but doubling both will lead to very different results.
If you mean 293.15K in absolute temperature, you're right. However, doubling a temperature difference makes perfect sense in either unit system.
something entirely different. So I'd stick to offer a transformation between absolute temperatures.
But in most ways differences behave more like what we expect when we use units. That is a length, for example, is really a difference between the two endpoints of an object, etc...
Since people are likely to expect reasonable handling of both absolute temperatures and temperature differences, we may end up adding the absolute<> wrapper to the units library to allow that intent to be indicated and caught. Relative values are basically degenerate with bare value type and probably don't need a special wrapper. Then the operations that need to be supported are :
absolute<T> operator+(absolute<T>,T) absolute<T> operator+(T,absolute<T>) absolute<T> operator-(absolute<T>,T) absolute<T> operator-(T,absolute<T>) T operator-(absolute<T>,absolute<T>)
I think that's about it. You can't multiply absolute values by scalars or add them to themselves, obviously. Of course, this functionality certainly has relevance beyond the dimensional analysis/units domain, but I don't know if it's possible to find a sufficiently generic solution that meets every reasonable need and is implementable...
Matthias _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost