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