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@gmail.com> wrote:
On 10/12/05, Andy Little <andy@servocomm.freeserve.co.uk> 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@servocomm.freeserve.co.uk> 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@servocomm.freeserve.co.uk> 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@servocomm.freeserve.co.uk> 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@servocomm.freeserve.co.uk> 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
-- -Matt Calabrese