Re: [boost] Interest in dimension/unit-checking library?

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-13 01:02:35

> On 10/12/05, Andy Little <andy_at_[hidden]> wrote:

Well the decision to use numeric types where possible as opposed to a
> dimensionless udt works fine in pqs. I have no reason to believe it was
> the
> wrong decision. It
> makes the library directly compatible with inbuilt types. Its easy to use
> and
> there are no oddities to learn.

 The library still is compatible with built-in types and there really
shouldn't be any oddities to learn. types with an empty classification still
have units associated with them, whereas built-in types do not. As well, if
I were to go the route of making them built-in types, then they would have
to all be of one unit type and would not be easily useable in expression
templates (since just a raw add without explicit encapsulation would use the
built-in operator + or the overloaded operator + for that type).

> On 10/12/05, Andy Little <andy_at_[hidden]> wrote:

Well numeric types by nature dont have any unit information. I guess you
> could
> add scalinfg of eg *10^3 etc, but really all you are doing is creating an
> extended
> floating point type.

 When you form a value from division of two quantities, it has units with an
empty classification. Like the example I gave above, division of a circle's
circumference by its radius gives you a result in radians, which is a unit
which has an empty classification (such as with SI units). An empty
classification is not the same as a lack of units. Resulting in a raw value
needlessly gets rid of this abstraction.

> On 10/12/05, Andy Little <andy_at_[hidden]> wrote:
> No... OTOH ...
>
> quantity<radians>(pi ) + 3.14159 ;
>
> ... I would have no problem with.

 That's because the number is in radians. Basically what you're saying is
"assume all raw values are quantities in radians", which is not a valid
assumption. As well, what type of quantity is 3.14159? Is it a scalar
quantity or a vector quantity or a point quantity? If it is a vector
quantity or a point quantity then that operation should not be allowable,
since you can't add a scalar to a vector or point. Unfortunately, since you
suggest to allow raw values, you lose this abstraction. The fact of the
matter is, you creating ambiguity but then arbitrarily allowing certain
operations.

On 10/12/05, Andy Little <andy_at_[hidden]> wrote:
> In pqs I assume that raw values are numeric. radians are different its
> true.

 Then why did you state above that the radian value should be allowed to be
added with the numeric? A quantity with units plus a raw numeric shouldn't
make sense, even with radians.

 On 10/12/05, Andy Little <andy_at_[hidden]> wrote:

Thats fine if there is no requirement for 'type information', which is the
> case
> with numeric types.

 My argument is that what you call numeric types aren't always simply
numeric types. Division of similar quantities result in a quantity with an
empty classification but which has unique units, such as with radians.
 Completely separately, I do see an orthogonal problem. How should we handle
multiplication of two quantities of empty classification. For instance,
degrees * degrees should result in degrees^2, just like meters * meters
results in meters^2. This concept does make sense, however, squaring a
quantity which has an empty classification would result in another quantity
having an empty classification (0^2 equals 0). So, we run into the odd case
that degrees and degrees^2 have the same classification.
 At the moment I am not sure it is correct, however I do have some theories
about the concept. Continuing with the case of degrees, I believe that
degrees and degrees^2 should have the same classification, however
considering scalars and vectors, conversion between those two types should
be disallowed. Surprisingly, the conversion should be allowable for points.
I haven't written the following logic in words yet, so bare with me. I'll do
the best I can.
 At first this may seem strange, but it is based on a theory that I have
been thinking about concerning support for units such as decibels or the
richter scale. The concept is that while the two units, such as degrees and
degrees^2, have the same classification, conversion between the two spaces
is not defined by an affine transformation, but rather something more
complex. In such a case, vectors in one space could be added with vectors
the same space, however conversion from a vector in one space to vectors in
the other space is not defined. This concept sounds odd, but I currently
believe it is correct.
 I'll switch to decibels for a moment, since the situation is easier to
create a common case for. Decibels are related to other units of the same
classification logarithmically. This classification happens to be an empty
classification -- the same as radians and degrees. What this means is that
If you were to take "decibel" space and compare it to the natural space of
radians and degrees, the distance between 0 and 1 in decibel space would not
be the same magnitude in natural space as the distance between 1 and 2 in
decibel space. Depending on where you are in decibel space changes
magnitudes of vectors when looked at from natural space. For instance, a 2
decibel vector + a 3 decibel vector is a perfectly fine operation resulting
in a 5 decibel vector, however, a vector quantity of 5 decibels + a vector
quantity of 5 radians can't be performed, since the magnitude of "5
decibels" changes in radian space depending on where in that space you are.
Since vectors on their own have no spacial location, the operation makes no
sense. However, points do have a well-defined location in their space, and
conversion from spaces such as radians to decibels is actually defined, just
not through a simple scale change and phase shift. Instead, it is a
logarithmic relationship.
 Because of this, you can convert from radian points to decibel points. This
makes sense since decibels describe a ratio, which radians are, through a
logarithmic scale. Unlike with two vectors from different spaces, you can
even add a radian point with a decibel vector, since the radian point can be
converted to a decibel and then added to the decibel vector! This type of
odd relationship actually makes mathematical sense, and in my opinion, is
necessary for representing concepts such as decibels, or the richter scale,
or nepers.
 As with the above example, I believe the same type of concept exists for
degrees and degrees^2, with an exponential relationship. The benefits of
this are that we properly represent degrees and degrees^2 as both having an
empty derived classification, yet, just as intuitively, you can't add a
degree with a degrees^2 vector, though their points are convertible to each
other. This is a concept which is difficult to understand, though that I
believe is entirely correct. Thankfully, average users wouldn't be affected
anyway.
 Again, this is all just theoretical stuff that I have been thinking about,
and is currently the best model that I have come up with and seems to handle
all cases that I throw at it. Because of this, I have no outside sources to
provide and backup my theory, so hopefully all of the above logic makes
sense. I'd appreciate it if people could provide some criticisms,
particularly mathematicians, and if possible, provide other solutions if my
theories are flawed. These situations definately must be handled prior to
release, otherwise common units such as decibels or nepers can't be
represented, and the concepts of degrees^2 or other similar units would
remain unhandled.

--
-Matt Calabrese