Re: improving special functions in GSoC 2017

[Marco Caliari]

On Sun, 26 Jun 2016, Robert T. Short wrote:

> On 06/25/2016 11:52 PM, John W. Eaton wrote:
> > On 06/26/2016 02:08 AM, Colin Macdonald wrote:
> > > On 25/06/16 02:54, Marco Caliari wrote:
> > > > "Special functions are expected by users to just work".
> > >
> > > So I just found that our "besselj" gives NaNs for values like "1e10".
> > >
> > >  >> besselj(1, 1e9)
> > > ans = -5.21042264155388e-06
> > >  >> besselj(1, 1e10)
> > > ans = NaN + NaNi
> > >
> > >
> > > https://savannah.gnu.org/bugs/index.php?48316
> > >
> > >
> > > That's not some wild exotic function: its a common Bessel function!
> > >
> > >
> > > Why are we not just calling some free-licensed library that nails these
> > > things?
> >
> > Amos was the best thing I knew of at the time.  If there is something 
> > better now, or a standard library solution, then perhaps we should be using 
> > it.  Propose a patch and a test suite.
> >
> > jwe
> There was some discussion of this a few years ago (something like 2011 or 
> 2012).  At the time Amos was still the best option that we could find.  I 
> don't remember all the details, but other libraries (including boost) didn't 
> handle things like complex arguments or other some other crucial element.

Yes, for instance boost, GSL, and Cephes require both the arguments of 
gammainc to be nonnegative. Matlab allows x negative, and in this case the 
result is complex.

> Hopefully things have changed since then, but that was the conclusion at that 
> time.  I was not able to find that thread so my memory is not refreshed.  I 
> put in a bunch of tests at the time we had the discussion.  It seems, though, 
> that I didn't do any for complex arguments.  I have no clue how I missed 
> that.

Should we start with *the* list of special functions with the domain of 
application?

specfun1: A1 x B1 x ... x Z1 -> complex_field

where the domain is taken from the equivalent Matlab function.

Marco