log(im) not implemented

[dlfivefifty]

log(im)
no method log(ImaginaryUnit)
while loading In[39], in expression starting on line 1

But log(1.im) works.

[ivarne]

See #4922, for some discussion about why we have this situation.

[dlfivefifty]

Maybe it’s better to overwrite log(im) and throw an error?

On 4 Jan 2014, at 7:02 pm, Ivar Nesje notifications@github.com wrote:

See #4922, for some discussion about why we have this situation.

—
Reply to this email directly or view it on GitHub.

[ViralBShah]

Closing this as a dup of #4922. The discussion can continue there.

[ivarne]

Closing as a dup of a closed PR?

[ViralBShah]

Oops, I didn't realize that the PR was also closed.

[johnmyleswhite]

I think they're all supposed to be closed as we decided not to treat a standalone im as a number.

[ViralBShah]

Perhaps we should note this in our documentation, before closing this.

[ivarne]

Yes, and this issue is now (as so many other issues) about giving a better error message. It seems that MethodError is not the most friendly introduction to Julia, and it indicates that fixing the problem involves implementing more methods, when there is a well discussed design decision behind the behavior.

[jiahao]

There is a genuine issue about im left unresolved. I presume im's behavior was meant to mimic Kahan's proposal for an imaginary type (which Julia doesn't have).

Although in #4922, @JeffBezanson wrote that the alternative to current behavior would lead to problems like:

maybe we should just live with the NaN problem and let im == complex(false,true)

However, we already have these problems and so have the worst of both worlds at the moment (where functions over im are undefined and should stay that way). Note that this equality already holds true now

julia> im==complex(false,true)
true

I assume the NaN problem refers to the issue which Kahan points out [pdf], namely that automatically promoting all operations on (Real, Complex) operands produces bad computations sometimes, like

julia> 4*complex(Inf, 5)
Inf + 20.0im

julia> complex(4,0)*complex(Inf, 5)
complex(Inf,NaN)

While this works correctly for (Real, Complex), it doesn't work on imaginary*Complex:

julia> 4im*complex(Inf,5) #Expect complex(-20,Inf)
NaN + Inf*im

or in other words, that the current arithmetic rules obtained via type promotion retain half the "NaN problem".

This can be fixed fairly simply with parentheses, viz.:

julia> 4(im*complex(Inf,5))
complex(-20.0,Inf)

so it could be simply an order-of-operations issue. (and similarly with division)

For addition and subtraction, however, I don't see how to rescue the sign-of-zero problem without special casing:

julia> 4.0 + complex(5.0, -0.0)
9.0 - 0.0im

julia> complex(4.0) + complex(5.0, -0.0) #0.0 + (-0.0) == 0.0
9.0 + 0.0im

julia> 4.0im + complex(-0.0, 5.0) #expect -0.0 + 9.0im
0.0 + 9.0im

[StefanKarpinski]

I fairly strongly support the addition of a purely imaginary type. I suspect that we can define im as Imaginary(1) or maybe Imaginary(true).

[jiahao]

Since Imaginary would have to have a Number parameter, would defining im as Imaginary(true) incur cost in type promotion?

[StefanKarpinski]

No, I don't think so. I'm actually working on a pr for this, so we'll see how it works out.

[StefanKarpinski]

See #5313.

[JeffBezanson]

We would still face the question of whether to implement every function for the Imaginary type.

Half seriously, would we define Complex{T} as something like CompoundNumber{T,Imaginary{T}}?

[stevengj]

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

[jiahao]

Looks like the lack of a pure imaginary type continues to haunt us; c.f. #9531