
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Valentin Samko Sent: Saturday, November 06, 2004 6:26 PM To: Noah Stein Subject: Re[4]: [boost] Re: Re: GUI Library Proposal for a Proposal
That is very true if we consider an abstract point, but in that case, operation pointA-pointB is undefined, just like pointA+pointB. Do you have any examples of any classical spaces, where pointA-pointB is defined, but pointA+pointB is not?
I can only point you again to the PDF entitled "The Ambient Spaces of Computer Graphics and Geometric Modeling". It has a discussion of various coordinate spaces in which the difference between points and vectors are clearly discussed: http://ibm.tju.edu.cn/resource/ComputerGraphicsApplication/ComputerGraphicsA pplication/2000/g2/g2076.pdf Whether these spaces are "classical" mathematically or not is largely irrelevant. What is relevant is that these are the coordinate spaces used throughout the computer graphics literature.
This makes them almost the same thing. You can treat vector as a point, and point as a vector. Besides, we are talking about R^2, which is a vector space.
Sure, there's an isomorphism between points and vectors; however, that doesn't make them the same. There's an isomorphism between the functions f(x)=x and f(x)=2x; however, that does not make those two equations the same. R^2 or R^3 is irrelevant. The concepts that underlie coordinate space usage in 3D hierarchies are just as valid, if less commonplace, in 2D. OpenGL's modelview matrix stack is an analog of Postscript's transformation stack.
Do you really care about non Euclidean spaces, considering a GUI library? :)
Maybe if we all just cared a little bit more about non-Euclidean spaces, this world would be a better place? :)
Everything I said in this thread is only related to R^n spaces. I think it is pointless to consider anything else for a GUI library. Also, if we only consider a vector space R^n, are you saying that a point in a vector space R^n is not actually a vector?
Yes, I'm fully saying that a point in R^2 is not a vector in R^2. Vectors do not translate. Points do. Even though both points and vectors may be represented as 2 numbers, you still need to differentiate the two; otherwise, you're significantly more likely to misuse them. For example, say I have two points, p1 & p2, that undergo some transformation, T, that includes a translation, t. I can compute a vector, v, between the two points: v=p2-p1. Thus p2=p1+v. Let's say that, given the origin o, p1=o+v and thus p2=o+2v. Now transform them. T(p2)=T(p1)+T(v) is true. T(p1)=T(o)+T(v) and T(p2)=T(o)+2*T(v) are not true in the general case, only in the case that t=0. In the former equation there is one extra translation, t. In the latter equation, the difference is 2t. It would, therefore, be dangerous to treat points the same as vectors. You would need to remove a very important invariant: vector addition is no longer a linear operation. In reality vector addition is still linear; however, by treating a point as a vector, you cannot enforce this fact in code.
Now, there might be completely different reasons for treating points and sizes differently in a C++ program, and that would be the type safety. But if we go in this direction, we might as well introduce a type for velocity, to be able to do something like this:
NS> That's a red herring.
It is nice/polite of you to quote several lines of text and call it all a red herring. Type safety is actually is an important reason to distinguish Point and Size classes, so that if you use one instead of another, you program just wouldn't compile (and making it easier to read too).
I apologize for the terseness of my position. In my rush to get back to work, I wanted to respond but not spend the time to do it properly. It was unfair. I called this a red herring because I thought it was purely a rhetorical device - an attempt to bring in a non-issue (velocity) to confuse the real issue (points). Type safety is important. I've argued for points precisely because there are major type safety issues involved because of the semantic differences. Most code out there doesn't make the distinction, and it causes problems. In math, I've always been taught that a vector "has direction and magnitude but no position". The CG literature I've read uniformly treated points and vectors as different beasts. In point set topology, it's possible to have points but no vectors. None of the discussions of geometry that I've read has mentioned velocity. I must admit that I haven't read anything on the geometry of relativity. -- Noah