[J3] More Bessel functions

[Bill Long]

> On Jan 20, 2021, at 1:21 PM, Ondřej Čertík via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 
> 
> On Tue, Jan 19, 2021, at 7:26 PM, Steven G. Kargl via J3 wrote:
>> On Tue, Jan 19, 2021 at 02:49:59PM -0800, Van Snyder via J3 wrote:
>>> On Tue, 2021-01-19 at 12:28 -0700, Ondřej Čertík via J3 wrote:
>>>> On Tue, Jan 19, 2021, at 12:11 PM, Steven G. Kargl via J3 wrote:
>>>>> On Tue, Jan 19, 2021 at 10:45:22AM -0800, Van Snyder via J3 wrote:
>>>>>> On Tue, 2021-01-19 at 16:38 +0000, Nathan Sircombe via J3 wrote:
>>>>>>> They’re not implemented in libm as far as I can tell -
>>>>>>> https://www.gnu.org/software/libc/manual/html_node/Special-Functions.html
>>>>>>> 
>>>>>>> …so you don’t get them ‘for free’, although GSL has
>>>>>>> animplementation.
>>>>>> 
>>>>>> There are more things in heaven and earth, Horatio, than are
>>>>>> dreamt ofin your philosophy.There are more sources of freely-
>>>>>> available reliable mathematicalsoftware than libm.
>>>>> 
>>>>> Isn't your second sentence an argument against adding these
>>>>> functions to the Fortran standard?
>>>>> As Bill points out, Abramowitz and Stegun is a rather thickbook on
>>>>> special functions.  It is now updated and availablefor free at 
>>>>> https://dlmf.nist.gov.  The NIST site contains linksto software,
>>>>> e.g., https://dlmf.nist.gov/10.77.  Should theFortran standard
>>>>> include all of the functions covered by NIST?
>>> 
>>> The advantage of standards is they are, well, standard.
>>> One can find software for just about any special function. Typically
>>> several routines, with different interfaces.
>> 
>> I think that this is slippery slope.
>> 
>> I suspect that solving linear algebra problems far out
>> paces the need for BESSEL_I0(x), etc.  Should the Standard
>> include standardized interfaces for some, many, or all of
>> the BLAS and LAPACK routines?  Perhaps, the Standard should
>> include an intrinsic module named ISO_MATRIX that encapsulates
>> BLAS and LAPACK interfaces.
>> 
>> I also suspect forward and inverse FFTs far out pace
>> the need for BESSEL_I0(x).  Again, should the Standard
>> include standardized interfaces and an ISO_FOURIER intrinsic
>> module?  Should it only include radix-2 FFTs?  I would
>> advocate for Clive Temperton's prime factor FFT algorithms.

The (free) fftw package from MIT seems to have taken most of the mind-share in this area. 

> 
> Yes, Fortran needs a high quality implementation of all of these (and more), readily available to the user.

There are professionally written libraries, like NAG, already available.  Also LaPack for some cases.  Perhaps we should argue for robust Fortran interfaces instead, akin to the mpi_f08 module for MPI. 


> I would argue against putting all these into the Fortran standard today.

The feature list for F202X is already closed, so F202Y would be the soonest.  Even in the longer run, something like the add-on packages used by C/C++/Python might be a better strategy. 


> However, all these are in scope and planned for stdlib:
> 
> https://github.com/fortran-lang/stdlib/
> 
> And that is a great start to put all these, with a community discussed and agreed upon API, and a good (i.e., numerically accurate and fast) reference implementation (leveraging / reusing software that is already available whenever possible).

“accurate" and “fast" are often conflicting goals. 

Cheers,
Bill

> 
> Ondrej

Bill Long                                                                       longb at hpe.com
Engineer/Master , Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Hewlett Packard Enterprise/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425