> -----Original Message-----
> From: maxima-bounces at math.utexas.edu [mailto:maxima-
> bounces at math.utexas.edu] On Behalf Of Daniel Lakeland
> Sent: Wednesday, January 03, 2007 4:14 PM
> To: maxima at math.utexas.edu
> Subject: Re: [Maxima] romberg
>
> On Wed, Jan 03, 2007 at 02:36:14PM -0800, Richard Fateman wrote:
> >
> >
> > > -----Original Message-----
> > > From: Robert Dodier [mailto:robert.dodier at gmail.com]
> > .....
> > > Bigfloat arithmetic isn't much of an
> > > issue in numerical integration anyway; integration errors are
> > > typically several orders of magnitude larger than the floating point
> > > epsilon.
> >
> > I don't understand this. Bigfloat integration can get higher accuracy
> if
> > you carry more precision and adapt the algorithm. If you want to get a
> > value to 50 decimal places, what choice do you have?
>
> I think he meant that typically the error in an estimate of an
> integral computed using double precision is dominated by the
> truncation error inherent in the method rather than by the
> roundoff. So for a method designed for doubles, using bigfloat doesn't
> add anything much.
Any method designed specifically and only for doubles would be inappropriate
for bigfloats. There are methods that can be used for variable precision,
adjusting their convergence criteria based on the requested accuracy and
perhaps the precision of basic arithmetic. These generally produce
increasing accuracy for high precision (and more time, subdivisions, etc.).
They also sometimes find answers where lower precision does not converge at
all.
>
> I think most people using numerical integration are generally happy to
> have a double precision float's worth of accurate digits.
Maybe this is true for people taking programs out of netlib or using matlab.
In my experience this is not true, and that people who are told that they
can get more accuracy for more computation time, often try to get additional
digits. Especially when the integration method offers only an "estimate" of
accuracy, and when people want to integrate nasty functions and don't have
confidence in the numerical methods. Or the lower precision result is a
failure.
>
> Perhaps improving the documentation on quadpack, standardizing the
> interface with respect to multiple integrals, or creating a special
> multiple integral routine would be a better time investment.
I think that throwing away the bigfloat version of Romberg without replacing
it with a bigfloat version of some better numerical integration program
would be a bad choice. Both Maple and Mathematica have bigfloat numerical
integration.
Removing a feature from Maxima on the grounds that [someone thinks that]
most people are generally happy without it, would remove quite a few
features! :)
RJF