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

From: Deane Yang (deane_yang_at_[hidden])
Date: 2005-10-12 15:56:34

Andy Little wrote:
> "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. :-(

I humbly disagree. He's trying to differentiate between interface and 
implementation, to make it easier to write good code. (As you probably 
recall, I raised this issue before and conceded the issue to you. But I 
think Matt raises good points.)

> 
>> 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....

Not that I'm aware of. Could you elaborate? Given two points, A and B, 
"A+B" makes no geometric sense but "tA + (1-t)B" does. You should think 
of the latter as a primitive geometric operation. The fact that it can 
be written in terms of vector addition is an implementation detail and 
should be hidden from the interface. Allowing "A+B" makes it easier to 
write incorrect formulas involving 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.

If you parse these formulas carefully, you will see that they can always 
be written in terms of the following operations only:

point +/- vector = point
vector +/- vector = vector
vector */ scalar = vector

> 
>> 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. ;-)

No. He's removed addition of points from the interface and hidden it in 
the implementation. I agree with this. This for me makes it easier to 
write good code, not harder, because it protects you from coding 
incorrect formulas involving points.

> 
>> 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?

By using a long and conspicuous name, it signals to the programmer that 
the formula should be checked with extra care, since the compiler cannot 
  verify that only allowable operations are used in the formula.

But I am fairly confident that you will need only barycentric 
combinations and nothing else.