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
>> > 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
> 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?
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
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
> dimensions using variables instead of types is different. Instead of the
> you have something like:
> 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk