Re: [boost] [PQS] rank of a physical quantity?

From: Matthias Troyer (troyer_at_[hidden])
Date: 2006-06-20 05:44:17

On Jun 19, 2006, at 7:23 PM, Oleg Abrosimov wrote:

> Gerhard Wesp wrote:
>> On Mon, Jun 19, 2006 at 10:04:21AM +0200, Matthias Troyer wrote:
>>> As a physicist I am completely baffled and confused. What do you  
>>> mean
>>> by rank of a quantity? Do you mean the size of a vector/matrix? If
>>
>> I understood Olegs post about rank such that it was something that  
>> would
>> allow to distinguish energy from torque, e.g.  Is there such a thing?
>> Off the top of my head, I cannot think of a situation where you might
>> want to add energy to torque, even if in the SI system they have the
>> same dimension (Nm).
>>
>> Same thing for angular velocity [rad/s] and frequency (1/s).  You
>> probably don't want to add both, even if in SI they're both in  
>> s^-1.  Is
>> this maybe a deficiency of SI?  Would it make sense to add the unit
>> "radians" that is used colloquially anyway, to the system?
>
> You are almost right, but in the end you've chosen a wrong direction.
>
> There is a very good article in wikipedia about tensors in which  
> tensor
> rank is also described:
> http://en.wikipedia.org/wiki/Tensor
>
>
> The wrong direction is about deficiency in SI. The SI is all about
> units, rank is absolutely orthogonal concept to units (of course it
> deals not only with units, but also with dimensions, but it is natural
> because units are just scales in multidimensional space defined by
> dimensions). The truth is that angular velocity is (surprise!) a
> pseudovector. Its direction is the same as a direction of rotation  
> axis.
> it is known to be involved in the following equation:
> velocity_vector = crossproduct(angular_velocity_pseudovector,  
> radius_vector)
>
> On the other hand, frequency is simply a scalar. So, here is the same
> situation as we have in energy vs torque "paradox" ;-)
>
>
> Roots of such a problems lies in existence of two operations that
> produce the same dimension from given ones:
> 1) dot-product (results in a scalar, like energy)
> 2) cross-product (results in a vector or a pseudovector, like torque)
>
>
> This problem can not be solved only inside dimensional analysis. I  
> hope
> that it is clear from this post.
> The solution is to take into account the rank of quantity (rank is  
> 0 ->
> scalar; rank is 1 -> vector, ...)
>
> It can be implemented absolutely in the same manner as dimensional
> analysis: rank would be a compile time constant that is bound to
> quantity and all operations would be defined with respect to  
> quantities'
> rank. It means, in particular, that dimensional vector _must_ be  
> defined as:
> 1) length< vector<double> > l;
>
> and not as:
> 2) vector< length<double> > l;
>
> reason is simple - we should define operations for vectors (rank is  
> one)
> that respect rank of it's results. For example:
> dot(v1, v2) -> scalar (rank is 0) of dim = dim1 * dim2
> cross(v1, v2) -> vector (rank is 1) of dim = dim1 * dim2

I feel that this discussion about "rank" is trying to achieve too  
much. If I understand it correctly, one wants to prevent users from  
mixing quantities with the same units but different semantics, and to  
use the "rank" or some other identifier to disambiguate them. I would  
propose to completely drop this idea, since there are *many* more  
examples where semantics play a role. Just consider

- Total energy of a system or energy per particle have the same units  
but care must be taken in adding them
- Free energy, energy, and enthalpy have the same units but care must  
be taken in adding them
- Price of a produce including or excluding tax has the same units,  
but but care must be taken in adding them
- ...

There are many cases where it does not make any sense to ad two  
quantities even if they have the same units. No matter how one  
extends the unit library, one will never be able to catch all of  
them. I thus think that the unit library should focus on unit  
checking and conversions and not attempt to prevent any possible user  
error, especially if this will make the library more complex and will  
require a completely new linear algebra library to be written

Matthias