Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-10-10 22:08:34

On Mon, 10 Oct 2005 16:12:53 -0400, Matt Calabrese wrote
> For instance, I have three different main templates for working with
> units
> (instantiated with unit type, value type, an operations policy for
> the provided value type i.e. vector and point operations, all which have
> appropriate defaults):
> quantity (which is a scalar quantity)
> quantity_vector
> quantity_point
> A quick example of why explicitly separating these types is
> important is easily examplified by the common case of temperature.
> Firstly, consider the temperature 2 degrees celsius. In order to
> convert this temperature to fahrenheit, we would multiply by 9/5 and
> then add 32. Applying this operation, we get the result 35.6 degrees
> celsius, as expected. On the other hand, consider a temperature
> difference. Let's say at the beginning of the day, the temperature
> was 8 degrees celsius. At the end of the day, the temperature was 10
> degrees celsius. The change in temperature from the beginning of the
> day to the end of the day is 2 degrees celsius. Now, to convert that
> change in temperature to fahrenheit, we multiply by 9/5. Note that
> unlike the previous example, we do not at 32. This result is
> 3.6degrees fahrenheit, which is obviously very different from
> 35.6 degrees fahrenheit, despite that both come from a conversion of
> 2 degrees celsius.

Wow, that's amazing. Replace quantity_vector with time_duration and
quantity_point with time_point and you have the core concepts behind
date-time. And the 32 versus zero -- seems an awful lot like an epoch_time
adjustment. So I suppose I'm saying I believe there is something fundamental
here :-)
> Aside from everything I mentioned, there are also a few other interesting
> things I'd like to talk about later, though I really wanted to get a
> working implementation uploaded before getting into a big discussion
> about it. I'll try to get expression rearrangement done by the end
> of the week and upload a version for people to play with.

Expression rearrangement is really cool stuff, but it doesn't really impact
the interface does it? If you're serious about putting it in boost it's
really the interface and docs that will ultimately matter the most.
Personally I'd like to see a units lib proposal sooner rather than later...


Boost list run by bdawes at, gregod at, cpdaniel at, john at