Re: [boost] Preview 2 of a template Geometry Library

From: Arash Partow (arash_at_[hidden])
Date: 2008-03-28 08:37:42

Barend Gehrels wrote:
 > Quite a statement. I limit my answer to this: the submission is a
 > preview, as mentioned in my posting.
I should not have been so brash, its just very exciting to see some
momentum in this topic again on the BOOST ML.

 > The distance of two integers may result in a floating point value.
 > Therefore distance returns a double. Internally, you will see, often,
 > the same numeric types or better is used as you describe. See
 > select_type_traits and large_type_traits.

I couldn't find one for the instance of distance, perhaps I wasn't looking properly,
in any case the simplest definition in my opinion could be:

template<typename point_type>
point_trait<point_type>::value_type distance(const point_type& p1, const point_type& p2);

btw will there be support for base value inputs?

template<typename T>
T distance(const T& x1,const T& y1, const T& y2,const T& x2);

 > Points of different types can be handled.
 > If you use a derived class, you have to provide an appropriate traits
 > class. It is not promoted. At least not in the compilers I use.
All the compilers I use do it quite easily.

class my_rational
{
public:
    my_rational(const int& i);
    my_rational& operator=(const int& i);
};

void foo(my_rational value){...}
{
    int i = 123;
    foo(i);
}

as per the example above if I provided a distance strategy/routine
using my_rational, then I should not need to do anything
else in order to be able to pass in a series of integers
into the routine - the result would of course be my_rational
but the class my also have a few cast operators to convert
into the various C++ PODs

 > Besides that, the library user might choose to specify a strategy.
Thats great, but consider me a really dumb user, I have 4 values
I've just read in from a file and i want to compute the euclidian
distance, I would like to be able to say the following without having
to worry about strategies or converting my values into point types etc:

dist = boost::geometry::distance(x1,y1,x2,y2);

In-fact to further this discussion before any proposal could be made,
one must consider the use-cases people will want to have. This concept
in comp-geo s/w is called layering and the computational issues
surrounding it are called folding ("Robustness In Geometric
Computations" [Hoffman01]) Above is just one of many use-cases (one of
the more important ones), there are others where the user will define a
type could be a POD could be something else, and a kernel, others may
want to also define mathematical operational variants (eg: new form of
addition or subtraction that is valid in their space) as you can see
we're still discussing the base types of the objects, not the objects
themselves let alone the policy nature of the higher level routines
eg: I want to compute a euclidean distance but my values represent
astronomical/cosmological values in a meter basis, what is the best
strategy here? - obviously as you suggested earlier a user defined
distance, but this stuff should come later.

There is so much to this topic, you indeed are very courageous to take
it on.

Regards,

Arash Partow
__________________________________________________
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
http://www.partow.net