Should complex numbers be closed at infinity by default?

[scheinerman]

Dividing a nonzero value by 0 should give an infinite result. This works fine for floating point numbers, but not for complex:

julia> 1. / 0.
Inf

julia> 1. / (0.+0.im)
NaN + NaN*im

Similarly, dividing by infinity (with a finite numerator) should give 0. This isn't working entirely properly:

julia> 1/Inf
0.0

julia> 1/(Inf*im)
0.0 - 0.0im

julia> 1/(Inf + 0*im)
0.0 - 0.0im

julia> 1/(Inf + Inf*im)
NaN + NaN*im         # this is wrong

Finally, in my opinion, there should be only a single ComplexInf value and not allow this:

julia> a = 3+Inf*im
3.0 + Inf*im

julia> b = 4+Inf*im
4.0 + Inf*im

julia> a==b
false

Both a and b should have evaluated to a common ComplexInf value. (We may also need a ComplexNaN.) Separate +Inf and -Inf is fine for Real values.

[andreasnoack]

Probably related: #5234

[jiahao]

There are two issues. The first is entirely a duplicate of #5234. The second is not a problem with how complex numbers are implemented, but rather a question of rather we want complex numbers to be closed at infinity by default.

[jiahao]

It is also good to cross-reference relevant threads on the mailing list.

Ref: julia-users.

[scheinerman]

I've posted an idea for how to handle here:
https://github.com/scheinerman/RiemannComplexNumbers.jl.git

[simonbyrne]

I think that both of the following are implementation bugs, and should be fixed:

julia> 1/(Inf + Inf*im)
NaN + NaN*im

julia> 1. / (0.+0.im)
NaN + NaN*im

From the C 2011 standard (with which we are generally trying to be compatible):

• if the first operand is a finite number and the second operand is an infinity, then the result of the / operator is a zero;
• if the first operand is a nonzero finite number or an infinity and the second operand is
  a zero, then the result of the / operator is an infinity.

@scheinerman I'm still not really convinced of the advantages of a single complex infinity: do you have a particular application in mind for which this would be better than the current behaviour?

[scheinerman]

Hi Simon,

It's a fair question: do I have an application in mind? Very short answer: No.

My perspective is that of a mathematician and how we might extend the (finite) complex numbers to include infinity. For the real numbers, extending with separate positive and negative infinities is fine. Having those two, and only those two, infinities for the complex numbers doesn't make sense. This leads us to a few reasonable choices. But for whatever we decide, having Inf+2im and Inf+3im as different values is not reasonable; they should compare as equal just like Inf+2 and Inf+3.

A single ComplexInf turns the complex plane into the Riemann sphere. This ComplexInf is the value returned by dividing any nonzero complex number by 0. Mathematically and aesthetically, I think this is the cleanest.

But if we wish to emulate +Inf and -Inf from the real case, we can imagine that every ray in the complex plane points to an infinite value (for the reals, there are only two ways a ray can point). Parallel rays point to the same infinity. So if we write complex numbers in polar coordinates, (r,theta) then the infinities are of the form (Inf, theta) where two complex infinities are equal iff their angles are the same modulo 2pi. Thus we have an entire circle of infinities added to the complex plane.

I also think that having a single ComplexNaN is a good idea. We could, of course use the existing NaN but that is of type Float64. I think the result of complex operations should always be a Complex type. This is what I have attempted to do here: [https://github.com/scheinerman/RiemannComplexNumbers.jl.git]

But I concede this: Efficiency and speed may well trump mathematical elegance. Having to do checks for every complex operation will slow things down. Folks that just want to do a bunch of complex arithmetic quickly in which infinities and/or NaN's are not going to crop up would not want this overhead. Hence my proposed solution is to create a package that a user may load that redefines Complex operations to behave well in the face of infinities and NaN's. Those who only want speed and for which this is an academic exercise simply wouldn't load the package, but those who are concerned about this can then ask for the more careful operations. And we could even have more than one way to do this: one with a single ComplexInfinity as I favor and another that would have an infinity for every parallel class of rays in the complex plane. (For those who like projective geometry, we could even have a third in which there is an infinity for every parallel class of lines.)

[eschnett]

There are probably arguments to be made either way. The Riemann sphere is very elegant, but treating complex numbers as a Cartesian pair of real numbers is also elegant.

I favour consistency between languages. Since e.g. C, C++, or maybe even Lisp define how infinities and nans should behave, we should follow suit. If we want to diverge, then this should be a large community-wide decision, and we may even want comments from the C and C++ standards committees to see why they decided their way.

The argument regarding "don't care about infinities and nans" is not valid. The IEEE standard defines very closely how these are handled, and by default, Julia follows this standard. We should attempt something equivalent for complex numbers, and not say "efficiency trumps everything for complex numbers". For example, there's always @fastmath or similar options for people who don't care about infinities and nans and signed zeros.

[jiahao]

In the julia-users thread referenced, I suggested yet another possibility where equality comparison could be redefined for complex numbers so that complex infinity could have multiple representations, but they would all compare equal.

==(z::Complex, w::Complex) = (real(z) == real(w)) & (imag(z) == imag(w)) #Argand plane

==(z::Complex, w::Complex) = if isinf(z) && isinf(w)
    return true #Riemann closure at infinity
else
    return (real(z) == real(w)) & (imag(z) == imag(w))
end

It might seem a little crazy, but redefining equality is actually not an unreasonable way to capture the notion of topological closure. This option just happens to be not usually possible in most languages.

Ref: JeffBezanson/phdthesis#4

[simonbyrne]

Hmm, this is an intriguing idea: the main downside would be the overhead of the branch.

The C standard seems fairly flexible when it comes to complex infinities: as above, it uses the phrase "an infinity" and "a zero" a lot. In case anyone is wondering, the C standard (like Julia) regards NaN + Inf*im as an infinity.

Any discussion of complex infinities cannot go without a reference to Kahan's article "Branch Cuts for Complex Elementary Functions or Much Ado About Nothing's Sign Bit".

We should probably also try to conform to ISO/IEC 10967-3:2006 "Language independent arithmetic -- Part 3: Complex integer and floating point arithmetic and complex elementary numerical functions" (free link from here), which specifies "general" behaviour of complex numbers in software (though it doesn't seem to say too much about infinities).

[jiahao]

@simonbyrne The language in the ISO standard mirrors much of the C99 spec. I found the C9X N557 draft more enlightening, as it was annotated with comments and discussions that were omitted from the final spec.

[simonbyrne]

Yes, I've looked briefly through other LIA specs and generally they are not all that enlightening, as they seem to be written so that almost all existing software would be conformant.

[scheinerman]

Hello again folks.

First, I was curious to see how C++ handles complex division by zero. So I wrote this:

#include <iostream>
#include <complex>
using namespace std;

main() {
  complex<double> zero = complex<double>(0,0);
  complex<double> one  = complex<double>(1,0);
  complex<double> eye  = complex<double>(0,1);
  cout << "1/0 = " << one/zero << endl;
  cout << "i/0 = " << eye/zero << endl;
  cout << "0/0 = " << zero/zero << endl;
  cout << "(1+i)/0 = " << (one+eye)/zero << endl;
}

and the output when run on my Mac is this

1/0 = (inf,nan)
i/0 = (nan,inf)
0/0 = (nan,nan)
(1+i)/0 = (inf,inf)

but when run on my Ubuntu linux machine I get something slightly different:

1/0 = (inf,-nan)
i/0 = (-nan,inf)
0/0 = (-nan,-nan)
(1+i)/0 = (inf,inf)

The negative nan values really surprised me.

So the fact that Julia evaluates (1+0im)/0 as Inf + NaN*im is consistent with C++.

Now Jiahao's idea of redefining == so all the manifestations of complex infinity merge together sounds good, but I think we'd need a bit more work because if z is any flavor of infinity, I'd want 1/z to be zero. This won't happen without more work:

julia> z = (1+0im)/0
Inf + NaN*im

julia> isinf(z)
true

julia> 1/z
NaN + NaN*im

By the way, this is something C++ gets right. Dividing (1,0) by (inf,nan) does yield (0,0).