Re: [boost] Preview 3 of the Geometry Library

Subject: Re: [boost] Preview 3 of the Geometry Library
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-10-20 14:15:31

Phil wrote:
>- I note that you're supporting homogeneous coordinates in arbitrary
>dimensions.  My current requirements are for at least partially
>heterogeneous coordinates in 2 or 3 dimensions.  Of course you can't
>support all permutations and combinations of requirements, but you
>should perhaps qualify some names to indicate their limited scope.

Can your coordinates cast to and from one coordinate type at the interface between your data structure and the algorithms provided by a generic library?

>- I have always used a very simple point type: struct point { T x; T y;
>};.  It seems that I could continue to use "user" code in this style
>with your library; however, as a potential library author, I need to
>replace "p.x" with something like "access<P>::get<0>(p)".  I'm not
>wildly enthusiastic about this verbosity.  I accept that I'm outvoted
>on this, but I'm going to continue to remind you (all) that I'm unhappy
>about it.

You only need to use the accessor function when you don't know the data type of the object.  If you are writing code within the library you can use std::pair<coordinate_type> for point and throw it in a vector and sort it and just get on with your life.  The accessors are just for the interfaces.

>- I have previously noted that you can advertise your distance function
>as returning a "type convertible to T" in order to avoid unnecessary
>sqrt calculations while, for example, scanning a list of points to find
>the one furthest from p.

I have a euclidean_distance_squared function on geometries that does what you say.  Distance calls distance squared and returns its square root.

>- I look forward to seeing concepts for shapes.
>- Is there a strategy for "within" that can be used when the shapes
>being tested store their bounding boxes?

I have a winding direction accessor function on my generic interface to unknown polygon type T.  If the polygon knows its winding direction in constant time it can return it, otherwise it returns unknown and I compute the winding direction.  A similar thing could be done for bounding box, where the cached bounding box can be returned in constant time.  Because these things make the interface bigger, I'd like to come up with a way to make them syntactically optional.  Any competent implementation of within on polygon would do bounding box comparison first to rule out simple cases.  Getting the bounding box would go to the bounding box accessor first and could get your cached bounding box to speed up the check.

Luke