Boost logo

Boost :

From: eford_at_[hidden]
Date: 2001-09-15 12:38:19


> So you are in agreement that the units themselves aren't of great
> importance to the programmer in these settings? Just the
dimensions?

I'm not entirely sure what that means, so I don't want to give a yes
or no answer. I know that I would like to be able to write functions
which take and return quantities with dimensions and units. I want to
specify the dimensions and get compile time errors if they don't
match. I don't want to specify units in the functions. I want the
compiler to do the "right thing".

It sounds to me like there may be several design decisions:

1a. Generate compile time errors for dimension mismatches, perform
automatic unit conversions (e.g. SIunits)
1b. Generate compile time errors for dimension and unit mismatches, no
automatic unit conversions

I like 1a, but see the reasons for both. Would there be a good way to
have one code base and allow the programmer to specify which behavior
they wanted?

2a. Have a fixed set of dimensions (e.g. 7 in SIunits)
2b. Allow users to add their own dimensions

You might be able to provide 2b by having three template arguments for
each dimensioned quantity, a numerator list, denominator list, and a
list of which dimension.

However, allowing users to add their own dimensions seems dangerous to
me. Because some silly user is going to think "I have a distance and
time dimension, but I need a velocity dimension." You might argue
that they shouldn't be using automatic conversions (or even writing
the code), but there are less obvious cases and I can imagine users
creating redundant dimensions and causing problems with checking for
the same dimension.

At the same time, I can see the desire for things like "a teaspoon of
sugar". But I'm not sure that it's a good idea to think of the
ingredient as a dimension or unit. I wonder if you could combine one
library with choices 1a, 2a and another with choices 1b, 2b in series
to that effect. So I'd say something like
  typedef enum { sugar = 100, flour = 101 } ingredients;
  typedef unit_unconvertible<teaspoon, ingredients::sugar>
teaspoon_of_sugar;
  typedef unit_unconvertible<tablespoon, ingredients::sugar>
tablespoon_of_sugar;
  typedef unit_unconvertible<cup, ingredients::flour> cup_of_flour;

Then conversions between different "of sugar" units would be
automatic, but conversions between any unit of sugar and any unit of
flour would generate compile time errors.

3a. Have a fixed set of conversions (e.g. SIunits)
3b. Allow conversions that are dynamically specified at runtime (e.g.
currencies)

I think for scientific users, 3a is the only reasonable choice.
However I'd guess that for financial users, 3b is the only reasonable
choice. Is it possible/reasonable to have one code base that deals
with both efficiently? That might could be done with a trait type
parameters, but it also might get messy. Maybe multiple separate
libraries (e.g. SIunits-like, unit_unconvertible-like, currency-like)
are in order. In that case, we'd want to make sure they can interface
with each other (e.g. dollars per pound and euros per kilogram).

E


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