Boost logo

Boost :

From: Darryl Green (green_at_[hidden])
Date: 2001-06-28 21:08:21

fwiw decibels are a unitless ratio (like percent) but
expressed using a logarithmic scale. There are derived
units like dBm (decibels with respect to 1 milliwatt)
which are essentially linear units with a log scale.
I'm not sure if scale is the right word for what I'm
trying to describe, or how this relates to pH, although
I expect it is a bit like dBm.

-----Original Message-----
From: Deane_Yang_at_[hidden] [mailto:Deane_Yang_at_[hidden]]
Sent: Friday, 29 June 2001 3:23 AM
To: boost_at_[hidden]
Subject: [boost] Re: Units (and operators.hpp, too)

I've been reading and learning a lot from the boost list.
Although my experience with C++ is much less than everyone
else here, I have implemented template base classes representing
units very successfully. I have found these classes to be
extraordinarily useful in catching errors in formulas coded in C++.

Although the discussions I've seen seem to be converging to what
I consider to be the "correct" view, I thought I'd try to describe
how I see things.

1) There are basically two types of units

First, I have found that units come in two different types.
I used to call one "absolute units" and the other "relative units".
I now call them "affine units" and "linear units", because the former
corresponds to a 1-dimensional affine space, while the latter
corresponds to a 1-dimensional linear space.

Linear units are familiar to everyone. For example, any physical unit
like meters, seconds, ergs, etc. is linear. You can add, subtract, or
rescale any quantity that has linear units. In other words, a
quantity in linear units is simply an element of
a 1-dimensional vector space).

A quantity in affine units corresponds to an element of a 1-
dimensional affine space. An affine space is like a vector space
without an origin. You can't add or rescale an affine object.
There is, however, a vector space naturally associated with an affine
space. Given two affine objects, you can subtract them and get a
corresponding linear quantity.

Let me illustrate with one very useful example. The set of all
possible calendar dates is an affine space. It does not make sense to
add or rescale a date. It does, however, make sense to subtract two
of them and get a quantity in days, which is a linear quantity.

The other example was given by Dave: an iterator is an affine object,
while the difference of two iterators is a linear quantity.

By writing code that uses classes to represent unit and that
distinguishes between affine and linear units,
my compiler now catches virtually every error I make when coding
a formula in C++.

I see implementations of affine units in various specific cases,
like iterators, but I think it's worth identifying the common
abstract notion that guides all of them.

2) It is important to identify "unitless" quantities

It is obvious that the ratio of two quantities with the same units
must be unitless. What is not always so obvious is that some "units"
are really unitless quanities. The two I know about are percentage
(which is obviously a ratio) and radians.

And then there are quantities that seem unitless but are not.
The simplest example is an interest rate, which is always
stated as a percentage. To see what it really is, you just
ask yourself how it's used in a formula. The first thing you
always do is multiply the interest rate by a time and get a
ratio (interest/principal). So the units
of an interest rate are always given by 1/(time unit).

3) Transcendental functions

Any standard transcendental function, such as sin, cos, exp, log,
MUST take only unitless quantities and return unitless quantities.
If not, there is an error in the formula. You can sort of see why by
observing that these functions are computed using a Taylor series
with unitless coefficients and there is no way to have every term in
the series have the same units unless the argument is unitless.

There are logarithmic units such as decibels and pH. I'm not familiar
with how these are used in formulas. I think these are sufficiently
strange so that they should be treated specially.


--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> Helmut,
> What you're saying makes sense, but I think we need to be careful. A
> conforming compiler will generate these functions even if unused,
so it
> could break code.
> Actually, I thought of a pretty strong counterexample: take a look
> random_access_iterator_helper. It makes sense to subtract the
distance type
> from the iterator type. Does it make sense to convert the distance
type to
> the iterator type? I don't think so.
> So, I think we'd better stay with what we've got, or at most, add an
> additional operator template.
> -Dave
> ----- Original Message -----
> From: <helmut.zeisel_at_a...>
> To: <boost_at_y...>
> Sent: Thursday, June 28, 2001 10:21 AM
> Subject: [boost] operators.hpp issue
> > In operators.hpp,
> > the commutative two-type versions of the operators,
> > such as addable2 have both versions of the operators defined:
> >
> > struct addable2 : B
> > {
> > friend T operator+(T x, const U& y) { return x += y; }
> > friend T operator+(const U& y, T x) { return x += y; }
> > };
> >
> > the non-commutative versions, such as subtractable2
> >
> > have only one version:
> >
> > struct subtractable2 : B
> > {
> > friend T operator-(T x, const U& y) { return x -= y; }
> > };
> >
> > Shouldn't there be a second version such as
> >
> > friend T operator-(const U& x, const T& y)
> >
> > T x1(x);
> > return x1 -= y;
> > }
> >
> > IMHO, it does not make much sense to provide the
> > two-type versions of the operators when U is not convertible to T.
> >
> > Helmut
> >
> >
> >
> >
> >
> > Info: Unsubscribe:
> <mailto:boost-unsubscribe_at_y...>
> >
> > Your use of Yahoo! Groups is subject to
> >
> >

Info: Unsubscribe:

Your use of Yahoo! Groups is subject to

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