Re: [boost] [geometry] robustness approaches

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]]
On
> 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
know why
> we need to bypass it with a free implementation.  Even so I don't depend
on gmp
> header files in my geometry library.  Instead I allow the "big" type to be
overridden by
> specializing a meta-function that looks it up.  I don't need to depend on
GMP header
> files in my library code to use GMP with my library in an application.
There is,
> 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
of the
> 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

---
Paul A. Bristow
Prizet Farmhouse
Kendal, UK   LA8 8AB
[phone], mobile [phone]
pbristow_at_[hidden]