Define functions for ImaginaryUnit

[magistere]

Now many common functions are not defined for imaginary unit im that has separate type (not Complex).

julia> sin(im)
ERROR: no method sin(ImaginaryUnit,)

julia> sqrt(im)
ERROR: no method sqrt(ImaginaryUnit,)

This pull request defines missing methods with ImaginaryUnit argument.

[johnmyleswhite]

I believe we had historically agreed not to do this, because every function we implement in this way leads to the erroneous impression that we're committed to making all functions work on im.

[JeffBezanson]

I agree, and we still have the problem that !isa(im,Complex). Maybe we need a special Real type T such that zero(T)*Inf == 0, and then use a Complex{T} as im? Or maybe we should just live with the NaN problem and let im == complex(false,true). There doesn't seem to be a way to define im that obeys every identity you might expect; for example im does not behave the same as complex(real(im),imag(im)).

[StefanKarpinski]

Thanks anyway for the pull request, @magistere – it seems like this is a deeper problem than missing functions :-(

[JeffBezanson]

One way to think about the problem is that im can be designed for use in syntax like 1+2im, or it can be designed for use as a value like pi. Given that you can't have every identity you might want, you have to pick one of those two uses to prioritize. We picked the first one; our im is basically just for multiplying. Instead of passing im, you need to use 1im, which is pretty similar to what's done in other languages with syntax for complex numbers.

[magistere]

I understand that defining these functions is oversimplified solution to the problem. My initial motivation was to make it work like in MATLAB.
I think that allowing only multiplication im with numbers will be good enough solution. But now other arithmetic operations are also allowed:

julia> im+2
2 + 1im

julia> im/2
0.0 + 0.5im

julia> im^3
0 - 1im

And these operations are not defined when both arguments are of ImaginaryUint type:

julia> im+im
ERROR: + not defined for ImaginaryUnit
 in + at promotion.jl:178

julia> im/im
ERROR: / not defined for ImaginaryUnit
 in / at promotion.jl:181

julia> im^im
ERROR: ^ not defined for ImaginaryUnit
 in ^ at promotion.jl:182

Maybe it will be better to forbid all operations with im besides multiplication?

[JeffBezanson]

It is getting those operations via the type promotion mechanism. Given the intended use, it might be reasonable to allow only multiplication, but we used promote_rule to get the more general "allow combining with different types". With 1-argument functions there is no combining of course, so this concept doesn't help there.

[stevengj]

Fixed by #5468, since im is now a Complex type and gets promoted to Complex{Float32}.

[magistere]

Stefan, thank you for finally getting rid of ImaginaryUnit.