Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-02-14 13:49:26


Hi Steven,

I've been thinking about extensions to the units library,
particularly ways of simplifying the use of
heterogeneous unit systems (units that are from mixed systems). For
example, if a user wanted
to define a unit for tracking FLOPs, it is reasonable that they might
want to use units like

FLOPs/second

or

FLOPs/(second*dollar)

As it stands now, the user would have to add tags to, say, the SI
system for FLOPs and for dollars.
What I'm thinking would be nice is to decorate the dim<T,V>::tag_type
so that it carries the
system with it. Then your units could be composed of any set of
fundamental units. The challenges
I can see are:

1) how to ensure that list of these dims are sortable; you would
presumably sort on system first, then
on tag:

let's call

SI::system -> si
CGS::system -> cgs
length_type -> L
mass_type -> M
static_rational<N1,D1> -> r1
static_rational<N2,D2> -> r2
etc...

then we would have

mpl::list< dim< tag<si,L>,r1>,
                 dim< tag<cgs,M>,r2>,
                 dim< tag<si,T>,r3>,
                 dim< tag<cgs,M>,r4> >::type

getting sorted as two separate reduced dimension lists, with si first
(specific order not important), then
cgs. This would make constructs like

(centimeter/kilogram)*meter*gram

make sense. Clearly, they wouldn't auomatically reduce to one unit
system, but I think it should be
possible for the explicit constructor to check that every element in
the list is convertible to the desired
unit system, so

quantity<SI::area> a(1.5*centimeter/kilogram*meter*gram);

would actually work.

2) the process of determining if a unit belongs to a system gets a
little more complicated (not too bad,
though).

I have a couple of questions for you:

any ideas on how to make tags sortable without requiring them to be
specifically enumerated?

this would probably up the compile-time demands. how much slower
would this make compilation?

Thanks,

Matthias


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk