"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