power returns invalid complex number for negative base and Infinity as exponent

[balagge]

Following inputs return NaN - aNi in Notepad. Seems like all negative bases yield the same:

(-0.5)^Infinity
(-1)^Infinity
(-2)^Infinty

probably the underlying function pow() returns a Complex with both Real and Imaginary part set to NaN. (haven't checked).

Definitely, NaN + aNi is wrong. But whether this is simply an issue with the rendering, or the underlying logic, is to be analyzed. Some thoughts:

• Whether the result should be a Complex with both Real and Imaginary parts set to NaN, is questionable (after all there is a NaN already, no need to introduce a "second, complex NaN" value maybe).

• for -1 < a < 0, the result should probably be zero, as in javascript, this one converges: Math.pow(-0.5,Infinity) // 0

• for a < -1 the result should not be Infinity (so, unlike javascript), because this is clearly divergent. (I don't understand javascript behavior: Math.pow(-2,Infinity) // Infinity

• -Infinity as exponent should also be considered (currently these cases also return incorrect NaN + aNi, but convergence / divergence should also be considered separately for -Infinity)

[josdejong]

Thanks for reporting Paal. That NaN - aNi looks like a formatting issue. Besides that we can definitely give these edge cases with NaN and infinity some more thought. We should keep in mind that we're working with a numerical system (with it's limitations).

[harrysarson]

I had a look into this: the pow function checks if the base is positive or the exponent is an integer or config.predictable = true and if so returns the result of Math.pow. Otherwise the pow function of Complex.js is used which returns Nan + NaNi for infinite exponents.

Therefore with config.predictable = true negative bases raised to the power of infinity return either Infinity or zero.

I feel that the behaviour should not change in this way regarding config.predictable so it would be worth adding a check for infinite exponents to the pow function.

[josdejong]

@harrysarson would you like to pick this issue up?

[harrysarson]

Sure I can have a go :)

[josdejong]

👍 thanks

[harrysarson]

What are your views on the best result for (-2)^Infinity?

• a) Infinity as javascript, matlab and c++ all go for.
• b) Not infinity as @balagge says - possibly NaN?.
• c) Some sort of ComplexInfinity which how it is done in wolfram alpha.

I feel like (c) is the most elegant solution but would require either a new type or and extension of complex.js. (a) and (b) are much easier to do.

Additionally the behaviour of complex.js is currently to return (NaN + NaN * i) for any infinite powers - it would be nice if math.pow(2, Infinity).toString() === math.pow(math.complex(2), Infinity)).toString() so I might raise an issue with complex.js for better support for infinities.

[josdejong]

I think returning complex infinity for (-2)^Infinity would be most neat, or else complex NaN like it does now.

[infusion]

For complex numbers NaN can make sense, since the the power function is defined via sin/cos and sin(inf)=nan. However, if we think about it, pow(c∈C, inf) is an infinite rotation of an arrow. With this interpretation, Infinity would make sense too. However, I would go with a new "symbol" - "complex infinity" as well.

I made some minor changes on complex.js regarding the infinity behavior. I'd be glad if you guys could have a look: rawify/Complex.js#5

[infusion]

Ah, and about the printing error, I catch NaN's in complex.js's toString(). I suspect, that we added an own stringifier for math.js.

[josdejong]

I've fixed the wrong formatting of NaN + aNi which should be NaN + NaNi. math.js indeed still overwrites the .toString of Complex.js. Maybe that's not needed at all. Let's check that out.

Sounds good @infusion . It may make sense to create a special constant complex infinity rather than using Infinity. It may make sense to create this as a constant in math.js: math.ComplexInfinity, which would simply be the new Complex.Infinity constant of Complex.js. Probably we can do the same for complex NaN: ComplexNaN?

[infusion]

@josdejong for "NaN + NaNi", I decided for complex.js to make the whole complex-number NaN as soon as one component becomes NaN. So, the output is "NaN". I think this lacks some information in the output, but at the end it's just a feedback, that an operation failed, other than for infinity, where the individual dimensions can become infinity with a certain meaning.

Mapping Complex.Infinity to math.ComplexInfinity sounds good to me :)

ComplexNaN is still a big question. We actually use complex numbers to make Math.sqrt(-1)!=NaN work. There're only rare discontinuities where NaN can occur. That are 0/0 and the strange case when 0*Infinity is NaN in Javascript, which we can fix. For my last push to the "infinity" branch of complex.js, I decided to make 0/0 complex infinity as well, since I don't like to introduce a new symbol for that.

What do you guys think?

[balagge]

I think complex infinity is a great idea. Complex infinity is different from "real" infinities Infinity and -Infinity, because those have directions on the complex plane, whereas complex infinity is directionless.

Complex infinity (denoted by I below) should satisfy:

• I + z = I, for any z ∈ ℂ;
• -I = I (UNLIKE real Infinities!!);
• I * I = I;
• I * z = I for any z ∈ ℂ, z ≠ 0;
• z / I = 0 for any z ∈ ℂ, z ≠ 0;

Edge cases:

• I + I is not defined (NaN), UNLIKE real Infinities!;
• 0 * I is not defined (NaN?)
• I / I is not defined (NaN?)
• I - I is not defined (NaN?)