Re: [boost] Re: Dimensional Analysis Interest?

From: Jan Van Dijk (janvandijkinjapan_at_[hidden])
Date: 2003-10-16 22:57:38

On Thursday 16 October 2003 15:50, Deane Yang wrote:
> David Richardson wrote:
> > The library has to make some choice about the internal way it represents
> > the exponents, and the users just have to follow whatever convention the
> > library has.
> >
> > The concern is if a user stuffs dimensions into the n-tuple that do not
> > have the same semantics the library expects (e.g. multiplication of two
> > numbers does not result in the exponents in their n-tuples being
> > added).  If the library is hard coded to do conversion as if the n-tuple
> > contained physical dimensions, the library may incorrectly compute types
> > for arithmetic expressions.
>
> I'm sorry if I confused people. I never meant to say that the user
> should be able to specify the semantics of the exponents. I only meant
> that the user should be able to define the fundamental dimensions/units
> to be used (so, not necessarily mass, length, and time). As far as I
> know, you always want to add the exponents when you multiply two
> quantities. I even think that this is a mathematical fact and therefore
> should be hardwired (just as 2+2 = 4 is hardwired).

        Hi Deane,

This is not as clear-cut as it seems. Think about logarithmic units. As you 
know such units are defined as the N-log (typically 2 or 10) of the ratio of 
the value P, say, and a reference Pref. As an example, take the decibel:

power in dB = 10log(P/Pref).

[I forgot Pref, but that does not matter]. Anyway, the result is that 
combining two power sources of both 0dB yield 3dB: "0+0=3".

If the library is supposed to do not only dimensional analysis, but also unit 
conversion or even arithmetics on (physical) quantities, it should be taught 
that in the above case the P's should be added, rather than the 
representations of P in the logarithmic units. The units should be marked as 
logarithmic, so that distributivity (val1*u+val2*u=(val1+val2)*u) is no 
longer assumed.

This is probably outside the scope of the proposed library.

> But I do think it worthwhile to allow rational exponents (but NOT
> arbitrary precision). I'd like someone to show me a real example
> where the exponent had a numerator or denominator other than 1, 2, 3, or
> 4. (Even 4 is, for me, a stretch)

Such high exponents are very common in physical chemistry and thermodynamics.
As an example, the rate coefficient of a ternary process (A+B+C => whatever) 
has dimension [length]^6/[time]. These are very common. Even fourth-order 
reactions exist (giving an exponent of 9). Non-existing reactions with even 
higher arity are artificially formed in the field of theoretical/numerical 
equilibrium thermodynamics (to find out the equilibrium composition of 
complex chemical mixtures.) 

This is not only theory. This is what I do for a living. And precisely in the 
implementation of the code I have developed for these applications I would 
have used a dimension-cheking utility, were one available.

I am sorry that we (physicists) have ruined the beauty and elegance of your 
(mathematical) world ;-)

        Bye, Jan.

-- 
Keio-Tsuushin Residence
Dr. Jan van Dijk, Room 210
2 Chome 19-30, Mita Minato-ku
108 Tokyo, Japan
jan_at_[hidden]
tel: [phone] (home)