Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2006-03-25 18:21:04


> Andy Little wrote:

> What exactly does using physical quantities entail? Is the problem that
> performing matrix multiplication results in the types of the physical
> quantities becoming mangled, and if so couldn't you just make matrices
> use untyped units while allowing the vectors to keep their types?

I guess I really need to provide some detailed documentation about it, but that
is unlikely to happen soon as I have too much else to do.

A 3D vector needs to be converted to a homogeneous vector before it can be
multiplied by a matrix.

Lets assume a 3d length vector. it might have elements x == 1mm, y == 2 mm, and
Z == 3 mm

To convert that to a homogeneous vector requires multiplying each element by a
constant which is kept in the 4th element of the homogeneous vector. In the case
of a numeric homogeneous vector the constant is numeric naturally (usually, but
not necessarily, with value of 1) but in the case of a physical quantity vector
the type of the constant is the reciprocal of the type of the quantity
comprising the original vector. Assuming units of meters the constant would be
in units of meters to_power -1.

The homogeneous vector is suitable for multiplication by a 4 x 4 transform
matrix, but the types in the matrix are required to give a matrix of the same
type in multiplication of two matrices and to be multipliable by the vector.

The elements of the resulting matrix also have various different types . The
following is actual stream output for for a RC matrix describing a
rotation of 45 degrees about a point 1mm from thex origin and 1 mm from the y
origin (repeated from a previous post) The matrix is the result of concatenating
a translation , a rotation and another translation of course

| 0.707107, 0.707107 , 0 m-1 * 1e3 |
| -0.707107, 0.707107 , 0 m-1 * 1e3 |
| 1 mm , -0.414214 mm, 1 |

The units relate to the various transforms. The units provide a useful
reference over simply using numeric types. Note however that its not possible to
iterate over the rows and columns with operator [].

Of course the big question is whether it is worth going to all this trouble. Why
not just use numeric types? I dont have an answer to that except to say that I
have found it extremely interesting to find out how far it is possible to go in
using physical quantities over numeric types. There is probably a positive
benefit in catching errors in complicated equations. The other feature is that
it is simply more satisfying to be modelling using physical quantities directly
in equations. Thats difficult to quantify, but its maybe similar to the
difference between a high level language and a low level language or between
watching television in colour and black and white.

Thats the upside. I seem to be modelling reality a bit better. The downside is
that the implementation is much more complicated. Thats partly a result of C++'s
current lack of features (Joking!) which result in a lot of extra typing, though
Arkadiy Vertleybs Boost.Typeof library has already provided a good indication
that decltype and auto would help a lot. The other features such as Concepts
would also help I think. Nevertheless I think thats is a big practical issue
with pqs in general.

> For
> instance (note that I am using row vectors and assuming the meta
> function remove_units has been implemented):

Sure... To a mathematician and probably many physicists thats much easier, but
to me its just not sexy. I mean remove the units and you are back with doubles.
I do sometimes wonder if this is like the Emperor has no clothes thing but as I
said before I prefer not to justify whether what I'm doing with the geometry
stuff in pqs is useful or generally practical and thats why I would prefer to
develop it separately and keep it within the pqs library. ( OTOH I have had some
feedback especially from mechanical engineers and physicists that get it!)

regards
Andy Little


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk