Boost logo

Boost :

From: Leland Brown (lelandbrown_at_[hidden])
Date: 2006-06-14 05:21:31

--- Geoffrey Irving <irving_at_[hidden]> wrote:

> On Tue, Jun 13, 2006 at 09:13:43PM +0200, Janek
> Kozicki wrote:
> > Geoffrey Irving said: (by the date of Tue, 13
> > Jun 2006 09:30:39 -0700)
> >
> > > Specifically, you can make vector3 (or
> > > vector<3>, perhaps) a
> > > straightforward single unit Euclidean vector.
> > > It can have L2 norms and
> > > L^inf norms and cross products and all the
> > > operations that are undefined
> > > for vectors with components of different units.
> > > Then we could define a
> > > vector space variant of boost::operators to
> > > convert any tuple-like type
> > > into a vector space type.
> >
> > > In my opinion, this would be far more
> > > useful than writing phase space as
> > >
> > > vector<m,m,m,kg_m_div_s,kg_m_div_s,kg_m_div_s>
> >
> > PS: I like vector<3> , I think that Andy can't
> > argue with this name :>
> Or vector<T,3>

There's been a lot of discussion on this issue of
vectors and how/
whether to deal with vectors or tuples of mixed units.
 I'd like to
chime in with some of my thoughts: 1 - why I think
mixed vectors are
both sensible and important, and 2 - why I think this
could be easy
to implement, at least partially.

1. First, what's the real difference between a vector
and a tuple?
There are probably differences in the way they're
visualized by
various people, but I think we should be primarily
concerned with the
differences in semantics - what operations are
meaningful and/or
useful on each, which distinguish one kind from the
other. The way I
think about them, I see at least three differences:

    A. Vectors have operations like magnitude
(length), dot
products, cross products, angle between two vectors,
etc. For
tuples, in general, none of these functions have a
definition. (This is probably why they are hard to
"visualize" as

    B. Vectors can be transformed to other vectors by
multiplication. Thus, it's useful to have them be
compatible with or
embedded in some sort of matrix library. Tuples
typically are not
suited for such use.

    C. Vectors, like matrices, can be indexed
numerically (1st row,
2nd column, etc.), so it's easy to loop over the
elements. This is
part of what makes them suited for matrix
calculations. Tuples are
frequently referenced by name instead of number -
e.g., the members
of a struct.

So what about "vectors" of mixed dimensions/units? As
far as
property, they would not act like vectors. But for
property B, there
*are* many engineering applications that need mixed
aggregates to
have these operations. The bulk of my own work falls
into this
category, and this is, in fact, the situation for
which I developed
my dimensional analysis library in the first place.
Janek Kozicki
also commented on the need for matrix multiplication
with vectors in
phase space.

In my work, I tend to visualize these mentally as
tuples, not as
vectors in some N-dimensional space. But it turns out
mathematics I need to perform requires them to be
involved in lots of
matrix calculations - which also means the matrices
themselves have
mixed units.

In summary, I think it's important to allow vectors
whose elements
have different physical dimensions - even though
certain operations
like vector length will fail unless all the dimensions
are the same.

2. The good news is that I think this is almost
trivial to implement
using the "t3_quantity" or "free_quantity" or whatever
we decide to
call it. And with the other two "quantities" I found
it extremely
difficult to implement in a general way, so I suggest
don't bother.
If the user needs mixed vectors, he can use
"free_quantity." (Or he
can write his own matrix operations for his special
case, or exit the
strong typing and dimensions checking for the matrix

We can do this if we define vectors as vector<N,T>
like this:

    vector<2,double> // 2D dimensionless
    vector<3,pqs::length::km> // 3D position
vector in km
    vector<6,pqs::free_quantity> // 6-element vector
of mixed units
                                  // (e.g., phase

And I agree that this is better than:


Likewise with matrices, perhaps use matrix<M,N,T> like


etc. FWIW, in my library I made the type parameter
default to
double, which allows simply vector<3> if you want a
unitless vector.

> Templatize specialization is probably required to
> get all the lower
> dimensional versions fast, but that's happily
> transparent to the user.
> Specialization also allows the low dimension
> versions to have nice member
> variables like x,y,z.

I agree. Especially since cross products only exist
for 3D, template
specialization is probably needed for that case at

-- Leland

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

Boost list run by bdawes at, gregod at, cpdaniel at, john at