Re: [boost] Geometry and spatial indexes, my opinion

Subject: Re: [boost] Geometry and spatial indexes, my opinion
From: Brandon Kohn (blkohn_at_[hidden])
Date: 2008-10-09 12:44:15

--------------------------------------------------
From: "Mathias Gaunard" <mathias.gaunard_at_[hidden]>
Sent: Thursday, October 09, 2008 11:19 AM
To: <boost_at_[hidden]>
Subject: Re: [boost] Geometry and spatial indexes, my opinion

> Brandon Kohn wrote:
>> //! Function to find the cross product between two vectors formed by the 
>> specified three points which share an endpoint at A.
>> template <typename Point>
>> point_traits<Point>::coordinate_type cross_product( const Point& A,
>> 
>> const Point& B,
>> 
>> const Point& C )
>
> Isn't the result of the cross product a vector/point?
>
>> {
>>   typedef cartesian_access_traits<Point > access_traits;
>>   boost::function_requires<Point2DConcept<Point> >();
>
> Isn't the cross product 3D-only?

No the cross product is not 3D only. It can be used to calculate the signed 
area of the parallelogram formed by 2D vectors (the length of the vector 
which *is* normal to the 2D plane has this value.) This is how it is used 
here to calculate the orientation using right hand rule convention. This 
particular implementation is just a 2D specialized version. I have another 
version for 3D. Higher dimensions could be written using an indexed access 
scheme. This is all not the point however. The point is that the mechanisms 
allow one to write the algorithms as they see fit for whatever underlying 
point type. Perhaps this notion is now a dead horse that has been repeatedly 
beaten.

> Anyway, wouldn't it be better to use SFINAE so that you can overload the 
> algorithm to make it work with other concepts?
>

This was done for clarity of my point. The actual version is implemented 
like this:

template <typename Point>
typename boost::enable_if< boost::is_same< typename 
point_traits<Point>::dimension_type, dimension_traits<2> >, typename 
point_traits<Point>::coordinate_type >::type cross_product( const Point& A, 
const Point& B, const Point& C )
{
  typedef cartesian_access_traits< Point > access_traits;
  boost::function_requires< Point2DConcept< Point > >();
  boost::function_requires< CartesianCoordinateAccessorConcept< 
access_traits > >();
  typename point_traits< Point >::coordinate_type cross =
  (
    ( access_traits::get_x( B ) - access_traits::get_x( A ) ) * ( 
access_traits::get_y( C ) - access_traits::get_y( A ) )
    - ( access_traits::get_x( C ) - access_traits::get_x( A ) ) * ( 
access_traits::get_y( B ) - access_traits::get_y( A ) )
    );
  return cross;
}

>
>> When I was talking about access like tuple, I meant using compile time 
>> indexing via the access traits. One of the main goals of my library is to 
>> facilitate use with legacy geometry code (proprietary in my case) simply 
>> by specializing access traits. Using access traits results in little 
>> constraint on the interface of the underlying point type.
>
> Are you aware of the Fusion sequence concepts?
> Any type can be made into a fusion sequence non-intrusively.
>
> So there is no need to recreate the get<N> machinery.
>

There is a need because the access_traits are what define the interface and 
the coordinate framework, not the point type. This is just an example of how 
it would be done for that fusion vector type. The access traits would be 
specialized differently for other types.

struct point { double x, double y }; for example would be specialized 
differently (and more complexly for the access traits class). If you are 
saying that fusion can be used to make a struct like this one into a 
sequence with get<I>.. then it seems there is nothing stopping one from 
implementing the access traits in terms of that.

To reiterate, the point isn't to say that fusion::vector3 makes a great 
concept for how one should define points or that one should constraint point 
types to use the get< Index >() interface. It is rather to say that the 
access_traits mechanism allows algorithm writers to accommodate both formats 
simply by specializing the access traits for whatever point type is used.

> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>