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

From: Andy Little (andy_at_[hidden])
Date: 2005-10-12 14:29:30

"Matt Calabrese"  wrote

> I'm not going to make bad code easy to write by allowing points to be added
> with operator +.

You seem to be making good code more difficult to write though. :-(

> Again, this is why in geometry you don't normally define
> addition of points, since on its own it makes no sense.

hmm.... Geometry does define addition of points....

>  In reality it only
> makes sense as an implementation detail of a higher-level operation.

As you confirm here... ;-)

> For
> instance, the rare case you mention.

Addition is pretty common e.g for curves, for piecewise integrals(e.g Simpsons
rule) etc. Physical data is noisy more often then not.

> and that I mention are still very easily
> expressible without the need for operator + to be defined. I suggested
> providing a function such as average( t1, t2, t3, t4, t5, t6 ), which
> internally uses component-wise addition through my componentwise_add
> function (NOT using operator +).

You havent actually removed addition. You've just given it a
non-obvious name. ;-)

> As I said, I will provide this and
> barycentric combination function templates to cover those situations, but
> I'm not going to overload operator + for points, since it isn't a logical
> operation on its own and would just allow for illogical expressions, such as
> just the addition of the temperature at the beginning of the day with the
> temperature at the end of the day.

I dont see how changing the name of the function helps. componentwise_add is an
addition right?

> If I really want to go far, using
> expression templates I could allow addition to compile only if it is a
> direct subexpression of a multiplicative expression containing division, or
> if the expression follows the form of a barycentric combination, but that
> would be going overboard.

For true safety you would need to check the calculation-constants are correct.
OTOH... maybe  I want to accumulate my values  in a container....?
You would need to do the check at runtime in that case.

[cut]

> On 10/11/05, Andy Little  wrote:
>>
> What do you do when two quantities have the same dimensional signature eg
>> torque
>> and energy?
>
> Then the division of one by the other results in a type having
> "empty_classification" (which is the derived classification used by angles,
> etc. as with SI Units).

The term used by the SI is dimensionless.
I believe that  the radian and steradian are described as dimensionless derived
units.

Whatever...You need a means to distinguish dimensionally-equivalent types for
output purposes.

> On 10/11/05, Andy Little  wrote:
>>
> The other area I worked hard at was dimensionless results for which I
>> returned
>> the promoted value_type of the operands. It would have been easy to
>> provide a
>> dimensionless quantity but this too would fail in "rare cases".
>
> I provide a dimension-less quantity called empty_classification, since it
> provides more information and is safer than a raw value.

Ah right. OK .Sorry I should have said "numeric results" rather than
dimensionless
results. A numeric type needs no extra information. Only when you have other
information  (as with angles) will a record of the extra information be
necessary. When there  is no extra information there is no reason not to return
a numeric type.

> I understand why
> one might think it a good idea to result in just the raw value as opposed to
> an encapsulated one, but I don't believe it is the correct decision.

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.

> I.E. Both radians and degrees have an
> empty_classification, yet have different unit types and their values mean
> different things.

Ok.

> If you just result in the raw value as opposed to a
> quantity specifying units, you lose all of the unit information.

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.

> Now that
> you have lost the unit information, using the value in an operation with
> other units of empty_classification would be seemingly ambiguous. For
> instance, I do not believe it is a good idea to allow for
>
> quantity< degrees >( 180. ) + 3.14159

> By your logic, such an expression would have to be allowable.

No... OTOH  ...

quantity<radians>(pi ) + 3.14159 ;

... I would have no problem with.

hmmm.  You could  add angle to the base-units, but then an angle quantity
wouldnt be strictly dimensionless. It would have a dimension of {mass(0),
length(0),.., angle(1)}. In pqs I made various distinctive types of angle
separating them overall into two major types; fractions_of_revolution which
comprised degrees,minutes etc. and  radians.  radians has an implicit conversion
to and from a numeric type whereas the other types needed to be converted to
radians  and then to a numeric type. Previously I was against  adding angle to
the base-units but it might be worth revisting that, though I would try to keep
similar semantics to those I have in pqs currently.

>  However, it
> really should not, since 3.14159, while is of empty_classification, does not
> state which unit type it has. Obviously here it is in radians, which happens
> to be the natural unit type of empty_classification, but you can never be
> sure of this and so shouldn't even always just assume raw values are in
> radians.

In pqs I assume that raw values are numeric.  radians are different its true.

> One of the main purposes of a library like this is to make
> operations more typesafe, whereas what you suggest actually has the opposite
> effect.

To be honest I'm nopt sure what I am meant to have suggested.. :-(

> Another example is forming an angle in radians via a ratio:
>
> circumference_in_meters / radius_in_meters
>
> The resultant expression is a quantity in radians and should have that unit
> information accessible, despite that it is of empty classification.

dimensionless... sure.

> Your
> approach would have it be a raw value without units associated with it which
> just results in a loss in type information.

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

regards
Andy Little