Re: [boost] [units] Any interest in dimensional analysis for orientational dimensions and Euclidean vectors?

From: Hervé Brönnimann (hervebronnimann_at_[hidden])
Date: 2007-03-12 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 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_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