Boost logo

Boost :

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

> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at