Re: [boost] mcs::units informal review request

From: Ben FrantzDale (benfrantzdale_at_[hidden])
Date: 2007-01-17 09:56:27

On 1/16/07, Matthias Schabel <boost_at_[hidden] > wrote:
>
>  ...

> My humble knowledge may have confused me but I thought that the same
> > temperature by Centigrade and by Kelvin will always differ by about
> > 273 (i.e. the conversion is linear). Which is not right in case of
> > Farenheit.
>
> What I mean by linear vs. affine is that, while the scale factor for
> converting
> temperature differences in Kelvin to/from centigrade is one, there is
> a nonzero
> translation of the origin (MathWorld has a good description of linear
> and affine
> transformations):
>
> http://mathworld.wolfram.com/LinearTransformation.html
> http://mathworld.wolfram.com/AffineTransformation.html
>
> The point that Ben was making in his post is that, while absolute
> temperature
> conversion between Kelvin and centigrade requires an offset,
> conversion of
> temperature differences does not. As far as I can tell, to integrate
> this directly
> into the library would require strong coupling between a special
> value_type
> flagging whether a quantity was an absolute temperature or a
> difference, which
> I think is undesirable. By defining special value_types
>
> class absolute_temperature;
> class temperature_difference;
>
> and defining the operators between these so that you can add or subtract
> temperature_differences to/from absolute_temperatures to get another
> absolute_temperature, add or subtract two temperature_differences to get
> another temperature difference, and subtract two
> absolute_temperatures to
> get a temperature_difference you should be able to get the correct
> behavior.
> Maybe I'll try to put together a quick example of this...
>

I do think it would be great to distinguish between affine and vector spaces
in a library like this, but in practical terms it seems like there are three
levels of commitment that users might have to dimensional analysis:
1. Type of dimension (length versus temperature).
2. Units of measure (meters versus feet).
3. Absolute versus relative quantities (°C = K+273.15 versus °C = K).

It seems to me that these are separate problems, each building upon the one
before it, and that an ideal library would let the user work at any of these
levels. I think 1 and 2 can be handled with appropriate dimensional types
and casts among them; 3 can be handled by separate types for absolute and
relative quantities. I think these could be implemented independently in
that order.

I'm thinking usage like this:
  // First: type of dimension
  quantity<double, distance> x1 = 42.0 * distance;

  // Second: units of measure
  quantity<double, meters> x2 = 20.0 * meters;

  // Casting to explicitly add units of measure to unitless quantities.
  x2 = quantity_cast<quantity<double, meters> >(x1); // The user claims x1
is in meters.
  // Allow casting a reference or pointer, too (important for interfacing
with numerical solvers).
  quantity<double, meters>& xref = quantity_cast<quantity<double,
meters>&>(x1);
  quantity<double, meters>* xptr = quantity_cast<quantity<double,
meters>*>(x1);

  // Third, since most people won't want to get into this, let quantity be
what
  // most would expect (i.e., a linear space) but add absolute_ and
relative_ to be clear.
  absolute_quantity<double, temperature> t1 = 1000.0 * temperature; //
Unspecified temperature type.
  absolute_quantity<double, temperature> t2 = 1010.0 * temperature;

  relative_quantity<double, temperature> tdiff = t2 - t1; // tdiff is now 10
temperature units.

  quantity<double, kelvin> t3 = 1020.0 * kelvin; // General kelvin quantity.
  relative_quantity<double, kelvin> t3rel =
       quantity_cast<relative_quantity<double, kelvin> >(t3); // Explicitly
say it's relative.
  // So now t3rel is 1020.0 K
  absolute_quantity<double, celsius> t3C =
       quantity_cast<absolute_quantity<double, celsius> >(t3); // Explicitly
say it's absolute.
  // Now t3C is 746.85°C.
  t3C /= 2.0; // Specialize absolute temperatures to have scalar
multiplication.
  // Now t3C is 236.85°C = (1 020.0K/2)

  absolute_quantity<double, seconds> t = 10.0 * seconds;
  // t2 *= 2.0; // This shouldn't compile because absolute time doesn't have
scalar multiplication.

—Ben

PS
Temperature is particularly odd in that absolute temperature it is (almost)
a linear space even though temperature differences are in a different linear
space. That is,
   0°C × 2 = 273.15K × 2 = 546.3K = 273.15°C.
(I say "almost" because there's no negative absolute temperature, so it
can't really be a linear space.)

PPS
Where can I find the code under discussion?