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.