
Boost : 
From: Matt Calabrese (rivorus_at_[hidden])
Date: 20051013 01:57:03
I went to bed but couldn't sleep as I believe I made a mistake here.
Not regarding decibels, etc. but regarding the relationship between
degrees and degrees^2. After more thinking about it, I believe that
while they should share the same classification, as one would notice
from dimension analysis, conversion between them should not be defined
at all, even for points. I foolishly stated that the relationship
should be exponential without fully thinking it through. So,
basically, the result would be a unit type of the same classification
with no way to convert to many other units of the same classification.
On 10/13/05, Matt Calabrese <rivorus_at_[hidden]> wrote:
> > 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 builtin types and there really
> shouldn't be any oddities to learn. types with an empty classification
> still
> have units associated with them, whereas builtin types do not. As well, if
> I were to go the route of making them builtin 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
> builtin 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 welldefined 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
>
>
 Matt Calabrese
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk