[boost] physical quantities

From: Andy Little (andy_at_[hidden])
Date: 2004-06-12 07:24:50

The next version of my physical quantities libary pqs-1-01-04 is available
on my site at:

http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-01-04/download.html

The original type has now been augmented by another. The original type has
now been renamed as a 'ct-quantity' representing a physical quantity whose
units cannot be modified at run-time. The other type is the 'rt-quantity',
whose units can be modified at run-time. The two types are of course
compatible and the rt-quantity in particular is useful for further
derivation, for instance into a physical quantity whose units can be set and
interrogated via strings ie "mm, kgf" etc of which there is an example in
the examples directory.

The first question many will ask about such a library is : "How does the
run-time speed/memory performance compare with using inbuilt types?." That
is an important question, but to me not the most important one.  (The answer
is that this is implementation dependent and the current implementation is
not optimal)

Having used the library for some time its power seems to lie in the fact
that it models a concept quite accurately from a programmers point of view.
IOW what you can do with the type is restricted (by the compiler) to (some
subset of) the entity that it models. The reason that this is powerful is
difficult to define, but can be summed up in the saying:
" a picture is worth a thousand words"

I now see more clearly what those who wanted to see currency conversion and
number of apples per kumquat or whatever where driving at. However these are
not physical-quantities. C++ does have the ability to express those
concepts, but they lie outside the remit of the concept that this library
models.

Nontheless such concepts would be useful. So in a network model a byte,
packet etc would be a concept which would be modelled by a C++ type.
Strongly enforcing the rules by which entities interact is satisfying , I
guess, because it clarifies the mental picture of a program. Modelling
everything by a double or an int (should number_of_bytes_received be
convertible to double ... probably not etc)  means everything is mush.

So on a personal note designing the library has been very rewarding. As I
spend much time GUI programming, it strikes me that the next useful concepts
are those of model-space, view-space, paper-space etc. Here a  point in
space would be represented by different types which could only exist in the
relevent space, but have the intelligence to perform transforms from one
space to another. Similarly where one is modelling (say) magnetic flux
density at a point x, y, z , the role of the view-space would be to convert
form the entity in model-space to 'some representation ' in the view-space
or the paper-space. The obvious candidates for the types in model-space
being the ct-quantity of course.

regards
Andy Little