From: Andy Little (andy_at_[hidden])
Date: 2004-07-06 19:22:53
"edA-qa" <edA-qa_at_[hidden]> wrote
> A few questions about your library:
> -How does one represent non-whole dimensions (such as m^1/2)?
Firstly do note that this is an experimental library and as such things are
changing from pqs-1-01-04- the version you have
This affects the way new types are declared. The info here relates to
(I hope to get the new version out within the month. but it is not entirely
Note too that the documentation on the site is newer and better than that
included in the zip.
So its worth looking at that in preference.
for the particular case of m^1/2. You could declare it like this:
abstract_identity< // name changing in pqs-2-00-01
abstract_pq< // name changing in pqs-200-01
length_pwr<1,2> //means dimension of length^1/2
> meters_pwr0pt5; // whatever typedef name you require
meters_pwr0pt5 x(100); // ready to use.
q_length::m len = x * x;
len = power<2>(x); // as above
x = power<1,2>(len); // means to power 1/2
As it happens the length^1/2 is the easiest because many parameters default.
The full blown template looks like this in pqs-1-01-04
double, // whatever value_type
length_pwr<2,1>, // the exp of dimension of each base unit
auxiliary_tag<0> // can have different quantities of same
coherent_exponent<3>, // eg 3 for km
incoherent_multiplier<0> // 0 for coherent-quantity in
// for pqs 2-00-01 the incoherent multiplier template parameter mechanism
// is changing too
// pqs 2-00-01 adds another tag here too
However as you appreciate declaring things this way is a daunting task, and
there are better ways, which leads neatly to your next question...
> -How do I add new dimensions (different types)?
I need to write the proper docs for this AND things are changing in the new
version. So rather than explain this here I better get on with that part of
the docs. I havent been happy with the the way things are handled as regards
defining new types but have improved matters radically in pqs-2-00-01.
> -Will it work with non-fundamental/user-defined types, such as complex?
Yes. For complex check in "pqs/complex/q_complex.hpp".
Some examples and tests in "examples/complex_example.cpp".
It only does the basic operations though, merely because of time reasons.
Another thing to do.
There is also some support of boost::numeric::interval. Example in
I am working to make value_types yet more generic in the next version too.
> -Is it possible to automatically determine the type of a calculation?
> That is, I want to declare q as the type of whatever a * b / c is?
Yes look here:
which explains this. (binary_operation can be nested for more complex calcs)
Note however that only anonymous-quantities can be declared (simply)this
And as to what they are, again I need to write this up, but basically they
are useful for temporaries in calculations
> It seems like a really functional library, accomplishing its task at
> compile time (what I had hoped for in my code). Though it seems
> extremely bulky and takes a while to compile.
On the compile time issue. I agree absolutely, Its a pain. Compile times can
be reduced somewhat by only including the headers from pqs/types for the
particular quantities you want. (use the q_xxx_out.hpp versions if you
require stream output.) On the bulkiness of the library. I am trying to
address the issue with some success in pqs-2-00-01. Unfortunately there is a
potentially infinite number of physical quantities. Much of the bulk is due
> > This is doable in my library at the above link.
> > (However problems would start to arise if you need prefixed or
> By doable, what do you mean? It is vitally important to my project that
> all this typing is turned off to allow the compiler to get a high-level
> of optimization.
Its doable If you dont require unit conversions, that is all lengths in
meters, times in seconds etcetera. without prefixes.
In that case merely create a header with a facsimile of the particular
containers required. replacing the ct-quantity decl with a (say) double.
e.g for length:
typedef double m;
typedef double s;
and you have the desired effect:
q_length::m // is now just a double
Of course if you do unit conversions from (say) meters to millimetres, you
will get invalid results with this approach. Again this is doable by using a
hybrid approach and doing all the conversions manually, but things do start
to get ugly. However if you have an optimising compiler then I hope that
(this and )the next version of pqs will give quite good results while
leaving the checks in place. There is a lot of room for optimisation, but at
this stage I am concentrating on the basics. And Yes I need to get on with
the Docs too !
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk