From: Jeff Garland (jeff_at_[hidden])
Date: 2003-10-17 08:37:25
On Thu, 16 Oct 2003 18:42:16 -0400, Deane Yang wrote
> Temperature is an example of what I would call an "affine" dimension
> and not a "linear" one, which is what we've been focusing on so far.
>
> When we think of grams, meters, or seconds, we are thinking of relative
> measurements, namely the difference between two absolute
> measurements. So there is a natural meaning for 0 and the
> measurement lives naturally in a vector space. So, as a measurement
> of the difference between two temperatures, both °C (= °K) and °F
> make perfect sense as linear units.
>
> If you want, however, to represent absolute temperatures in Kelvin,
> Centigrade, or Fahrenheit, I would say that you need to define the
> notion of an affine dimension. An affine dimension corresponds to
> a 1-dimensional affine space, where there is no natural origin but
> given any two points in the space, there is a natural vector
> associated with the two points (the difference between the two
> points).
>
> So you would never add two affine measurements nor would you ever
> multiply or divide affine dimensions by anything else. You would
> only subtract two affine measurements, resulting in a linear measurement
> (to which you can then do lots of things). (A standard example of an
> affine dimension is a pointer, and the corresponding
> linear dimension is the difference of two pointers.)
>
> This also arises in time, where calendar dates as defining an affine
> dimension and the difference between two dates to be the standard linear
> time dimension. You would almost never multiply a date by two (nor
> would you normally ever multiply a pointer address by two, but never
> say never), but you might want to multiply the difference between
> two dates by two (or multiply the difference of two pointers by two).
Interesting that you point this out, as it is a foundational concept for the
date_time library that time systems have 2 distinct types: the 'point in time'
and the 'time duration'. The definition of all valid calculation flows from
this concept. That is:
Timepoint + Duration --> Timepoint
Duration + Duration --> Duration
Timepoint + Timepoint --> Not Allowed
Timepoint - Timepoint --> Duration
More at http://www.boost.org/libs/date_time/doc/Calculations.html
>From what I've seen of units libraries they tended to only represent durations
and not time points. So they basically side-step this issue.
Jeff