
Boost : 
From: Hervé Brönnimann (hervebronnimann_at_[hidden])
Date: 20070312 21:11:59
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 lineartoaffine 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 componentwise addition, but the
first is runtimefree. 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 highperformance applications,
I believe the compiletime 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_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk