Re: [boost] Dimensional Analysis

From: Andy Little (andy_at_[hidden])
Date: 2006-03-10 12:51:46

"Paul Mensonides" wrote
>> -----Original Message-----
>> From: boost-bounces_at_[hidden]
>> [mailto:boost-bounces_at_[hidden]] On Behalf Of Andy Little
>
>> > This (my small sample code) is in no way supposed to be a
>> full-blown
>> > library, BTW.  It is just for amusement.
>>
>> How about rational dimension elements rather than integers.
>> Would that be possible using the preprocessor?
>
> The preprocessor isn't doing the work.  It is just generating the code that
> does
> the work.  Use of the preprocessor (here) is just making all that code write
> itself based on an initial sequence of fundamental units.

Unfortunately it wont compile on VC7.1, though I preprocessed it .
Seems to be based on doing maths inside array brackets to get different sizes?
Sounds quite like Boost.Typeof though more direct maths!

>> This occurs
>> rarely but needs to be possible.
>> One example is in measuring electrical noise where units for
>> noise-voltage density are  Volts * (Hertz  to_power -1/2).
>                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Out of curiosity, how does this occur starting from SI's fundamental units?

if :

K is  boltzmanns constant which is approx 1.38 e-23 Joules per Kelvin
T is absolute temperature in Kelvin
R is resistance in Ohms then

Johnson noise density  in Volts  / (Hertz to_power 1/2).
== sqrt( 4 * K * R * T);

However volts, energy and resistance are all compound units of course .
resistance = voltage / current,  power = current * voltage, power = energy /
time, energy = force * distance, force = mass * acceleration, acceleration =
distance / (time*time).

I think its possible to derive the  units of johnson noise density from
fundamental units that way.

>> The time element of the dimension works out as being to power
>> -(2 1/2) FWIW!
>
> You can certainly implement a static rational with a little template
> metaprogramming.  Reducing rational values with template metaprogramming would
> be expensive in general, but here were mostly talking about very "small"
> rationals.  You'd just end up with two "fields" per dimension (numerator and
> denominator) instead of one, and you'd have to use them as rational values.
> E.g. the way that I wrote it, you basically have:
>
> dim<mass, time, ...>
>
> ...where 'mass' and 'time' are integers.  Instead, you have to have 'mass' and
> 'time' be types that represent rational values (such as 'rational<-5, 2>').

Right (and I understand its for fun) , but presumably there is unlikely to be an
advantage over using templates  in compilation speed  and certainly not in
legibility ?

FWIW I have finally started using the preprocessor library in pqs. I needed to
generate a large number of  power of 10 functors with a rational exponent and
where the range is configurable by the user via a config macro. (For anyone
interested these functors are in
<boost/pqs/detail/united_value/operations/coherent_exponent_eval.hpp>. note: pqs
is in the review queue but not an official boost library )

The preprocessor code I ended up with is basically copied from
http://boost-consulting.com/tmpbook/preprocessor.html  ,which I found thanks to
the useful link in the preprocessor docs ;-). seems to work well but I dont make
any claim to really understand how it works though! (note: I'm quite happy to
leave it that way too unless I really need to know otherwise ;-))

>> > The things that I find amusing in it are that dimensions
>> are specified
>> > using variables, not types (somewhat unusual), and the way that the
>> > reconstruction of type from variables occurs.
>>
>> Is that the same as how Boost.typeof works ...?

[..]

> It is probably similar (as far as reconstruction goes).  I think that
> specifying
> dimensions using variables instead of types is different.  Instead of the
> above,
> you have something like:

 [cut example]

> All of the above are variable declarations, not typedefs.  They are variables
> that have no function except to be used in expressions for the purpose of
> extracting type.  In a scheme like this, the user never even sees the actual
> types of these variables.  Instead, the type is 'named' via an expression.

Presumably there is a chance that these end up in the executable though which
could tend to get messy?

[...]

> All of this is slightly more complex that what I wrote (which is no where near
> being a full-fledged physical quantities library), but it is all possible.

I have to admit that I prefer to use the preprocessor as a last resort, however
that might be seen as an improvement on my previous position which was to avoid
its use at all if possible.  Nevertheless I have  found the Boost.Preprocessor
library really useful recently as said above and also just plain impressive
because it seems to makes use of the preprocessor a bit more like a traditional
programming language, hence easier to understand or even just plain useable.

The Preprocessor library has to be the most original boost library I reckon!

regards
Andy Little