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

From: Barend Gehrels (barend_at_[hidden])
Date: 2008-03-25 17:08:23

Bruno,

Bruno Lalande wrote:
>> Herewith the URL to the second preview of Geodan's Geometry Library,
>> including documentation and examples.
>>     
>
> Hello,
>
> Thanks for this submission, I have compiled and run successfully all the
> examples provided, and had a quick look at the documentation and
> implementation. What I've seen until now is quite convincing :-)
>   
Good to hear!
> Here are a few remarks...
>
> * I think a lot of people will most often choose to initialize their points
> to 0. Maybe it would be better if the default behavior was init_zero, and to
> have an additional "init_none" value in the "init" enum, that could be used
> explicitly when needed? If non-init is the default, I'm already afraid about
> all the "uninitialized value" bugs that programmers will mistakenly
> produce...
>   
OK, it is no problem to change that of course.
> * Maybe the parameterized constructor of point should be declared explicit,
> since implicitly converting a scalar to a point is likely to be an
> unintended error.
>   
Good idea.
> * You could take advantage of the "dimension-agnosticness" of your point
> concept more than you're currently doing in your algorithms. For example, I
> have rewritten the pythagoras algorithm to make it dimension-agnostic, this
> way:
>
> template <typename P1, typename P2, size_t I, typename T>
> struct compute_pythagoras
> {
>     static T result(const P1& p1, const P2& p2)
>     {
>         T d = p2.template value<I-1>() - p1.template value<I-1>();
>         return d*d + compute_pythagoras<P1, P2, I-1, T>::result(p1, p2);
>     }
> };
>
> template <typename P1, typename P2, typename T>
> struct compute_pythagoras<P1, P2, 0, T>
> {
>     static T result(P1, P2)
>     { return 0; }
> };
>
> template <typename P1, typename P2 = P1>
> struct pythagoras
> {
>         static inline bool squared() { return true; }
>
>         inline distance_result operator()(const P1& p1, const P2& p2) const
>         {
>             typedef typename select_type_traits<typename
> P1::coordinate_type, typename P2::coordinate_type>::type T;
>
>             return distance_result(compute_pythagoras<P1, P2,
> P1::coordinate_count, T>::result(p1, p2), true);
>         }
> };
>
> This way you can use pythagoras either with a point_xy or with other point
> classes of higher dimensions. I've quickly made up a point_xyz class and it
> worked perfectly after having defined a strategy for it. Every algorithm
> doesn't have to be that generic, sometimes it just doesn't make sense. But
> for the simplest ones, and if it's not too much effort, I think it's worth
> it.
>   
Thanks for your close look and this well looking elaboration! I will 
replace it.

To be honest I've done some experiments, also with a polygon with a 
compile-time number of vertices. Called it the template <size_t D> gon, 
so a gon<3> for a triangle, etc. It disappointed me a bit because the 
compile-time area calculation routine which I drafted turned out to be 
slower than the runtime version... So it is interesting to test this 
with Pythagoras as well. However, it's looking beautiful like this.

Regards, Barend

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

-- 
-------------------------------------
Barend Gehrels
-------------------------------------
Geodan Holding b.v.
President Kennedylaan 1
1079 MB Amsterdam
The Netherlands
-------------------------------------
Tel: [phone]
Mob: [phone]
Fax: [phone]
-------------------------------------
E-mail: barend.gehrels_at_[hidden]
Website: www.geodan.nl
Disclaimer: www.geodan.nl/disclaimer
-------------------------------------