Re: [boost] Library Proposal: Boost.Geom 2D and 3DGeometricPrimitives

From: Andy Little (andy_at_[hidden])
Date: 2005-07-02 07:59:05

"Anis Benyelloul" <benyelloul_at_[hidden]> 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