Boost logo

Boost :

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


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