romberg-- replacement for bigfloat romberg

I looked at Sherry Li's papers again, and there are 2 things worth noting.
 
1. There is a version of ARPREC, which is comparable to MPFR (that is,
arbitrary precision floats) implemented in Fortran 90. So maybe it can be
run through f2cl.  (I have used ARPREC and its predecessor MPFUN in the
past; MPFR seems to have more of a following and in some timing tests is
faster. In favor of ARPREC (and QD), it is locally produced by friends and I
can sometimes get help :)  )

2. There is a version of ARBITRARY precision quadrature using ARPREC
(actually 3 programs) that could substitute for bf Romberg. The source code
is online.
http://crd.lbl.gov/~xiaoye/quadrature.pdf

Also, 

http://crd.lbl.gov/~dhbailey/mpdist  is the distribution page

There are problems for which each of the programs performs better.  Note
that there are also a bunch of papers, some by me, some by Keith Geddes, and
I think James Davenport on how symbolic math systems can reformulate
numerical integration problems to be easier to solve.  Typical kinds of
transformations are converting infinite endpoints to finite; averaging out
oscillations; removing singularities at endpoints by various tricks (e.g.
separating out an integrable part).

Is there anyone who cares about
 making this (a: arprec; b: Li's integration) work in Maxima? I believe that
part b can be done using existing bigfloats.

RJF







> -----Original Message-----
> From: maxima-bounces at math.utexas.edu [mailto:maxima-
> bounces at math.utexas.edu] On Behalf Of Richard Fateman
> Sent: Thursday, January 04, 2007 10:15 AM
> To: maxima at math.utexas.edu
> Subject: Re: [Maxima] romberg
> 
> I'm not especially defending the Romberg code, and deprecating the
> double-float version is fine, if it is really totally superceded by better
> stuff.  I am sure I can come up with problems that quadpack fails on, too.
> 
> It is not clear what you are advocating here, But  deprecating the
> (bigfloat) version of it seems to me would be a BIG mistake. What
> distinguishes Maxima from Fortran, C, Matlab ... is that numerical
> programs
> can, at least in principle, be run to arbitrary precision.  What
> distinguishes Maxima from MPFR is that the specification of calculations
> can
> be done interactively.  Deprecating the Maxima facility to do bigfloat
> integration is exactly the wrong direction.
> 
> 
> 
> There are other things to do: how about replacing bigfloats (which I
> wrote)
> by MPFR (which I did not write, but is actively under development and
> appears to be fast). I don't see offhand an MPFR numerical integrator (but
> one could be built with Romberg)..  Another possibility is to use
> quad-double integration which has been studied by Sherry Li:
> http://crd.lbl.gov/~xiaoye/fp.html
> 
> and could be put into my generic arithmetic package easily, and into
> Maxima
> too, though not without some effort. This brings up the foreign function
> interface issue in whatever CL you are using, as well as the cross-
> platform
> compilation issues for libraries --- which lack of standardization seems
> to
> be a disqualification for Maxima.  (I would prefer this to not be a
> disqualification, but I am unwilling personally to fix all lisps! And
> recompile everything in C or C++ for Mac, Linux, Windows, Solaris...)
> 
> RJF
> 
> 
> > -----Original Message-----
> > From: maxima-bounces at math.utexas.edu [mailto:maxima-
> > bounces at math.utexas.edu] On Behalf Of Daniel Lakeland
> > Sent: Thursday, January 04, 2007 8:02 AM
> > To: maxima at math.utexas.edu
> > Subject: Re: [Maxima] romberg
> >
> > > 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.
> >
> > I tend to think that the romberg code should stay as an alternative to
> > the quadpack, but that the third option (can't remember the name) is
> > superfluous since it performed worst among the three that Robert
> > tested. The Romberg code should be documented as having been
> > superseded for most purposes by quadpack.
> >
> > > 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! :)
> >
> > True enough. I think one of Robert's concerns is that it's not
> > completely robust, having failed some of his tests. If a bigfloat
> > version of quadpack were available it would probably be wise to
> > deprecate romberg as suggested. For now, perhaps it's best to
> > deprecate Romberg in the documentation but leave it available in the
> > code.
> >
> >
> > --
> > Daniel Lakeland
> > dlakelan at street-artists.org
> > http://www.street-artists.org/~dlakelan
> > _______________________________________________
> > Maxima mailing list
> > Maxima at math.utexas.edu
> > http://www.math.utexas.edu/mailman/listinfo/maxima
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima