weird InexactError()

[autozimu]

OS: Mac OS X 10.8.4
Julia Version: Commit 05e64a1 2013-07-13 04:09:58

Am I doing something wrong, or is this a bug?

[aviks]

Looking at the code in array.jl,

This seems to occur due to

julia> typeof(real(zero(Complex)))
Int64

Defining

A=Array(Complex{Float64},1)

fixes the immediate issue, but I have no opinion on whether this issue should be considered a bug or not.

[ViralBShah]

zero(Complex) should certainly not be Complex{Int64}. At the very least, it should perhaps be Complex{Float64} to be consistent with the real case.

@autozimu If you use a concrete type like Complex128 instead of an abstract type like Complex, your example will work fine. We should ensure that it works either ways. Do note that it is more efficient to use a concrete type.

[StefanKarpinski]

I'm not sure that zero(::Type{Complex}) should be defined at all – there's no canonical value for that. Perhaps if we made it so that Complex{Bool} could replace the ImaginaryUnit type, then we could use Complex(false,false) for this.

[JeffBezanson]

Oh no not this again. Using Complex{Bool} as the imaginary unit is cute, but we would have false * Inf == 0. While that's convenient in some cases, it seems too magical to have a special zero that behaves differently from other zeros, I'd almost like to think of a way to justify that behavior but I haven't thought of anything yet.

[StefanKarpinski]

We could have Zero and One constants that are MathConst{0} and MathConst{1} or something like that and then make const im = Complex(Zero,One). I think this could be made to work correctly.

[JeffBezanson]

That would lead to the undesirable situation of a complex number whose components are of different types.

[JeffBezanson]

I also don't see how that solves the multiplying by Inf problem. Then MathConst{0} would be the special value, instead of false.

[JeffBezanson]

One option is to change complex multiplication so that Inf * complex(0,0) is NaN, but if one component is nonzero and the other is zero then the zero is left alone. After all complex(0,1) does not equal zero, so multiplying by Inf might not have to give NaN.

[stevengj]

I vote that we solve the issue at hand first. Why not simply define:

for f in (:real, :imag)
    @eval begin
        function ($f){T}(A::AbstractArray{Complex{T}})
            F = similar(A, T)
            for i=1:length(A)
                F[i] = ($f)(A[i])
            end
            return F
         end
    end
end
real{T<:Real}(A::AbstractArray{T}) = copy(A)
imag{T<:Real)(A::AbstractArray{T}) = zeros(T, size(A)...)

[ViralBShah]

Interestingly, trying your code (there is a typo in the last imag definition),

julia> A = Array(Complex,1)
1-element Complex{T<:Real} Array:
 #undef

julia> A[1] = 0.5 + 0.5im
0.5 + 0.5im

julia> real(A)
ERROR: no method real(Array{Complex{T<:Real},1},)

[JeffBezanson]

Yes; putting Complex{T} in the signature requires that the argument specify T, but the type Complex by itself does not.

[stevengj]

Whoops, I was thinking of Complex as equivalent to Complex{Real}. Just add:

         function ($f)(A::AbstractArray{Complex})
            F = similar(A, Real)
            for i=1:length(A)
                F[i] = ($f)(A[i])
            end
            return F
         end

[stevengj]

Of course, one also has to audit whether any other functions fall down for Complex arguments.