Re: [boost] [Review][PQS] Review deadline

From: Andy Little (andy_at_[hidden])
Date: 2006-06-09 13:16:34

"Leland Brown"wrote
> Andy Little <andy <at> servocomm.freeserve.co.uk> writes:

[...]

> For anyone who scratches their head as to what t3_quantity would be good for,
> here's one answer!  It can be used with existing linear algebra libraries with
> a minimum of effort.  (It would still be good to use t3_quantity only when
> necessary, however, because of the run-time penalty.)

OK. That is the sort of functionality I saw for the  t3_quantity. In a simple
implementation it would need to carry its dimension and unit information around
at runtime though AFAICS, which would be quite an overhead in terms of size and
speed.

>> > blas::vec3<float> a(1, 0, 0);
>> > blas::vec3<double> b(0, 1, 0);
>> > blas::vec3<double> result = cross_product(a, b); // returns vec3<double>!
>> >
>> > template <typename LHS, typename RHS>
>> > typename boost::result_of_plus<LHS, RHS>::type
>> > operator +(const LHS &lhs, const RHS &rhs)
>> > {
>> > typename boost::result_of_plus<LHS, RHS>::type nrv(lhs);
>> > nrv += rhs;
>> > return nrv;
>> > }
>
> In my work I implemented something very similar to this - but only for vectors
> with elements of homogeneous dimensions (e.g., a length vector, a velocity
> vector).  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.)

Having only investigated transform matrices, I had hoped that integrity of
quantities can be maintained in most cases. But I havent done extensive 
experiments

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.

[...]

>> The problem is that this is quite a heavy modification to ask of a numeric
>> matrix library, especially when most users will be using it for numeric
> values.
>
> Yes, unfortunately, that's true.  It will make it very hard to integrate any
> dimensional analysis library with any existing matrix library.
>
>> The point of all this is that the price of strong type checking (ie using PQS
>> rather than numerics) may be discarding all your current libraries, which are
>> based on the assumption of numerics. That is quite a high price!.
>
> Again, unfortunately true.  (But not because of bad PQS implementation!
> AFAICS
> the situation would be the same with any strongly-typed dimensional analysis
> 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.

>> I dont know any solution to this problem( except to exit the strong type
>> checking) but basically there it is.
>
> You can exit the strong type checking, or you can pay the performance penalty
> for t3_quantity.  In effect what I ended up doing was both - by putting a
> compile-time switch in my t3_quantity to turn off the dimensional analysis.
> Then I get the best of both worlds - I live with the performance penalty for
> the sake of the dimensions-checking (and enforced documentation of units)
> until
> my formulas are debugged, and then I get the benefit of the speed in my
> production code - all while using a matrix library that doesn't care about any
> of this.  (And BTW, it did find several bugs in my computations by flagging
> dimensions problems!)

That sounds like an interesting useage. 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.

regards
Andy Little