Boost :

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