BUG: special: overflow in hankel1 occuring a little too early

[person142]

Reproducing code example:

>>> import scipy.special as sc
>>> import mpmath
>>> v, z = 10, 1e-30
>>> with sc.errstate(overflow='warn'):
...     sc.hankel1(v, z)
...
__main__:2: SpecialFunctionWarning: scipy.special/hankel1:: overflow
(nan+nanj)
>>> complex(mpmath.hankel1(v, z))
(2.69114445546736e-310-1.1828049049433484e+308j)

Error message:

None

Scipy/Numpy/Python version information:

>>> import sys, scipy, numpy; print(scipy.__version__, numpy.__version__, sys.version_info)
1.4.0.dev0+9957ce7 1.17.1 sys.version_info(major=3, minor=7, micro=4, releaselevel='final', serial=0

Further details:

What's happening here is that Amos computes hankel1 function by using kv, so it reaches this line:

https://github.com/scipy/scipy/blob/master/scipy/special/amos/zbesh.f#L234

and checks whether kv would overflow at that point. The limiting form of kv is

0.5 * Gamma(v) * (0.5 * z)**(-v)

(see https://dlmf.nist.gov/10.30#E2), which does in fact overflow at that point, so Amos reports that the Hankel function overflows and bails out. The limiting form for hankel1, however, is the slightly different

-(i / pi) * Gamma(v) * (0.5 * z)**(-v)

(see https://dlmf.nist.gov/10.7#E7) which just barely doesn't overflow at that point.

We run into this situation because the smallest absolute value we test when using Arg() in test_mpmath is 1e-30, so if you try to set nan_ok=False in the Hankel function tests you get a failure. We can obviously fix the overflow, but there's a bit of a question as to where to put the fix (Amos is large and tangly), so I'm making this issue to keep track of what's happening.