![]() |
Boost : |
From: Andy Little (andy_at_[hidden])
Date: 2006-08-20 04:42:00
"Janek Kozicki" <janek_listy_at_[hidden]> wrote in message
news:20060819212430.739b0920_at_absurd...
> Andy Little said: (by the date of Sat, 19 Aug 2006 13:03:42 +0100)
>
>> In fact there is a 2D and 3d vector in quan so you can do:
>>
>> quan::some_vect< quan::length:: m > position_a, position_b;
>>
>> quan::length:: m distance_a_to_b = magnitude(position_b - position_a);
>>
>> Because of that useage It might get confusing.
>
> I still hold my position that linear algerbra library should not be a
> part of _two_ separate libraries: Dimensions and Units.
FWIW I brought this up only in relation to magnitude. That said, I have found
that being able to write code like the above is a lot of fun, much more so than
if I was using doubles to represent lengths. However suddenly you are
restricted in what you can do. For example:
double var1= 10; // var1 meters
double var2 = 10 ; // var2 represents meters.
var1 *= var2 ; // var1 now represents an area in square meters.
Of course you cant do this with a fixed_quantity:
quan::length::m var1(10);
quan::length::m var2(10);
var1 *= var2 ; // Error
I would guess that is an unacceptable restriction for many authors of algebra
libraries.
As far as I am concerned though I am more interested to see what happens if I do
play by the rules that are imposed by having strongly typed quantities, but it
is kind of difficult to ask everyone to play by these rules, so I am happy to
create vector types myself, that work with Quan.
Maybe, if we can get Quan into Boost then we will be in a stronger position and
there may then be interest in creating a linear generic algebra library for
physical quantities, but I suspect that due to the above kind of issues, there
will always be a great divide between a 'raw' linear algebra library and one
that is designed to work with physical quantities.
> Although Dave did not answer about details of his linear algebra library
> I agree with him that correctly written units+dimensions libraries
> should work with any other library - eg. small vectors (liear algebra),
> quaternions, octonions, matrices, etc...
It is difficult to define 'correctly written'.... ;-)
> Specifically it should work with any other part of boost.
>
> If it wouldn't then the user of units library would be only limited to
> this linear algebra which is bundled with it.
>From the work I have done so far it isnt that hard to make something that would
work for other quantities libraries, and in fact the main problem is agreeing on
a common result_type deduction scheme. Ideally one could use Boost.Typeof raw,
but unfortunately gcc chokes on this type of declaration:
template <typename Lhs, typename Rhs>
BOOST_TYPEOF_TPL(Lhs() * Rhs()) operator * ( Lhs lhs, Rhs rhs);
Meanwhile, in practise it is not too difficult to write some glue code for
interfacing with the other result_type deduction schemes such as Boost.Lambda
and so on.
regards
Andy Little
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk