Sérgio Vale e Pace <svpace.forum <at> gmail.com> writes:*

Ahh, now I get it... I will take a look at your code. (Thanks a lot for your time Sérgio !)

Well, just to make myself clear, here is a quote from the documentation <quote> One of the most important aspect of the library is its close integration with existing ones. That is, you surely already have some points&rectangles library you are happy with, in fact, you surely have some graphical library that imposes its own points and rectangles, and you don't want to use Boost.Geom if this means converting between Boost.Geom's stuff into you library's stuff, and vise-versa. You don't have to: you can make Boost.Geom compatible with any other points&rect library to take benefit of all features it has to offer and still be able to call (the zero cost) impl() member to obtain something your library wants, and to go back (at no cost) to Boost.Geom stuff you use function wrappers. This is just a matter of specializing some traits classes. ..... But the general spirit is here: - Close integration with already existing libraries. - Lots of handy features for every abstraction. - Not imposing additional overhead over a more simplistic library </quote> Also, it seems that there already has been some project similar (5 years ago): After having a look at the "Boost Yahoo Group Files" I found something of a ``geomerty2D'' library (geometry2D/geometry2D.zip). I still haven't looked at it closely, but seems limited to 2D and offering just one implmentation. Well, maybe its author (Aleksey Gurtovoy) would like to join the party here ! I also have posted Geom in the Boost Yahoo Group Files section, filename: geom.zip -- Anis Benyelloul

Andy Little <andy <at> servocomm.freeserve.co.uk> writes:

I had a quick look. Thanks !

You would need to change the licence for boost. Ahem.. I assume you're talking about the manual, because the code *is* under the Boost Licence. And about the manual, I don't recall having read something that forbids FDL for manuals ... maybe be I missed it ?

Not quite sure I understand the reason behind the parameter for points. You're talking about the template parameter of geom::point<> ? Well, it is an implementation type (as explained in the manual), something that tells geom::point<> how you'd like to implement the notion of ``point'' (as XY, as XYZ, as polar coordinates ... etc).

Why no lines? Maybe in the next version ? But think of this, what is a line ? isn't it a std::pair<point, point> ? Also, I had the idea of geom::region (a region of the plan/space) a collection of boxes, geom::polygon<> a collection of points ... etc ... But lets make sure we have the best points and rectangles of the planet first :)...

Hope to have a longer look at some stage. Hope so ...

--Anis Benyelloul

Joel de Guzman <joel <at> boost-consulting.com> writes:

How do you plan to implement your regions? If your Points can use native platform points, I assume your regions can also use native platform regions? Or are we talking about different things? I'm interested on how you can make it use the Macintosh classic Region, for example.

Well, let me think of it.... What is a region ? A collection of (non- overlapping ?) boxes. Now what is a collection of boxes ? - std::vector<box> - boost::array<box, 20> - box ; // Note: a single box ! - XRegion ;// Maybe some pre-existing region object in other libraries As you see, the problem is quite the same: for one abstraction (region) being able to choose among many implementations, and just "plug" them in some convenient wrapper class. Actually, I haven't studied much the subject, but it doesn't seem of extrem complexity ... (to be continued) --Anis Benyelloul

Joel de Guzman <joel <at> boost-consulting.com> writes:

Example: I need to XOR a YRegion with a MacRegion.

Although actual library implmentation permits mixed implmentation computations, I really doubt you'll ever need to do that. Do you think that you may be using Xlib's XRegion and Mac's MacRegion (and Windows' RGN) in the same program ? Usually you'll just choose one implmentation and stick with it throughout your project... This still remanis a consistency concern, however.

The thing is, a classic mac region is an opaque data type (actually, it's not implemented as a collection of boxes). The mere fact that it is opaque makes it impossible to even copy a mac region to a YRegion.

Right ! Let me add that Window's RGN is also an opaque type. Well maybe a geom::region is useful but I don't think that MacRegion XRegion and RGN are suitable implmentation of what we define as a ``region''. -- Anis Benyelloul

Joel de Guzman <joel <at> boost-consulting.com> writes:

I'd want to assign, say, a Mac Region to a cross-platform region. That way, I can, say, transform the more versatile cross-platform region, scale it, rotate it, etc. These functions are not available in the platform specific region.

This would be only possible/safe if MacRegion wasn't so opaque. But maybe the other way around is possible: Create a cross-platform region from the start, scale it, rotate it, reshape it, cook it (??), and then turn it into a MacRegion ! -- Anis Benyelloul

"Anis Benyelloul" <benyelloul@mailbolt.com> wrote

Andy Little <andy <at> servocomm.freeserve.co.uk> writes:

...

I had a quick look. Thanks !

...

You would need to change the licence for boost. Ahem.. I assume you're talking about the manual, because the code *is* under the Boost Licence. And about the manual, I don't recall having read something that forbids FDL for manuals ... maybe be I missed it ?

Ok .. I dont know how boost sees this.

...

Not quite sure I understand the reason behind the parameter for points. You're talking about the template parameter of geom::point<> ? Well, it is an implementation type (as explained in the manual), something that tells geom::point<> how you'd like to implement the notion of ``point'' (as XY, as XYZ, as polar coordinates ... etc). The interface is familiar :

url<http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/source/streamlines.hpp> Recently howver I use a struct with x and y members... its less typing ;-) Ok. I understand the use of a common type for cartesian and polar coordinates. Alternatively these two types could be provided as complete useable types, with a common interface. A viable alternative to the wrapper is simply to provide a conversion from one to the other type. Specialising the traits class looks to be nearly the same work as writing these from scratch with a common interface. One could provide something similar by overloaded functions: I dont see the advantage in wrapping other libraries point types. I would want precisely defined semantics on the parameters of a point. For example I would expect the semantics of float versus integer value_types to be defined separately. Allowing use of user defined point systems would appear to make this type of control of the specification much more difficult, if not impossible. Not sure what units angles are in. Is it degrees or radians? radians is my preference. FWIW I use specific type safee angle types. This allows conversions between the two families of angular unit. I also use types representing lengths in graphics. IOW I use a point<pqs::length::mm> type etc. This provides graphics data with unit information independent of the device its currently being displayed on. Its not a solution for every case but where the units of an entity is fixed it provides this information with no runtime space overhead. See my site at http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html I strongly disagree with the statement in the documentation: " Indeed, a ``2D point'' is just a 3D point whose implementation doesn't actually reserve memory space for a Z attribute." 2D space has no notion of another dimension. There is no Z attribute. Projections of 3D objects onto a 2D plane are not limited to truncation of their z-dimension. Mixing 2D and 3D points doesnt actually happen in my experience. They live in separate spaces. 3D points are mapped to 2D points by applying a transform(projection). Some sort of matrix operations on 2D and 3D points should also be available(which will require conversion to homogeneous coordinates).

...

Why no lines? Maybe in the next version ? But think of this, what is a line ? isn't it a std::pair<point, point> ? Also, I had the idea of geom::region (a region of the plan/space) a collection of boxes, geom::polygon<> a collection of points ... etc ... But lets make sure we have the best points and rectangles of the planet first :)...

The box here is useful for a GUI viewport or window, an attribute of the current output device. IMO Its a mistake for a geometry library to get involved with this low level stuff too early. Geometrically a box is a 2D region bounded by geometric *1* lines, with no guarantee of its attitude. Why not start with the most primitive concepts, eg geometric points, lines, circles arcs, curves and regions? As for lines, one could use std::pair, but IMO a 'line' type is a clearer statement when reading code. That said, there should be some form of mechanism for graphical output on various platforms/ devices, but again without this affecting the core geometry library. generically this requires some means of converting points between various coordinate systems. Sorry for all the criticism. As you may gather I have my own ideas on what I want from a geometry library... looking forward to hearing your views ... * 1* as opposed to lines which have colour and thickness. These attributes, though required for output are not necessary from a geometric viewpoint Andy Little

Joel de Guzman <joel@boost-consulting.com> writes:

Andy Little wrote:

...

"Anis Benyelloul" <benyelloul@mailbolt.com> wrote

...

...

You would need to change the licence for boost.

Ahem.. I assume you're talking about the manual, because the code *is* under the Boost Licence. And about the manual, I don't recall having read something that forbids FDL for manuals ... maybe be I missed it ?

Ok .. I dont know how boost sees this.

I think it should apply to both and this should be made clear.

Agreed. Anything else will just undermine the purpose of having a unified license. -- Dave Abrahams Boost Consulting www.boost-consulting.com

Andy Little <andy <at> servocomm.freeserve.co.uk> writes:

Recently howver I use a struct with x and y members... its less typing ;-)

Ahhh.. I see :). Well, let's examine why using a "struct point { int x, y; };" is a bad idea. -1 Sometimes you aren't even given the choice --------------------------------------------- Indeed, if you're already using some graphical libraries, the choice is made for you. Consider this (hypothetical) example about a library named "trendy_graph" : <example> // In header trendy_graph.h // Rectangles for trendy_graph typedef struct __TG_RECT { TG_COORD left; TG_COORD right; TG_COORD top; TG_COORD bottom; } TG_RECT; // Updates a region of the screen // re: A pointer to an array of TG_RECT // n: The number of TG_RECT in re TG_Update_Screen(TG_RECT* re, size_t n); </emaple> (This is just the kind of ugly C interface I face everyday ..). Look how TG_Update_Screen needs a TG_RECT*. Now you suggested this : <your_suggestion> struct point { int x,y; }; struct rectangle { int x, y, width, height; }; </your_suggestion> Well, if you insist on using rectangle (instead of TG_RECT) you'll end up creating an array of rectangle, and converting it into the corresponding array of TG_RECT that you can pass to TG_Update_Screen. This is overkill. If you care about performances you'll just use TG_RECT in your own code. And when you move to another library (say fast_graph) you'll have to *learn* FG_Rectangle because FG_DrawRectandle needs an instance of FG_Rectangle, and you're not willing to do conversions. Be ready to learn XRectangle, SDL_Rect, RECT, MAcRect, FuNReCt, HEAVY_Rect, stupid_rect, (??).. :) -2 Less typing? --------------- Now if you can choose any point class you want, we may compare "struct simple_point{ int x, y; }" with "geom::point<>". - First simple_point is not much less to type. After some suitable typedefs (that you'll write once and for all), working with Boost.Geom resembles this : <example> point pt=point_xy(3, 4); pt.x()=10; pt.rho()=1; // normalizing pt.theta()+=3.14159/2; // rotating by 90° </example> This isn't far of what you can do with simple_point. - simple_point, is not yet written. You have to do it, you have to document it, you have to maintain it, you have to care about it... And you'll have to redo that (or to copy/past) for each project! because sometimes you'll need 3D points, polar points, "double" points, "float" points, "unsigned short" points ... - geom::point<> has more features ready to use. RHO, THETA, PHI,... - And finally, simple_point is not faster then geom::point<>. Or stated another way, geom::point<> can be as fast as simple_point

Ok. I understand the use of a common type for cartesian and polar coordinates. Alternatively these two types could be provided as complete useable types, with a common interface.

I'm not sure I get it, could you name the "types" you're talking about ?

A viable alternative to the wrapper is simply to provide a conversion from one to the other type.

A as a consequence of traits&wrappers the conversion is already provided: <code> point<point_polar> pt_p=point_polar(1, 3.141592654); // Polar point<point_xy> pt_c=point_xy(10, 20); // Cartesian pt_p=pt_c;// Conversion !!! </code>

Specialising the traits class looks to be nearly the same work as writing these from scratch with a common interface.

I don't get that either, sorry... Could you explicit your thoughts a bit ?

One could provide something similar by overloaded functions:

Humm... do you mean that we should have something like : <code> template<class PointImpl> value_type get_x(const PointImpl&); template<class PointImpl> void set_x(const PointImpl&, value_type); </code> And then we'll specialize set_x&get_x for point implementations? If that is what you mean, then yes ! it is the same as traits classes. But people already know what a traits class is, so I don't really have to explain the design this way.

I dont see the advantage in wrapping other libraries point types.

Well, you recall the TG_RECT and FG_Retangle we saw above, and you remember that we are obliged to use them. Now instead of having to face the ugliness of TG_RECT everyday you can wrap it in a geom::box and manipulate it with ease. <code> geom::box<TG_RECT> region_to_update[100]; // Here use all nice features of geom::box like center() and corner() //... // Now use impl() to get TG_RECT TG_Update_Screen(®ion_to_update[0].impl(), 100); </code> Note that : - You take benefit of the notaional convinience of geom::box - geom::box is a zero cost wrapper, using it does not create additional overhead as such. - You don't have to convert between geom::box<TG_RECT> and TG_RECT, or more precisely, the conversion is zero cost. And that is not specific to trendy_graph, if you also work with FastGraph you'll be able to wrap FG_Rectangle in a geom::box and enjoy the same interface as with geom::box<TG_RECT>, while still be able to turn a geom::box<FG_Rectangle> into a FG_Rectangle at no cost ! You learn one interface (that of geom::box) and you keep using it regardless of the underlying graph API, while not having to pay in efficiency, Isn't wrapping other libraries wonderful ?

I would want precisely defined semantics on the parameters of a point. For example I would expect the semantics of float versus integer value_types to be defined separately. Allowing use of user defined point systems would appear to make this type of control of the specification much more difficult, if not impossible.

Well, putting the exact and precise requirements imposed on geom::point<>'s template parameter and on the corresponding traits specialization is hard, very hard, maybe too hard for me. But I'll give it a try. Thanks for pointing this out.

Not sure what units angles are in. Is it degrees or radians? radians is my preference.

The standard C++ library (std::sin, std::cos, .. etc) speaks in radians, so I do.

FWIW I use specific type safee angle types. This allows conversions between the two families of angular unit. I also use types representing lengths in graphics. IOW I use a point<pqs::length::mm> type etc. This provides graphics data with unit information independent of the device its currently being displayed on. Its not a solution for every case but where the units of an entity is fixed it provides this information with no runtime space overhead.

Interesting ... As a first impression, I can say that currently available point implementations use double for angles, but nothing in the library design prevents using pqs:: stuff.

See my site at http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html

What is the connection between your library and boost, do you intend to have it accepted in Boost ? .. I'll make sure to give it a try ...

I strongly disagree with the statement in the documentation:

" Indeed, a ``2D point'' is just a 3D point whose implementation doesn't actually reserve memory space for a Z attribute."

Ok, maybe you're right. But I think it just a matter of how to express things. Consider the alternative : " There is no such a thing as a 2D point, There is even no such a thing as 2D, the world is 3D, and all points are 3D. Now, some point are always located on Z=0 plan and don't need to actually store their Z attribute, we call them 2D points."

2D space has no notion of another dimension.

Consider this: (let IR be the set of all real numbers) IRxIR is a 2D space. And IRxIRxIR is a 3D space. Let U={(x,y,z) in IRxIRxIR such that z=0} Now we can find an automorphism that maps U to IRxIR. That is, even though U seems part of IRxIRxIR (3D), it is mathematically indistinguishable from IRxIR (2D). So U is a part of IRxIRxIR (3D), but at the same time *it is* IRxIR (which is 2D). See how the "notion of another dimention" depends on the point of view ...

Mixing 2D and 3D points doesnt actually happen in my experience. They live in separate spaces. Like I say, 2D points are elements of IRxIR which is U which is part of IRxIRxIR which is the set of all 3D points. It just a matter of how you look at things ..

3D points are mapped to 2D points by applying a transform(projection). Some sort of matrix operations on 2D and 3D points should also be available(which will require conversion to homogeneous coordinates).

For homogeneous stuff, one can easily write a point implementation, say point_xyzq that stores a forth attribute. But about matrix transformation,... well, I'm not sure if there should be somekind of geom::matrix.. For example, If your're doing 3D games using OpenGL you already have some matrix manipulation primitives like glMultMatrix(), do we want to wrap glMultMatrix, to concurrence it or not care about it at all ? (IMO the latter !)

The box here is useful for a GUI viewport or window, an attribute of the current output device. IMO Its a mistake for a geometry library to get involved with this low level stuff too early. Geometrically a box is a 2D region bounded by geometric *1* lines, with no guarantee of its attitude. Why not start with the most primitive concepts, eg geometric points, lines, circles arcs, curves and regions?

Exactly what I was thinking.

That said, there should be some form of mechanism for graphical output on various platforms/ devices, but again without this affecting the core geometry library. generically this requires some means of converting points between various coordinate systems.

Humm .... such a mechanism should be, but I doubt it is really up to Boost.Geom to provide it. The user is free to use any output means available, for example if [s]he is using fast_graph: <code> geom::box<FG_Rectangle> bx; // Play with bx .... // Draw bx FG_DrawRectangle(&bx.impl(), FG_Forground, FG_MAKE_COLOR_RGB(0x2, 0x22, 0x32); </code>

Sorry for all the criticism. As you may gather I have my own ideas on what I want from a geometry library... looking forward to hearing your views ...

No, don't be sorry. With your suggestions, opinions and criticism you're helping improve my work (& knowledge), thanks a lot.

as opposed to lines which have colour and thickness. These attributes, though required for output are not necessary from a geometric viewpoint

I totally agree ! PS: I'll have a look at your library and tell you my impressions. But where should I send them ? Private mail ? Boost mailing list ? Anywhere else ? --Anis Benyelloul

Andy Little <andy <at> servocomm.freeserve.co.uk> writes:

template<typename ValueType> struct rectangle{ xy_pair<ValueType> position; xy_pair<ValueType> size; };

Nice ! I like the idea of a meaningful neagative size.

I generally only have a very few low level conversion functions where my user types are converted to the platform dependent types for output. I would guess that the system call to the graphics device is much more expensive than the single conversion so the cost is small,( but I havent tested this theory)

Ok ! Consider this: We are writing a 2D Game using SDL. Each time we move something on the screen we must remember its last and new position (two rectangles) so that we can redraw that area and update the screen (we call this, a dirty rectangle mechanisim) So at each frame we construct the region of the screen that has to be redrawen before calling SDL_UpdateRects to update the screen. The region is constructed 60 times per second (this the refresh rate of most screens), do you think that the game writer will want to convert a vector<rectangle> (whose size may vary between 0 and 100) into the corresponding vector<SDL_Rect> 60 times per second ? And remember there is far more stuff to be done in this 1/60 of a second.

I prefer using my own graphics primitives for various reasons. For example using Windows GDI output range is limited to a 16 bit integral value. I perform to work using (underlying) doubles, convert to the device coordinate system and finally clip the resulting value to the device viewport and only then cast to an integer to perform the raw output using the implementation defined call. In practise I never use the graphics platform defined types directly.

Fair enough ! But what if you're actually satisfied with 16 bit integrals ? Do you still want to do conversions ?

Yes , I see the point of the wrapper , but OTOH

point_polar p1 = point_xy(); point_xy p 2 = p1;

should also work.

I beg to differ. Implementation types were never ment to be used as such, they were designed to be wrapped. Indeed, for sometime I resisted the following idea : template<class T> struct point_xy { friend class point_traits< point_xy<T> >; point(); point(T x, T y); private: T x, y; }; That is only the traits class specilization need to know about members of point_xy. I really can't see why you'd want to use (the simple, featureless) point_xy when you have (the powerfull, general) point<point_xy>. For example if you use point_xy for your project and after 2 months you realize that polar points are more suitable, lots of stuff will need to be changed for point_xy provides direct access to its x and Y (only), while polar_point provides RHO and THETA (only) , but point<point_xy> *and* point<polar_point> do provide X, Y, Z, RHO, THETA, and PHI !!!

Sure ...Assuming the above two types

point_polar.x(); point_xy.x();

point_xy. phase_angle(); point_polar.phase_angle();

IOW each has the same interface.

Ok, but you seem to be only considering implementation types provided by Boost.Geom. Of course we could do that, but this is only because we have complete control over point_xy and point_polar. Now what about std::complex<> ? Do you think you can arrange to be able to write: typedef std::complex<float> point; point pt; pt.x()=10; pt.phase_angle()+=3.141592654; What about POINT, QPOint, XPoint, XYZ_Point_XYZ ? So no, giving a bunch of types the same interface is quite not the same as using traits. For one good reason: You don't have control over all the types you'd like to give the same interface. Using traits you can effectively call x() on an std::complex<> ; geom::point< std::complex<double> > pt; pt.x()+=0.3; // Et Voila ! So, in order to keep consistency we don't provide complicated members in implementation types, we put them in wrapper classes.

...

Note that : - You take benefit of the notaional convinience of geom::box - geom::box is a zero cost wrapper, using it does not create additional overhead as such. - You don't have to convert between geom::box<TG_RECT> and TG_RECT, or more precisely, the conversion is zero cost. And that is not specific to trendy_graph, if you also work with FastGraph you'll be able to wrap FG_Rectangle in a geom::box and enjoy the same interface as with geom::box<TG_RECT>, while still be able to turn a geom::box<FG_Rectangle> into a FG_Rectangle at no cost ! You learn one interface (that of geom::box) and you keep using it regardless of the underlying graph API, while not having to pay in efficiency, Isn't wrapping other libraries wonderful ?

Well its certainly a trick that this library plays but the wrapping is very limited (because the underlying tyopes are exposed in the template parameter),

What ? I don't see in what it is limited. If you don't want to expose the templete parameter, use typedefs !! typedef geom::point< geom::point_xy<float> > point; // Now forget about Boost.Geom and use point ! POINT convert_to_POINT(const point& pt);

but how useful is it in practise? How often do you need to convert?

60 times per second converting 100 rectangles is overkill.

I prefer to hide the platform dependent points behind a 'standard' type which works at a level above the output device towards which these other types seem to be geared. However I dont think that your library rules this out.

It doesn't. If you want close integration use point<GG_Point_2D> if you want platform independent types use point< point_xy<double> > !

You could even specialise it for eg double parameter..

The point I'm trying to make is that its much easier to do this if the

And could you tell me about the possible benefits we'd reaping of this ? platforms

own types are not exposed at all.

Don't get why...:(

OK.. take a look at the angles in pqs. Using them you can use both degrees and radians interchangeably. degrees is more human friendly IMO , while radians is better for math of course. :-)

This certainly is a good idea. Now if only your library gets accepted in Boost ...

...

U={(x,y,z) in IRxIRxIR such that z=0}; [...] Not too good on the math theory . IOW I dont understand this :-(

Unless you provide ready made output facilities, no one will use the library IMO. I disagree. People already have/know output facilities optimized for thier

Don't be afraid by technical math terms like ``automorphism'' ! (they're merely good enough for impressing girls .. ;-) ) It only means that there is a bijection between U and IRxIR , i.e to every element of U corresponds one and only one element of IRxIR, and to every element of IRxIR corresponds one and only one element of U. So IRxIR and U are (mathematically) the same. [...] platform and they can easily use them to draw geom::boxes.

It also gives a chance to prove how cross-platform the library really is.

It is already cross platform. You can plug almost anything in a geom::point<>

template < typename GX

...

void redraw(GX & gx) { pt p0,p1,p2,p3; // some points line L1(p0,p2); /

polyline poly0; poly0 += p0, p1,p2,p3; // assign values

polygon poly1; poly1 += p0, p1,p2,p3;

bezier bez( L1, line(p1,p3)); // gx is some graphics output device

gx << L1 << poly0 << poly1 << bez; }

Wow !!! You got far away my friend !! We aren't writing a graphical library, we are writing a "Geometric Primitives Library". If you already have some graphical library feel free to use it to draw geom::points, geom::bezier ... But I doubt it is the purpose of Boost.Geom to provide things like GraphContext or Window::handle_event(const MouseEvent&)! Of course if someone wants to do this (think of it ! a Boost-Quality cross platform GUI/Graph library) Boost.Geom could serve as a "base", but it shouldn't itself be the graph API. Let's divide the problem into small pieces and deal with each spearatly.

Hopefully some day sooner or later I plan to redo it suitable for boost and of course will announce the fact too :-)

Ok I'll wait :). -- Anis Benyelloul

"Anis Benyelloul" <benyelloul@mailbolt.com> wrote [..]

60 times per second (this the refresh rate of most screens), do you think that the game writer will want to convert a vector<rectangle> (whose size may vary between 0 and 100) into the corresponding vector<SDL_Rect> 60 times per second ? And remember there is far more stuff to be done in this 1/60 of a second.

An SDL_rect is converted to a system call. Whats the difference?

...

I prefer using my own graphics primitives for various reasons. For example using Windows GDI output range is limited to a 16 bit integral value. I perform to work using (underlying) doubles, convert to the device coordinate system and finally clip the resulting value to the device viewport and only then cast to an integer to perform the raw output using the implementation defined call. In practise I never use the graphics platform defined types directly.

Fair enough ! But what if you're actually satisfied with 16 bit integrals ? Do you still want to do conversions ?

I would use a vect<int16> . (FWIW I conclude that vect sums up the functionality better than xy_pair) [..]

...

Sure ...Assuming the above two types

point_polar.x(); point_xy.x();

point_xy. phase_angle(); point_polar.phase_angle();

IOW each has the same interface.

Ok, but you seem to be only considering implementation types provided by Boost.Geom. Of course we could do that, but this is only because we have complete control over point_xy and point_polar.

Nothing wrong with having complete control !

Now what about std::complex<> ? Do you think you can arrange to be able to write:

typedef std::complex<float> point;

[..] I dont need complex, I have point_polar ... [..]

What ? I don't see in what it is limited. If you don't want to expose the templete parameter, use typedefs !!

typedef geom::point< geom::point_xy<float> > point;

// Now forget about Boost.Geom and use point !

POINT convert_to_POINT(const point& pt);

But the dependency is required if you want to use an typedef geom::point< SDL_point > point;

...

but how useful is it in practise? How often do you need to convert?

60 times per second converting 100 rectangles is overkill.

Yet the conversion is ok for SDL ...? [..]

...

You could even specialise it for eg double parameter..

And could you tell me about the possible benefits we'd reaping of this ?

It would represent the simple useage I want... ;-)

...

The point I'm trying to make is that its much easier to do this if the platforms own types are not exposed at all.

Don't get why...:(

Heres a quote from your original post "

Well, putting the exact and precise requirements imposed on geom::point<>'s template parameter and on the corresponding traits specialization is hard, very hard, maybe too hard for me. But I'll give it a try. Thanks for pointing this out. "

...

OK.. take a look at the angles in pqs. Using them you can use both degrees and radians interchangeably. degrees is more human friendly IMO , while radians is better for math of course. :-)

This certainly is a good idea. Now if only your library gets accepted in Boost ...

Thanks. :-)

...

...

U={(x,y,z) in IRxIRxIR such that z=0}; [...] Not too good on the math theory . IOW I dont understand this :-(

Don't be afraid by technical math terms like ``automorphism'' ! (they're merely good enough for impressing girls .. ;-) ) It only means that there is a bijection between U and IRxIR , i.e to every element of U corresponds one and only one element of IRxIR, and to every element of IRxIR corresponds one and only one element of U. So IRxIR and U are (mathematically) the same.

hmm... Mathematics is notoriously poor at modelling space ! [...]

...

It also gives a chance to prove how cross-platform the library really is.

It is already cross platform. You can plug almost anything in a geom::point<>

IMO cross-platform implies gives consistent results independent of platform. Plugging in platform dependent types is opposite to this.

Of course if someone wants to do this (think of it ! a Boost-Quality cross platform GUI/Graph library) Boost.Geom could serve as a "base", but it shouldn't itself be the graph API. Let's divide the problem into small pieces and deal with each spearatly.

Allowing platform dependent types as template parameters is seriously mixing geometry with device output. I agree that they should be separated, but as it stands the library doesnt achieve this. There are two aspects of the library which should be separated: 1)I can see the use of the wrapper for hiding the difference between cartesian and polar coordinates,( though I'm not convinced of how useful it is). 2) I cannot see the use of platform dependent point types as template parameters being very useful. As you yourself said, one is only working on one platform at one time, so converting between platform dependent types in code seems unlikely. And If you want to be consistent across platforms then you dont want to expose the platform dependent types as template parameters. Hiding them in typedefs doesnt not remove them from the user code. Andy Little