MAINT: improve error message for isposinf and isneginf on complex values

[jor-]

Fixes a bug in isposinf and isneginf for complex values (#11438) and adds additional tests for these functions with complex values.

[pv]

I'm not sure if these functions should be extended to complex dtypes. Positive and negative infinity don't really exist in the C99 complex number model that Numpy follows, in which there's only one complex infinity.

[mattip]

Interesting. We should at least raise an error that makes it clear this is by design.

@jor- how did you come across this code path, was it part of NumPy, an external library, or just exploring the limits of NumPy's complex handling?

[jor-]

Positive and negative infinity can be values in complex NumPy arrays so I think it makes sense that isposinf and isneginf work also for complex arrays.

@mattip: You mean how I found the bug? I use NumPy in one of my libraries to handle complex valued arrays. These arrays might also contain positive and negative infinity which need to be handled separately in my library.

[eric-wieser]

Positive and negative infinity don't really exist in the C99 complex number model

I think this model only makes sense if you provide the proj function to normalize the invalid complex infinities, which both C99 and C++11 have:

https://www.ideone.com/IpsC42

Perhaps that has a place in numpy?

[pv]

The thing about there being only one complex infinity is that e.g. the arithmetic just assumes it: ```

>> a = 1.0; b = 0.0 >> np.float_(a) / np.float_(b)

inf

>> np.complex_(a) / np.complex_(b)

(inf+nanj)

>> np.complex_(np.inf) * np.complex_(np.inf)

(inf+nanj) ``` For the first one, isposinf would give True, but for the second it would give False. Also, `isposinf(a) and isposinf(b)` would not imply `isposinf(a*b)`. This stuff is iirc according to spec, so it's not a bug.

[jor-]

In my opinion, inf is infinity and inf+nanj is not infinity, so isposinf is correct on this. It returns only True if the value is np.inf.

That isposinf(a) and isposinf(b) would not imply isposinf(a*b) is due to the specification of the arithmetic and in my option no reason not to implement isposinf for complex values.

[charris]

I don't think +/- infinity makes sense for complex values.

[eric-wieser]

In my opinion, inf is infinity and inf+nanj is not infinity

Unfortunately, your opinion carries less weight than the C99 standard, which seems to disagree with you

In order to support the one-infinity model, C99 regards any complex value with at least one infinite part as a complex infinity (even if the other part is a NaN)

Or at least, it dictates that inf + nanj is an infinity.

[jor-]

Okay, I did not know about that. Thank you for pointing this out. You have convinced me. With the one infinity model for complex values, the functions isposinf and isneginf are superfluous or are already covered by isinf.

What originally brought me to this problem was, that +inf and -inf can be stored in complex arrays and thus it looks like the complex plane with +inf and -inf and not the Riemann sphere with +inf only is used.

[mattip]

So the conclusion is that calling np.isposinf npisneginf should raise a Warning/Exception ?

[jor-]

I changed the code so that an exception is raised now if np.isposinf or np.isneginf is called with complex values.

The failures in the tests are due to connection errors. Can I restart the failing tests somehow?

[mattip]

as -> has, here and in the second docstring

[jor-]

changed

[mattip]

Tests that reach the exceptions are missing, you can use assert_raises(...

[codecov-io]

Codecov Report

Merging #11503 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master   #11503      +/-   ##
==========================================
+ Coverage    85.7%    85.7%   +<.01%     
==========================================
  Files         327      327              
  Lines       82002    82018      +16     
==========================================
+ Hits        70281    70297      +16     
  Misses      11721    11721

Impacted Files	Coverage Δ
numpy/lib/ufunclike.py	97.36% <100%> (+0.93%)	⬆️
numpy/lib/tests/test_ufunclike.py	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0df3563...b11b764. Read the comment docs.

[jor-]

I added a test. The tests passed. Only one failed due to a failure at Travis.

[mattip]

restarted the failing test, now all tests are green.

[eric-wieser]

Can you justify choosing valueerror instead of typeerror?

[eric-wieser]

The asanyarray breaks this function on duck-types...

[mhvk]

To avoid the duck-type issue with np.asanyarray and also ensure the functions do not become slower for the normal case where the inputs are not complex, I'd suggest using a try/except, catching the exception raised by signbit and then raising a more informative error message.

[mhvk]

As @eric-wieser notes, this leads to a change of behaviour for objects that implement __array_ufunc__ but cannot be converted to arrays.

[mhvk]

p.s. I changed the title of this PR to reflect the consensus that arose that these functions should not work on complex values.

p.p.s. I think this is a very nice example of how review makes things better! Thanks for starting it, @jor-!

[jor-]

@mhvk: I now use try/except instead of asanyarray.

@eric-wieser: I changed the error raised to TypeError instead of ValueError.

[mattip]

Thanks @jor-

[jor-]

Thanks for the reviewing.