|
Boost : |
From: Leland Brown (lelandbrown_at_[hidden])
Date: 2006-06-09 13:57:20
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
> "Leland Brown"wrote
> >
> > When I have a vector of mixed quantities (length, velocity, time,
> > dimensionless - together in one vector), I end up going to something
> > more like t3_quantity. (FYI, this occurs in the context of least-squares
> > estimation of model parameters, where the parameters are of various
> > dimensions.)
>
> In cases of vectors, I have only used vectors where all elements are one type
> of quantity. The vectors are used to represent position, direction and so on
> in 3 dimensions. A container that holds different quantities I would consider
> to be a tuple. But I stress I am not an expert.
I see what you mean. But unfortunately, in the least-squares estimation,
the tuples get used extensively as vectors in heavy linear algebra equations.
So I'm stuck with using vectors of heterogeneous units in a matrix library.
> The question then is: when are the benefits of strong type checking (so use a
> Quantity type) justified, and when arent they (so use a float type). That
> would be a good question to answer in the PQS docs AFAICS. But not a trivial
> one.
True on both counts.
> I would guess that the only problem
> apart from slow performance would be that the t3_quantity would use a lot of
> space compared with a float, which would have an impact if used in some
> situations.
Yes, but perhaps not as much space (or time) as you would think. I allocate
a few bits to each dimensionn exponent and combine them in a single iteger
value. Then in a multiplication I can add all the exponents at once with only
one addition operation (and I can check for matching dimensions with only
one integer comparison). This works well for me because I have only integer
exponents and only length and time dimensions, so I can easily allocate
plenty of bits to avoid overflow. Perhaps you can make use of something
similar in your design.
-- Leland
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk