RE: [boost] Re: GUI Library Proposal for a Proposal
Russell Hind wrote:
Edward Diener wrote:
No !!!!! WxWidgets has almost nothing to do with modern C++. Let's no go there, or have anything to do with supporting any other GUI implementation.
Also, wxWindows is a huge library. If we were to introduce something in boost, I'd very much like it to be as small and light weight (as win32gui is supposed to be), not a collection of multi-megabyte dlls required, just to wrap win32 or what ever the underlying library is.
I am in the process of writing a platform-independant GUI (available at: http://uk.geocities.com/msclrhd/gui/gui.zip) that aims to be small and lightweight. This code is stll in the early stages and currently targets Win32/64 with minimal Cocoa/PalmOS support.
If people want more powerful components, they can be added afterwards, but the underlying library around core OS controls should be as small as possible.
In my library, I am working on: * gui::event_handler supporting lightweight "windowless" controls * gui::window supporting windows like the main frame, MDI child frames, etc. * gui::form (i.e. a frame with controls/layout set by an external designer referenced by ID) that includes dialog boxes in Win32. I do not have an implementation of gui::form yet. * gui::control supporting controls/widgets like buttons within a window or form These 4 classes should then make it possible to derive your own classes to support edit controls, property sheets, MDI windows, etc. I do not explicitly implement any of these extra UI components because they are platform dependant and will add to the complexity of the framework. This is especially true for things like "splitter" windows and floating/docking toolbars. Also, other components can be added at a later stage if necessary. As for the event processing mechanism, I have decided to use a std::map< event_id, void ( gui::event_handler::* )( gui::event * ) > that allows: class main_frame: public gui::window { public: void ev_destroy( gui::event * ); void EvDraw( gui::event * ); main_frame( gui::string name ): gui::window( ... ) { set_handler( WM_DESTROY, &main_frame::ev_destroy ); set_handler( WM_PAINT, &main_frame::EvDraw ); } }; At the moment, this does not support chaining of handlers (something on my todo list). The main event loop is controlled via gui::event_loop that does support filtering of events (e.g. processing keyboard shortcuts). There are also platform-independant versions of position (NSPoint, POINT, etc.), size (NSSize, PointType, etc.) and area (NSRect, RECT, etc.) that make use of properties allowing window positions to be handled in a platform-independant manner, e.g.: void main_frame::resizing( gui::event * ) { area a = get_client_area(); a.deflate( gui::size( 5, 5 )); pane -> move( a ); } At the moment, you need to register Win32/64 window classes using: gui::win::window_type frame_class( TEXT( "CxxGUIFrame" ), COLOR_BTNFACE ); but I am looking to abstract this. I am all for getting a group of people together from the boost mailing list interested in GUI and developing a general GUI framework. It may be useful to have at least one person from the C++ standards committee to get input from the standards people. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/
"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:BAY101-F20VythhOjcd000282d8@hotmail.com...
There are also platform-independant versions of position (NSPoint, POINT, etc.), size (NSSize, PointType, etc.) and area (NSRect, RECT, etc.) that
FWIW I find the difference between Point and Size largely irrelevent In MFC: CPoint (CSize ); CSize(CPoint ); tending to make me think that they could be covered by one type eg xy_pair;
At the moment, you need to register Win32/64 window classes using: gui::win::window_type frame_class( TEXT( "CxxGUIFrame" ), COLOR_BTNFACE ); but I am looking to abstract this.
I reckon the X or Fresco http://www.fresco.org ;-) end should be tackled too ... regards Andy Little
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: Friday, November 05, 2004 8:18 AM To: boost@lists.boost.org Subject: [boost] Re: Re: GUI Library Proposal for a Proposal
FWIW I find the difference between Point and Size largely irrelevent
In MFC:
CPoint (CSize ); CSize(CPoint );
tending to make me think that they could be covered by one type eg xy_pair;
It might be a valid distinction. It's certainly derived from affine geometry's concept of a point as a distinct entity separate from a vector. The distinction can be helpful since it carries some semantic information, e.g. points cannot be added unless they are weighted and all the weights add to 1. If not done properly it ends up being a headache since the semantics are ignored sometimes and pedantic at others. My gut reaction is that the distinction would be of little value in a window GUI, but I honestly haven't analyzed the situation too much. -- Noah
Andy Little wrote:
"Reece Dunn" <msclrhd@hotmail.com> wrote in message
There are also platform-independant versions of position (NSPoint, POINT, etc.), size (NSSize, PointType, etc.) and area (NSRect, RECT, etc.) that
FWIW I find the difference between Point and Size largely irrelevent
In MFC: CPoint (CSize ); CSize(CPoint );
tending to make me think that they could be covered by one type eg xy_pair;
MFC gets the intended use of CPoint/CSize wrong. In a mathematical sense, a point is a 0-size location in an nD coordinate system. In this case, it is a 2D coordinate system, so is (x,y). This is used for positioning, e.g. moving the graphics cursor, so I call it gui::position. It does not make sense to perform point [+-*/]= point since points are locations in a space (how do I add the location of my house to the location of Jupiter)? The size type stores width and height information, so it can be treated as a 2D vector. In this case, standard arithmetic operations make sense. Also, it is possible for sizes to interact with points, e.g. point += size. If you do point - point, then the resulting type is a size type that represents the distance between the two points. So in a mathematical sense, the difference between size and position is entirely relevant, it's just that some libraries (not mentioning names) do not adhere to the above mathematical rules.
At the moment, you need to register Win32/64 window classes using: gui::win::window_type frame_class( TEXT( "CxxGUIFrame" ), COLOR_BTNFACE ); but I am looking to abstract this.
I reckon the X or Fresco http://www.fresco.org ;-) end should be tackled too ...
Noted. I was planning on getting support for WinXX, Cocoa (MacOS), X11, GTK+ and Motif. I will need assistance to port to some of these APIs. Regards, Reece
RD> MFC gets the intended use of CPoint/CSize wrong. RD> In a mathematical sense, a point is a 0-size location in an nD RD> coordinate system. In this case, it is a 2D coordinate system, so is RD> (x,y). This is used for positioning, e.g. moving the graphics cursor, so RD> I call it gui::position. It does not make sense to perform point [+-*/]= RD> point since points are locations in a space (how do I add the location RD> of my house to the location of Jupiter)? I do not follow your logic. In mathematics, in Cartesian nD coordinate system, a point is represented by a set of distances between that point and the centre of coordinates, along each axe. Just like a vector. And vectorA + vectorB is a very common operation. RD> The size type stores width and height information, so it can be treated RD> as a 2D vector. In this case, standard arithmetic operations make sense. RD> Also, it is possible for sizes to interact with points, e.g. point += size. Once again, in geometry, vector and point are practically the same thing. RD> If you do point - point, then the resulting type is a size type that RD> represents the distance between the two points. Just like size - size. RD> So in a mathematical sense, the difference between size and position is RD> entirely relevant, it's just that some libraries (not mentioning names) RD> do not adhere to the above mathematical rules. There are no mathematical rules, which say that a point in nD Cartesian coordinate system is not just a set of corresponding distances along each axe. Valentin
On Fri, 5 Nov 2004 23:54:30 +0000, Val Samko <boost@digiways.com> wrote:
Once again, in geometry, vector and point are practically the same thing. Not really - you can only represent a point by its radius/position vector wrt a given coordinate system.
Radius vector and point are not the same thing, though. For instance, there is no meaning behind multiplying a point by a scalar. More formal, points are not members of any vector space, so you can't apply operations which are only defined on vectors on them.
RD> If you do point - point, then the resulting type is a size type that RD> represents the distance between the two points.
Just like size - size. The point (pun intended) is, that the resulting type is NOT a point. "point-point" has a different meaning than "vector-vector".
RD> So in a mathematical sense, the difference between size and position is RD> entirely relevant, it's just that some libraries (not mentioning names) RD> do not adhere to the above mathematical rules.
There are no mathematical rules, which say that a point in nD Cartesian coordinate system is not just a set of corresponding distances along each axe. A point can be *specified* by means of a vector, but it's not the same.
Another important.. point would be that o Cheers, Michael
MW> On Fri, 5 Nov 2004 23:54:30 +0000, Val Samko <boost@digiways.com> wrote:
Once again, in geometry, vector and point are practically the same thing. MW> Not really - you can only represent a point by its radius/position MW> vector wrt a given coordinate system.
I thought we are only talking about Cartesian coordinates? Does anyone really need a gui library for radial coordinate system? :) MW> Radius vector and point are not the same thing, though. For instance, MW> there is no meaning behind multiplying a point by a scalar. More MW> formal, points are not members of any vector space, so you can't apply MW> operations which are only defined on vectors on them. We are not talking about abstract points here. They are points in nD space, and each of them is represented by a corresponding vector. You may apply any operations defined in your space to your points/vectors. MW> The point (pun intended) is, that the resulting type is NOT a point. MW> "point-point" has a different meaning than "vector-vector". In C++ sence - yes, it's a different point. In mathematical sense, point-point depends on how this operation is defined in your particular space, and in Euclidean space, the result of this operations is the same as difference of corresponding vectors. If you need a distance, you need a norm, i.e. ||pointA-pointB||.
RD> So in a mathematical sense, the difference between size and position is RD> entirely relevant, it's just that some libraries (not mentioning names) RD> do not adhere to the above mathematical rules.
There are no mathematical rules, which say that a point in nD Cartesian coordinate system is not just a set of corresponding distances along each axe. MW> A point can be *specified* by means of a vector, but it's not the same.
Please see http://mathworld.wolfram.com/EuclideanSpace.html "Euclidean n-space (Cartesian space) is commonly denoted R^n. ... R^n is a vector space". So, any point in nD Cartesian space IS a vector. Valentin Samko http://val.samko.info
On Sat, 6 Nov 2004 13:12:14 +0000, Val Samko <boost@digiways.com> wrote:
MW> On Fri, 5 Nov 2004 23:54:30 +0000, Val Samko <boost@digiways.com> wrote:
Once again, in geometry, vector and point are practically the same thing. MW> Not really - you can only represent a point by its radius/position MW> vector wrt a given coordinate system.
I thought we are only talking about Cartesian coordinates? Does anyone really need a gui library for radial coordinate system? :) Apologies - I was apparently using the wrong term (not a native English speaker), and was just seeing "the vector r from the origin to the current position" on Mathworld. Googling a bit more it appears that it is such a vector in a polar/spherical coordinate system only.
The word I was looking for is "Ortsvektor" in German, the vector from the origin to a certain point. What would be the proper word for that in English (tried googling, failed :)?
MW> Radius vector and point are not the same thing, though. For instance, MW> there is no meaning behind multiplying a point by a scalar. More MW> formal, points are not members of any vector space, so you can't apply MW> operations which are only defined on vectors on them.
We are not talking about abstract points here. They are points in nD space, and each of them is represented by a corresponding vector. You may apply any operations defined in your space to your points/vectors. The Euclidean space is E^3, the vector space is R^3.
Please see: http://www.ma.umist.ac.uk/kd/curves/node3.html Note also: "Not all books make this distinction so you need to be prepared to encounter the unstated identification E^3 = R^n" Mathworld is using this _unstated_ _identification_; it is imprecise at least.
MW> The point (pun intended) is, that the resulting type is NOT a point. MW> "point-point" has a different meaning than "vector-vector". In C++ sence - yes, it's a different point. In mathematical sense, point-point depends on how this operation is defined in your particular space, and in Euclidean space, the result of this operations is the same as difference of corresponding vectors. Yes. But the result is a *vector*. IOW, the difference between 2 points is a mapping from two points in Euclidean space to a vector in a vector space: difference :: E^n x E^n -> R^n
Cheers, Michael
MW> The word I was looking for is "Ortsvektor" in German, the vector from MW> the origin to a certain point. What would be the proper word for that MW> in English (tried googling, failed :)? I do now know any other english term for that except for a "vector", but I am not a native english speaker as well. MW> The Euclidean space is E^3, the vector space is R^3. MW> Please see: http://www.ma.umist.ac.uk/kd/curves/node3.html MW> Note also: "Not all books make this distinction so you need to be MW> prepared to encounter the unstated identification E^3 = R^n" MW> Mathworld is using this _unstated_ _identification_; it is imprecise at least. It's not just Mathworld, it's thousands of books/articles. In any case, don't we assume, the gui library will use R^2 space?
In C++ sence - yes, it's a different point. In mathematical sense, point-point depends on how this operation is defined in your particular space, and in Euclidean space, the result of this operations is the same as difference of corresponding vectors. MW> Yes. But the result is a *vector*. IOW, the difference between 2 MW> points is a mapping from two points in Euclidean space to a vector in MW> a vector space: MW> difference :: E^n x E^n -> R^n I just do not get this. Why would you have a difference between two points in E^n defined as a point in R^n?
Valentin Samko http://val.samko.info
On Sun, 7 Nov 2004 00:26:26 +0000, Valentin Samko <boost@digiways.com> wrote:
MW> The Euclidean space is E^3, the vector space is R^3. MW> Please see: http://www.ma.umist.ac.uk/kd/curves/node3.html MW> Note also: "Not all books make this distinction so you need to be MW> prepared to encounter the unstated identification E^3 = R^n" MW> Mathworld is using this _unstated_ _identification_; it is imprecise at least.
It's not just Mathworld, it's thousands of books/articles. In any case, don't we assume, the gui library will use R^2 space? Most of the books/articles I have seen so far regard points as something different than vectors. It is even the way it's taught in High School ;-)
Usually you will read something like "a point can be specified/represented by a vector" (identification E^3=R^3). Everything else uses abovementioned identification, which, when unstatedly used, is at least imprecise.
In C++ sence - yes, it's a different point. In mathematical sense, point-point depends on how this operation is defined in your particular space, and in Euclidean space, the result of this operations is the same as difference of corresponding vectors. MW> Yes. But the result is a *vector*. IOW, the difference between 2 MW> points is a mapping from two points in Euclidean space to a vector in MW> a vector space: MW> difference :: E^n x E^n -> R^n I just do not get this. Why would you have a difference between two points in E^n defined as a point in R^n? Please read what I wrote: ".. to a vector in a vector space.". R^n is a *vector* space, hence the difference between two points in E^n is a *vector* in R^n.
MW> difference :: E^n x E^n -> R^n This is analogue to: vector<n> difference(point<n>, point<n>); in C++ (the point being that it is not a "C++ sense" thing, but that it naturally occurs like this in C++ because it represents the mathematical idea behind it).
Now, you can state the identification between points and vectors: E^n = R^n Again, in C++: typedef vector<n> point<n>; Cheers, Michael
MW> The Euclidean space is E^3, the vector space is R^3. MW> Please see: http://www.ma.umist.ac.uk/kd/curves/node3.html MW> Note also: "Not all books make this distinction so you need to be MW> prepared to encounter the unstated identification E^3 = R^n" MW> Mathworld is using this _unstated_ _identification_; it is imprecise at least.
It's not just Mathworld, it's thousands of books/articles. In any case, don't we assume, the gui library will use R^2 space? MW> Most of the books/articles I have seen so far regard points as MW> something different than vectors. It is even the way it's taught in MW> High School ;-) If your teacher treats E^2 and R^2 differently, he is a one weird teacher. Nowadays everyone considers them as the same space. If you google for Euclidean+vector+space, you will find plenty of lecture notes, etc, which assume that E^n is the same space as R^n, and element in E^n is a vector.
Considering the link you posted - either that guy is trying to be weird, or what he states there is only related to how he teaches the curve theory. Besides, he is being inconsistent in his definitions. Also, if we do not treat E^n as a vector space, then the difference in this space is somewhat undefined. MW> Usually you will read something like "a point can be MW> specified/represented by a vector" (identification E^3=R^3). MW> Everything else uses abovementioned identification, which, when MW> unstatedly used, is at least imprecise.
In C++ sence - yes, it's a different point. In mathematical sense, point-point depends on how this operation is defined in your particular space, and in Euclidean space, the result of this operations is the same as difference of corresponding vectors. MW> Yes. But the result is a *vector*. IOW, the difference between 2 MW> points is a mapping from two points in Euclidean space to a vector in MW> a vector space: MW> difference :: E^n x E^n -> R^n I just do not get this. Why would you have a difference between two points in E^n defined as a point in R^n? MW> Please read what I wrote: ".. to a vector in a vector space.". R^n is MW> a *vector* space, hence the difference between two points in E^n is a MW> *vector* in R^n.
I probably used the wrong word there. By *point* I meant "an element", and element in R^n is a vector. You can not have "points" in R^n, which are not vectors. See http://mathworld.wolfram.com/VectorSpace.html . Valentin Samko http://val.samko.info
On Sun, 7 Nov 2004 15:52:58 +0000, Valentin Samko <boost@digiways.com> wrote:
If your teacher treats E^2 and R^2 differently, he is a one weird teacher. "In High School" is unrelated to a certain teacher, hence it doesn't really help when you call people weird. Also "is the same space" != "is treated as the same".
Also, if we do not treat E^n as a vector space, then the difference in this space is somewhat undefined. No. You are assuming difference in E^n is a binary operation, whereas it is a mapping into R^n.
In C++ sence - yes, it's a different point. In mathematical sense, point-point depends on how this operation is defined in your particular space, and in Euclidean space, the result of this operations is the same as difference of corresponding vectors. MW> Yes. But the result is a *vector*. IOW, the difference between 2 MW> points is a mapping from two points in Euclidean space to a vector in MW> a vector space: MW> difference :: E^n x E^n -> R^n I just do not get this. Why would you have a difference between two points in E^n defined as a point in R^n? MW> Please read what I wrote: ".. to a vector in a vector space.". R^n is MW> a *vector* space, hence the difference between two points in E^n is a MW> *vector* in R^n.
I probably used the wrong word there. By *point* I meant "an element", and element in R^n is a vector. You can not have "points" in R^n, which are not vectors. So we seem to agree.
Cheers, Michael
First, although I know nearly nothing about GUI libraries, I suspect that there are much more important things to discuss than whether a Point is the same thing as a Vector. Still, I can't resist trying to help clarify things a little. I will stick to two dimensions. A Point and a Vector have the same internal representation, namely an ordered pair of doubles or floats. In that sense, both are the same. However, their public interfaces are different. A Vector will have the following operations: Vector operator+(Vector v, Vector w); Vector operator-(Vector v, Vector w); Vector operator(Vector v, double scalar); Vector operator-(Vector v); And, maybe also double length(Vector v); double inner_product(Vector v, Vector w); A Point, however, should have only the following operations: Point operator+(Point p, Vector v); Point operator-(Point p, Vector v); Vector operator-(Point p, Point q); And, maybe also double distance(Point p, Point q); A Point is NOT the same geometric object as a Vector, even though both have the same internal representation. Physicists understand this very clearly. They always draw a point as a dot and a vector as an arrow. Mathematically, the set of Vectors is the same set as the set of Points. But operationally they are very different. In mathematics we call the set of Vectors a "vector space" and the set of Points an "affine space". The beauty of object-oriented programming languages is that they are able to capture this difference and use it to help insure the correctness of a program and catch coding errors. But when all is said and done, I can think of much worse sins than pretending that a Point is the same thing as a Vector.
On Sun, 07 Nov 2004 15:24:22 -0500, Deane Yang <deane_yang@yahoo.com> wrote:
The beauty of object-oriented programming languages is that they are able to capture this difference and use it to help insure the correctness of a program and catch coding errors. Just to be nitpicky, I think this is more an issue of expressive type systems per se, than of OO. ;)
Cheers, Michael
Also, if we do not treat E^n as a vector space, then the difference in this space is somewhat undefined. MW> No. You are assuming difference in E^n is a binary operation, whereas MW> it is a mapping into R^n.
It all depends on how you define it. The difference in E^n is in E^n, and since noone distinguishes E^n and R^n, you can say that the difference is in R^n. Anyway, this is getting further and further away from the original question. There is something wrong if we try to distinguish E^n from R^n, talking about a GUI library.
I probably used the wrong word there. By *point* I meant "an element", and element in R^n is a vector. You can not have "points" in R^n, which are not vectors. MW> So we seem to agree.
Kind of. We are down to E^n vs R^n, which according to most literature is the same space, and according to some lecture notes are different spaces. Valentin Samko http://val.samko.info
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Michael Walter Sent: Sunday, November 07, 2004 2:52 AM To: boost@lists.boost.org Subject: Re: Re[6]: [boost] Re: Re: GUI Library Proposal for a Proposal
MW> a vector space: MW> difference :: E^n x E^n -> R^n I just do not get this. Why would you have a difference between two points in E^n defined as a point in R^n? Please read what I wrote: ".. to a vector in a vector space.". R^n is a *vector* space, hence the difference between two points in E^n is a *vector* in R^n.
The simplest way to say it is that point subtraction is not closed. It's no stranger than the fact that square root is not closed for reals.
Now, you can state the identification between points and vectors: E^n = R^n Again, in C++: typedef vector<n> point<n>;
If you are merely going to create a typedef, there's absolutely no reason to differentiate the two. Through the magic of typdef'ing, they would be semantically identical. Using your notation, E^n != R^n. They're both represented by n-tuples, but beyond that they are different. They have different operations. R^n has addition and subtraction, E^n has no addition operation and its subtraction isn't closed in E^n. R^n has inner and outer products, E^n does not. The above statement is true for affine and projective spaces. In a Grassmann space, points may be added together; however, points still do not have inner and outer products. In geometric algebra all the operations are defined and closed on all types. Somebody here wrote a GA library a year or two ago IIRC. -- Noah
Val Samko wrote:
RD> MFC gets the intended use of CPoint/CSize wrong.
RD> In a mathematical sense, a point is a 0-size location in an nD RD> coordinate system. In this case, it is a 2D coordinate system, so is RD> (x,y). This is used for positioning, e.g. moving the graphics cursor, so RD> I call it gui::position. It does not make sense to perform point [+-*/]= RD> point since points are locations in a space (how do I add the location RD> of my house to the location of Jupiter)?
I do not follow your logic. In mathematics, in Cartesian nD coordinate system, a point is represented by a set of distances between that point and the centre of coordinates, along each axe. Just like a vector. And vectorA + vectorB is a very common operation.
Yes, a point is taken w.r.t. the centre coordinates, but that does not mean that it behaves like a vector. All that means is that it is identifying a position in nD space, for example, a button is at (3,4) from a frame's client area. If you look up Point at MathWorld (http://mathworld.wolfram.com/Point.html) there is no reference to adding two points together, whereas for vectors (http://mathworld.wolfram.com/Vector.html) there is. Regards, Reece
I do not follow your logic. In mathematics, in Cartesian nD coordinate system, a point is represented by a set of distances between that point and the centre of coordinates, along each axe. Just like a vector. And vectorA + vectorB is a very common operation.
RD> Yes, a point is taken w.r.t. the centre coordinates, but that does not RD> mean that it behaves like a vector. All that means is that it is RD> identifying a position in nD space, for example, a button is at (3,4) RD> from a frame's client area. And vector in nD space is ... identifying a position in nD space. Just like a point. The difference is very vague and depends on the particular topic you are working on. RD> If you look up Point at MathWorld RD> (http://mathworld.wolfram.com/Point.html) there is no reference to RD> adding two points together, whereas for vectors RD> (http://mathworld.wolfram.com/Vector.html) there is. Once again, we are talking about Cartesian coordinates, and in this particular case, point and vector are practically the same thing. In many books/articles, etc. points are treated exactly the same as vectors. 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: void on_timer(time t) { velocity vel = getvelocity(); position pos = guiobject.pos(); move(guiobject, pos + (t - prev_t) * vel); prev_t = t; } Valentin Samko http://val.samko.info
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Val Samko Sent: Saturday, November 06, 2004 7:12 AM To: Reece Dunn Subject: Re[2]: [boost] Re: Re: GUI Library Proposal for a Proposal
And vector in nD space is ... identifying a position in nD space. Just like a point. The difference is very vague and depends on the particular topic you are working on.
Point and vectors are two distinct elements. Both mathematics and computer graphics consider them two different beasts. From Mathworld: http://mathworld.wolfram.com/Point.html http://mathworld.wolfram.com/VectorSpace.html Mathematically speaking, a point in an n-space is a 0-dimensional entity. No vector in n-space has ever been described as a 0-dimensional entity - it's always of dimension n. Although both are identified by n coordinates, they are clearly different beasts. Although a point in 3D at (3,4,8) could be represented by the vector (3,4,8) from the origin, this doesn't make the point and the vector the same thing. In homogeneous coordinates, the two are not equal: (3,4,8,1) != (3,4,8,0). Not only is there a semantic difference, but there's also a representational difference, too. As such, they truly aren't the same thing.
Once again, we are talking about Cartesian coordinates, and in this particular case, point and vector are practically the same thing. In many books/articles, etc. points are treated exactly the same as vectors.
In almost all of the computer graphics literature I have read, points and vectors are not treated uniformly. Computer graphics uses a number of spaces: affine, projective, and Grassmann. I suggest reading the following brief introduction to the use of coordinate systems in computer graphics: http://ibm.tju.edu.cn/resource/ComputerGraphicsApplication/ComputerGraphicsA pplication/2000/g2/g2076.pdf The author has a longer paper on the matter available to ACM members in the organization's digital library in the Transactions on Graphics area.
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:
That's a red herring. -- Noah
NS> Mathematically speaking, a point in an n-space is a 0-dimensional entity. NS> No vector in n-space has ever been described as a 0-dimensional entity - NS> it's always of dimension n. Although both are identified by n coordinates, NS> they are clearly different beasts. 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? NS> Although a point in 3D at (3,4,8) could be represented by the vector (3,4,8) NS> from the origin, this doesn't make the point and the vector the same thing. 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. NS> In almost all of the computer graphics literature I have read, points and NS> vectors are not treated uniformly. Computer graphics uses a number of NS> spaces: affine, projective, and Grassmann. I suggest reading the following NS> brief introduction to the use of coordinate systems in computer graphics: Do you really care about non Euclidean spaces, considering a GUI library? :) 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?
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). Valentin Samko http://val.samko.info
-----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
NS> I can only point you again to the PDF entitled "The Ambient Spaces of NS> Computer Graphics and Geometric Modeling". It has a discussion of various NS> coordinate spaces in which the difference between points and vectors are NS> clearly discussed: NS> Whether these spaces are "classical" mathematically or not is largely NS> irrelevant. What is relevant is that these are the coordinate spaces used NS> throughout the computer graphics literature. I did read this paper and it looks like the author notes that R^n spaces are not suitable for his theory (or it is easier to represent his results using other spaces) and introduces other spaces relevant for his research. Surely, some research in computer graphics may involve/require introduction of new spaces, but I fail to see how this relates to the choice of a space for basic operations used in a GUI library (which in my opinion should only be R^n).
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.
NS> Sure, there's an isomorphism between points and vectors; however, that NS> doesn't make them the same. There's an isomorphism between the functions NS> f(x)=x and f(x)=2x; however, that does not make those two equations the NS> same. This is an entirely different case. These two functions are two different elements in the same functional space (I assume, you defined them in the same space). NS> R^2 or R^3 is irrelevant. agreed NS> Maybe if we all just cared a little bit more about non-Euclidean spaces, NS> this world would be a better place? :) Good point, let's just not try to develop a gui library for a functional space :) NS> Yes, I'm fully saying that a point in R^2 is not a vector in R^2. I disagree. If you treat R^2 as a vector space, any element in this space is a vector. If you treat R^2 as an apple space, every element in it is an apple. Are you saying, R^2 is not a vector space? NS> Vectors NS> do not translate. Points do. Even though both points and vectors may be NS> represented as 2 numbers, you still need to differentiate the two; NS> otherwise, you're significantly more likely to misuse them. "otherwise, you're significantly more likely to misuse them." - true, and that is why I mentioned type safety in my previous post. NS> For example, say I have two points, p1 & p2, that undergo some NS> transformation, T, that includes a translation, t. What is a "translation" in this context? NS> Type safety is important. I've argued for points precisely because there NS> are major type safety issues involved because of the semantic differences. NS> Most code out there doesn't make the distinction, and it causes problems. Agreed. NS> In math, I've always been taught that a vector "has direction and magnitude NS> but no position". This is very correct, until we stick to R^n, where vectors and points happen to be same beasts. NS> The CG literature I've read uniformly treated points and NS> vectors as different beasts. I am not a CG expert, so I do not know why this is so in CG literature, probably this approach is more convenient to describe some CG problems. I am only familiar with dimensionality reduction aspects of CG, which treat points and vectors as the same beasts. Valentin Samko http://val.samko.info
On Sun, 7 Nov 2004 23:01:37 +0000, Valentin Samko <boost@digiways.com> wrote:
NS> For example, say I have two points, p1 & p2, that undergo some NS> transformation, T, that includes a translation, t. What is a "translation" in this context? A point P(x,y), translated by (dx,dy), results in the point P'(x+dx,y+dy).
Valentin Samko wrote:
The CG literature I've read uniformly treated points and vectors as different beasts. I am not a CG expert, so I do not know why this is so in CG literature, probably this approach is more convenient to describe some CG problems. I am only familiar with dimensionality reduction aspects of CG, which treat points and vectors as the same beasts.
That's because in CG one can't get away with treating points and vectors uniformly. Both points (positions in space) and vectors (surface normals at a particular position) are integral parts of CG, but moving an object only affects positions, not normals. That said, in GUI (and 2D positioning in general) I've always been able to get away with using vectors everywhere (and calling them points, of course.) I wonder whether the convenience is a win over the extra type safety in this context.
Peter Dimov wrote:
Valentin Samko wrote:
The CG literature I've read uniformly treated points and vectors as different beasts. I am not a CG expert, so I do not know why this is so in CG literature, probably this approach is more convenient to describe some CG problems. I am only familiar with dimensionality reduction aspects of CG, which treat points and vectors as the same beasts.
That's because in CG...
Oops. Ambiguous CG. Computer Graphics versus Computational Geometry?
Somewhere in the E.U., le 08/11/2004 Bonjour What Reece described is the difference between a vector space and an affine space. A vector space has one "special" element, the zero vector, whereas an affine space has none (every point is equivalent to every other). You *have* to choose one point in an affine space and label it as the "origin". There is (intrinsically) no way to choose such a point canonically. The confusion (that there is some magical way to choose the origin) comes from the fact that a vector space can *also* be endowed with an affine space structure (usually, but not necessarily, by choosing the zero vector as the origin). Likewise, one can derive a vector space from an affine one, but both are conceptually, and practically, two very different beasts. "Point+Point" is meaningless, "Point+Vector" is meaningful. Hubert Holin In article <1852440446.20041105235430@digiways.com>, Val Samko <boost@digiways.com> wrote:
RD> MFC gets the intended use of CPoint/CSize wrong.
RD> In a mathematical sense, a point is a 0-size location in an nD RD> coordinate system. In this case, it is a 2D coordinate system, so is RD> (x,y). This is used for positioning, e.g. moving the graphics cursor, so RD> I call it gui::position. It does not make sense to perform point [+-*/]= RD> point since points are locations in a space (how do I add the location RD> of my house to the location of Jupiter)?
I do not follow your logic. In mathematics, in Cartesian nD coordinate system, a point is represented by a set of distances between that point and the centre of coordinates, along each axe. Just like a vector. And vectorA + vectorB is a very common operation.
RD> The size type stores width and height information, so it can be treated RD> as a 2D vector. In this case, standard arithmetic operations make sense. RD> Also, it is possible for sizes to interact with points, e.g. point += size.
Once again, in geometry, vector and point are practically the same thing.
RD> If you do point - point, then the resulting type is a size type that RD> represents the distance between the two points.
Just like size - size.
RD> So in a mathematical sense, the difference between size and position is RD> entirely relevant, it's just that some libraries (not mentioning names) RD> do not adhere to the above mathematical rules.
There are no mathematical rules, which say that a point in nD Cartesian coordinate system is not just a set of corresponding distances along each axe.
Valentin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
There are also platform-independant versions of position (NSPoint, POINT, etc.), size (NSSize, PointType, etc.) and area (NSRect, RECT, etc.) that make use of properties allowing window positions to be handled in a platform-independant manner, e.g.:
Are these classes capable of transforming the position to the correct co-ordinate system of the platform you are working with. For example, in Windows and Classic Mac Toolbox (0,0) is in the upper left corner, but in OS X, it is in the bottom left corner (you can tell the OS to transform it for you, but you might not always have that option). Also, what about floats for points and size (I think OS X uses them this way, but I'd have to look it up to double check). Jared McIntyre
participants (10)
-
Andy Little -
Deane Yang -
Hubert Holin -
Jared McIntyre -
Michael Walter -
Noah Stein -
Peter Dimov -
Reece Dunn -
Val Samko -
Valentin Samko