Boost logo

Boost :

From: Deane Yang (deane_yang_at_[hidden])
Date: 2004-01-09 14:44:39


Phil Richards wrote:

> On Fri, 09 Jan 2004 08:38:14 -0700, Matthias Schabel wrote:
>
>>struct unit_info<Fahrenheit>
>>{
>> template<class Y> Y toBase(Y val) { return ((val-32)*(5./9.)); }
>> template<class Y> Y fromBase(Y val) { return (val*(9./5.)+32); }
>>};
>
>
> Hmmm. Not sure about that. There is an implicit assumption there that all
> quantities represented are "absolute" - that is wrong since it would
> require that either "fahrenheit(32) + fahrenheit(32) == fahrenheit(32)" or
> that such operations are not permitted. Neither option is correct.
>
This is a good point that I was hoping would not arise in the current
discussion, because it raises an extra difficulty in the units library.

Early on, I observed that there are two different types of units,
I like to call them affine units and linear units, because I am a
mathematician. They could also be called absolute units and relative
units. Temperature is a good example. When you say the temperature of
a room is 70 degrees Fahrenheit, you are using an absolute unit.
When you say that the temperature of a room is 10 degrees Fahrenheit
higher than the outdoor temperature, you are using a relative unit.
Absolute and relative units behave in fundamentally different ways
and therefore need to be treated separately in a units library.

So far we have focused on and I would recommend that we continue to
focus only on relative units. So the current proposed units libraries
would handle only the notion of "temperature differences" and not
"temperatures" themselves. Note that the arithmetic operations allowed
are different. It's analogous to iterators and differences between
iterators. It makes sense to double the distance between two iterators
but it almost never makes sense to double an iterator itself.

Once a good relative units library is built, building an associated
absolute units library (that would handle temperature) is quite easy.


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