Dropped NaN in hyperu function

[jacksonvanover]

When the third argument to the hyperu function is a NaN, the return is usually NaN. However, it is possible to choose first and second parameters such that the return is 1.

Reproducing code example:

Python 3.6.8 (default, Oct  7 2019, 12:59:55) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from scipy import special
>>> import numpy as np
>>> special.hyperu(0, 1, np.nan)
1.0
>>> special.hyperu(0, 2, np.nan)
nan
>>> special.hyperu(0, 1.1, np.nan)
1.0
>>> special.hyperu(0, 1.6, np.nan)
1.0
>>> special.hyperu(0, 1.9, np.nan)
1.0
>>> special.hyperu(0, 2.1, np.nan)
1.0
>>> special.hyperu(0, 2.2, np.nan)
1.0
>>> special.hyperu(0, 2.6, np.nan)
1.0
>>> special.hyperu(0, 3, np.nan)
nan
>>> special.hyperu(0, 7, np.nan)
nan
>>> special.hyperu(1, 7, np.nan)
nan
>>> special.hyperu(1235, 7, np.nan)
nan
>>> special.hyperu(0, 2.0, np.nan)
nan
>>> special.hyperu(1, 1, np.nan)
nan
>>> special.hyperu(1, 0, np.nan)
nan
>>> special.hyperu(1, 11, np.nan)
nan

Scipy/Numpy/Python version information:

1.4.1 1.17.4 sys.version_info(major=3, minor=6, micro=8, releaselevel='final', serial=0)

[jacksonvanover]

This appears to be the case for hyp1f1 as well

[peytondmurray]

Just addressed this issue in my PR. On a side note @jacksonvanover hyp1f1 appears to check for np.nan-valued arguments, and there is a test which has already been implemented which checks for this.

[jacksonvanover]

@peytondmurray, thanks for the follow-up! I realize that the hyp1f1 behavior I was referring to was from version 1.3.1 of scipy and has clearly been fixed. Thanks for your work!