RE: Re[4]: [boost] Re: Re: GUI Library Proposal for a Proposal

From: Noah Stein (noah_at_[hidden])
Date: 2004-11-07 15:22:42

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> 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