
Boost : 
From: Jeff Garland (jeff_at_[hidden])
Date: 20031017 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 1dimensional 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 sidestep this issue.
Jeff
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk