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