Boost logo

Geometry :

Subject: [ggl] Polygon concept change and Boost.Polygon
From: Barend Gehrels (barend.gehrels)
Date: 2010-12-14 12:11:31


I propose to move this discussion to the Boost-dev mailing list as it is
not specific to Boost.Geometry.

Regards, Barend

On 14-12-2010 17:12, Simonson, Lucanus J wrote:
> I forgot to mention that the scaling function should accept a policy
> for whether to throw when snapping out of bounds floating point value
> to integer, with default being to throw.
> ------------------------------------------------------------------------
> *From:* ggl-bounces_at_[hidden]
> [mailto:ggl-bounces_at_[hidden]] *On Behalf Of *Simonson, Lucanus J
> *Sent:* Tuesday, December 14, 2010 7:50 AM
> *To:* Generic Geometry Library Discussion
> *Subject:* RE: [ggl] Polygon concept change and Boost.Polygon
> Yes. I view the polygon types I provide as incidental, I need them to
> implement the library, but the intention is for user defined polygon
> types to be used by users who have real applications and legacy type
> systems. For casual users the polygon types I provide are
> convenient. Eventually a user of both libraries should be able to
> adapt their type for a concept in one and then call a macro that
> adapts it to the concept in the other using the interface of the
> first. Then the user calls ggl::area(my_polygon) and
> gtl::area(my_polygon) freely. While we have some overlap there are a
> number of algorithms that exist in only one library or the other. The
> issue of floating point versus integer coordinate types remains
> problematic, of course, and will impede mixing and matching algorithms
> with each library. Perhaps we can write a integer-to-double and
> double-to-integer polygon interface adaptor that snaps to integer in
> one direction and casts to floating point in the other and make it an
> optional part of the glue between the concepts of the two libraries.
> That wouldn't be without its problems, but it would prevent the user
> from having to do it manually. A scaling factor could be looked up by
> a function call that would return 1.0 by default and provide a point
> of customization for the user to specify their own scaling. VLSI is
> measured in microns and we work in thousandths of microns. If the
> user wanted to use micron as their unit with ggl and scaled integer at
> the thousandth or ten thousandth of a micron with gtl that could be
> made automatic and transparent. The user might then prefer to call
> ggl::area() only because they prefer to see the area result in square
> microns while they might call gtl::perimeter because they like to see
> length in integer units of one thousandth of a micron.
> ------------------------------------------------------------------------
> *From:* ggl-bounces_at_[hidden]
> [mailto:ggl-bounces_at_[hidden]] *On Behalf Of *Bruno Lalande
> *Sent:* Tuesday, December 14, 2010 1:33 AM
> *To:* Generic Geometry Library Discussion
> *Subject:* Re: [ggl] Polygon concept change and Boost.Polygon
> So basically, your mean adapting the Boost.Polygon concept rather than
> one of its models, so that any model can work? I agree it would be
> even greater indeed. And the changes Barend just did about making the
> library return-semantic-agnostic should help a lot.
> Bruno
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]

Barend Gehrels
President Kennedylaan 1
1079 MB Amsterdam
The Netherlands
Tel: +31 (0)20 5711 335
Mob: +31 (0)6 175 447 62
Fax: +31 (0)20 5711 333
E-mail: barend.gehrels_at_[hidden]
Kvk-nummer: 33 207089
-------------- next part --------------
An HTML attachment was scrubbed...

Geometry list run by mateusz at