Re: [boost] [geometry][units] Vector Class

Subject: Re: [boost] [geometry][units] Vector Class
From: Terry Golubiewski (tjgolubi_at_[hidden])
Date: 2010-05-19 21:59:36

Hello Barend,

I decided to remove boost::geometry from the implementation of my 
Vector/Point classes and instead focus on how to tell boost::geometry how to 
use my classes.
I've been using CGAL for a few years, so I'm "baby-duck" imprinted on that 
design.
I also used CGAL for affine transforms and some spherical conversions, so I 
hope to try boost::geometry for that functionality as well.
I really had a hard time understanding what a "geometry" was.
I expected a "geometry" to be a "system", rather than an object.
I also expected "points" to be referenced to a "reference frame" so that 
points that have difference reference frames cannot operate on one another 
without going through a transformation.
Much as in std::chrono, time_points from different clocks cannot be operated 
on together.  But durations, the difference of two time_points, are 
interoperable.
CGAL was also very difficult for me to learn because they use the concept of 
a "kernel".
Perhaps I'm not not geometry savvy, but I feel a need for a geometry library 
for dummies.
It seems a shame to keep coding "point/vector" over and over.  It reminds me 
of when I used to write linked-list-queues in C from scratch on every 
project...

I really missed going to BoostCon this year.
I hope you all had fun!
Thanks for all the hard work!

terry

----- Original Message ----- 
From: "barend" <barend_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Wednesday, May 19, 2010 3:40 PM
Subject: Re: [geometry][units] Vector Class

> Hi Terry,
>
>
> Op 19-5-2010 14:29, Terry Golubiewski schreef:
>> I imagine that using geometry/unit together will be common.
>> I just posted these files on boost-user too, but I wanted the 
>> geometry/units developers to see what I've done.
>> I think it was too difficult to make a Vector<quantity<U,T>> class.
>
> Agreed.
>
>> However, it could be done, so that is very good!
>
> The bad news is: the cartesian_distance class will go away. One of the 
> reasons is the one you showed in your attachment -- you actually have to 
> reimplement the whole strategy including return type. The good news is 
> that it will be simpler to implement, and actually the distance will have 
> the same measure as the coordinate system, so meters -> coordinate system: 
> meters -> distance: meters, no T*T vs sqrt(T) (or handled internally).
>
>>
>> The problem is that the geometry library assumes that the types of T*T 
>> and sqrt(T) is the same as T.
>
> Sure. During BoostCon I presented this "convertible to double" approach 
> (which is cartesian_distance) and Eric remarked that it might give 
> problems, using the return type in meta-programming, and indeed it does.
> Thanks for your efforts and sorry about the change needed in the near 
> future, but I hope it will be simpler indeed. I'm still not sure about it 
> anyway, the review report tells us to show how units can be integrated and 
> I envisioned it being in the coordinate system, not in the point type. So 
> I'll look more close into your implementation. Note also that a "vector" 
> is actually not part of Boost.Geometry but we hope that it can live apart 
> from it, e.g. as Emil's vector/matrix library, and work together (though 
> there is currently some vector arithmetic present).
>
>
> Regards, Barend
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>