float(Complex{Integer}) should give a complex float

[ViralBShah]

float(Complex{Integer}) should give a complex float.

julia> float(1+im)
ERROR: InexactError()
 in convert at complex.jl:23
 in float at float.jl:46

[stevengj]

1+im cannot be converted exactly into a Real value, so InexactError seems correct to me. Note that float(Complex{Float64}) also throws an InexactError under the same circumstances, e.g. float(1.+im).

If the imaginary part is zero, so that the conversion is exact, then this already works: float(1+0im) and float(1.+0im) both give 1.0.

[vtjnash]

I think I agree with Viral that the return type should be Complex{Float64} instead of Float64. There doesn't seem to be a reason that float must return only the Real part, instead of the same value but represented as a floating point number.
e.g. float(1+im) => 1.0+1.0im

[JeffBezanson]

Yes, generally convert has the conservative behavior of raising errors, and the functions such as int() and float() convert forcibly since they are always called explicitly.

[ViralBShah]

I was looking at cases where BLAS operations are to be performed on non BlasFloat arrays. If float() worked on complex numbers as I suggested, then it would be really easy to have generic code. Otherwise, every function has to have a separate case to handle complex.

I always interpreted the float function name as something that converted the input to floating point types in a general sense, rather than something that should give Real values. Having convert to raise an error here, but having float do a forcible conversion would do the trick for me.

[JeffBezanson]

Yes that would be good. The whole point of a function like float64(x) as opposed to convert(Float64, x) is that it can do whatever we want, not constrained to convert to a specific type (Float64).