Boost logo

Boost :

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-10-15 12:53:09


Yeah, you're right. I think I just got caught up trying to remove special
cases and have a more general abstraction without fully thinking it through.
I see that this was a mistake, now. The result is no longer radians, it's
just an encapsulated ratio (encapsulated because all expressions are
encapsulated, since they are represented as expression templates, and so
that way operator usage is still performed through the provided policies).
Conversion to the raw value is implicit, so you can use the result of such
expressions intuitively.

However, I would like some input on my talk of decibels, only now removing
my foolish talk of radians with "untransformed ratios" (encapsulated raw
numbers which when multiplied together result in another "untransformed
ratio" just like "regular" numbers operations result in more "regular"
numbers). I'm unsure if you were confused by my explanation of the
relationship of decibels to regular numbers and how point decibels are
convertible to regular number points yet not vectors and scalars, so I hope
this clarifies, and I would appreciate some feedback. To explain this better
I'll try to give some more examples relating bels to untransformed ratios.

Firstly, think of bel points and points without no units (untransformed
ratio units). Bels are just ratios represented with a base 10 logarithmic
scale, so concerning point space, these would be the relationships (bels are
approximated):

Ratio: 1
=
Bel: 0

Ratio: 2
=
Bel: 0.301

Ratio: 3
=
Bel: 0.477

Ratio: 4
=
Bel: 0.602

Ratio: 5
=
Bel: 0.699

...

Ratio: 10
=
Bel: 1

... etc.

I'm sure you understand the above, but it is provided for clarity and a
point of reference. Note that while the space between a ratio (encapsulated
raw number) increases by the number 1 in each grouping, the value in bels
increases more slowly the further away from 0 you get. You can convert a
point ratio to a point bel no problem, since the mapping is done by just
applying base 10 logarithm to the ratio.

However, this relationship cannot be use with vectors and scalars! In other
words, a bel vector can not be converted to a "ratio" vector (raw vector)
and a bel scalar can not be converted to a regular scalar. This is because
how a ratio vector or magnitude relates to a bel vector or magnitude depends
on "where" in point space those quantities lie. Since vectors and scalars
have no spacial location, the conversion is impossible.

Firstly, say you have two bel vectors with a value of 1 and a bel vector
with a value of 2.

If you were to assume that bel vectors were convertible to ratios, you would
think that you could convert those bel vectors with value 1 to ratios, add
them together, then convert them back to bels to have a value of 2. As I
said, the conversion wouldn't exist, but I'll follow through with the
operation to show the results:

1 bel = 10
10 + 10 = 20
20 = 1.301 bels

1.301 bels != 2 bels

Again, this is the case because what a translation of "1 bel" or magnitude
of "1 bel" is as a raw number changes depending on spacial location, which
vectors and scalars don't have. In actuality, converting a bel vector to a
raw number vector isn't possible, even though you can convert a bel point to
a raw point! This also means that given two vectors, one of bels and one as
an untransformed ratio, you can't add the two together, since conversion
from one to the other is impossible.

Now, what about adding a raw point with a bel vector? The operation can be
done and makes logical sense. Rather than converting the bel vector to a raw
vector, which is impossible, you have to convert the raw point to a bel
point. Now the operation can be performed and results in a bel point. This
bel point can also be converted back to a raw point if needed.

This relationship is the same for nepers and the richter scale, etc. making
it perfectly fine to have such unit types in an environment as other units,
given proper use of points, vectors, and scalars.

--
-Matt Calabrese

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk