Subject: Re: [boost] [geometry] robustness approaches
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2009-03-20 04:55:05
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> Behalf Of Simonson, Lucanus J
> Sent: 19 March 2009 20:11
> To: boost_at_[hidden]
> Subject: Re: [boost] [geometry] robustness approaches
> Paul A. Bristow wrote:
> > I've been following this erudite discussion with interest and a modest
> > degree of understanding.
> > But one thing seems clear to me - that any quality implementation is
> > going
> > to require at the very least 'big' ints and 'big' floats, and
> > probably exact int and exact floats.
> > It would seem that we need tried and tested Boost license
> > implementations - preferably before starting work on a complex
> > geometry problem. No solution can be considered for Boost if it uses
> > any restrictive-licensed components.
> GMP is licensed under the LGPL. That's not such a bad license. I don't
> we need to bypass it with a free implementation. Even so I don't depend
> header files in my geometry library. Instead I allow the "big" type to be
> specializing a meta-function that looks it up. I don't need to depend on
> files in my library code to use GMP with my library in an application.
> incidently, a boost multi-precision library under development. Brandon
tried it out
> about a year ago. It is a tall order to get performance up to the level
of GMP, which
> uses inline assembly and clever C++ tricks to eliminate unnecesary copying
> heavy number types.
I'm sure GMP and mfpr are good.
But the license issue should be fully resolved before you/we get too far
down the line?
--- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk