Re: [boost] [review] pqs - defining own units

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

"Janek Kozicki" wrote
> So with above citation to bring the context, the problem is that it's
> not easy to add new unit types. After short private correspondence with
> Andy I think there is a solution for that.
>
> Instead of modifying the source code of the library, just add there
> following macro (macro name can be different of course):
>
> #define BOOST_UNITS_DIVIDED(numerator,denominator,new_type) \
> typedef /*typename */ pqs::meta::binary_operation< \
>  numerator, \
>  pqs::meta::divides, \
>  denominator \
>  >::type new_type \
>
> (this macro works in boost 1.33 - without boost::typeof. A similar macro
> can be written to utilize boost::typof. Of course a second macro
> BOOST_UNITS_MULTIPLIED would be needed as well)
>
> This macro allows to define custom units with small trouble - just write
> the unit components. Taking example from my review - I had problems with
> a unit N/m (spring stiffness). With above macro I just write one line:
>
>   BOOST_UNITS_DIVIDED(pqs::force::N,pqs::length::m,N_div_m);
>
> and now I have a new type named N_div_m and I can use it as desired.

Hopefully boost 1.34 will be released soon. Then Boost.Typeof will provide a
generic solution to this problem rather than requiring a macro for each
expression, Boost.Typeof can handle expressions of arbitrary complexity directly
and IMO will be found to be extremely useful both inside and outside PQS
library. IMO the fastest way to get full language support for decltype and
auto(see below links): is to show how useful Boost.Typeof is and use it, use it,
use it in preference to other type deduction schemes

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1478.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1527.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1705.pdf

> With this mechanism maybe the amount of predefined units can be reduced
> - maybe even only to one unit per dimension and no mixed units at all?

I think there is a case for providing what I would call different 'views'. I
have concentrated on one 'view' in which the units are explicitly spelt out.
that is the one dealing with named-quantities, typedefs for particular units (
pqs::length::m) , etc, etc. This is helpful when unit conversions are needed.

However,  (though I havent looked in real detail at yade  yet)

http://yade.berlios.de/

from the current brief look I have had so far it occurs that  for this type of
use a different view, created by just typedefing quantities for their names
(length, time, force etc) in implied base units, would be more suitable.( In
yade  I think the unit conversion capability is irrelevant ?). This type of use
would also facilitate being able to switch PQS library in for dimensional
analysis checking and then switch the library back to floating point types for
max performance of the release version. In this case use of other than base
units wouldnt be suitable, though even here unit conversions could be achieved
( maybe via the alternate syntax favoured by Walter Browns SI Units and Jesper
Schmidt),  if necessary.

regards
Andy Little