Fix #11512 (disable computation for Complex BigInt/BigFloat type)

[lvnguyen]

We implement an explicit type checking and disable Complex{BigInt} and Complex{BigFloat}.
Currently only do for Bessel and Airy function.

[yuyichao]

Clarification on the way the error is raised. It is used to avoid the GC frame introduded due to string interpolation in the error branch. Another way is to have a non-inline function to throw the error instead.

[tkelman]

Note the style guidelines in CONTRIBUTING.md specify 4-space indent, not tabs. It's also preferable to use function syntax once the definition requires multiple lines.

[vtjnash]

In #11512, only BigFloat is mentioned. I don't know if Complex{BigInt} is broken, since the truncating convert should throw an error if it can't be represented in the target type.

[tkelman]

one of == or === should be used consistently here

[simonbyrne]

I think this would be handled via dispatch: for airy we should just get rid of the generic airy(k::Number, z::Complex) signature. Also, since the first argument is always an integer, it would probably make sense to change Number to Integer.

The Bessel case is a bit more complicated, but we should be able to do this via promote.

[yuyichao]

How can this work with the generic signature removed? I don't think we want to define airy(::Int, ::Complex{T}) individually for T equals to Int8, UInt8, Int16, UInt16 ......

[yuyichao]

And I think it is better to not define a method to raise error for BigFloat since it will prevent packages from providing this function without annoy warnings.

[simonbyrne]

How can this work with the generic signature removed? I don't think we want to define airy(::Int, ::Complex{T}) individually for T equals to Int8, UInt8, Int16, UInt16 ......

@yuyichao Why would we need to do that? We can just define

airy{T<:Integer}(k::Integer, z::Complex{T}) = airy(k, float(z))

[simonbyrne]

Actually, we could keep it generic, with just

airy(k::Integer, z::Complex) = airy(k, float(z))

[yuyichao]

There's also Rational{Int} etc... and I think a sane default in base is to promote to float for all types, while rasing error for big types in base but still allow more precise implementation to be provided by packages.

[simonbyrne]

Agreed, but we should be able to do this via dispatch, rather than have explicit branches in functions.

[simonbyrne]

What should work is:

airy(k::Integer, z::Complex) = airy(k, float(z))
airy(k::Integer, z::Complex{BigFloat}) = throw(MethodError(airy, typeof((k,z)))

[yuyichao]

No, it will make it impossible to support that in a package. The branch is written in a way that is constant folded away and generate not runtime overhead.

[simonbyrne]

How will that make it impossible to support? Just re-define Base.airy(k::Integer, z::Complex{BigFloat})

The whole point of multiple dispatch is that we don't need branches on types cluttering up our code!

[yuyichao]

It will give a warning.

[simonbyrne]

Is that a huge problem? I'm willing to pay that to avoid 6 lines of completely useless boilerplate code

Alternatively, we could do it via

airy(k::Integer, z::Complex) = _airy(k, float(z))

where _airy is the "internal" function

[simonbyrne]

For other functions which have the same problem (e.g. erfinv), we don't actually define fully-generic methods, just Integer ones.

[andreasnoack]

For other functions which have the same problem (e.g. erfinv), we don't actually define fully-generic methods, just Integer ones.

That doesn't seem right to me. A more generic solution would be something like airy(k::Integer, z::Number) = airy(k, promote_type(typeof(z),Float32))(z)).

[simonbyrne]

@andreasnoack That's the same as calling float, isn't it? The problem with that is that Complex{BigFloat} arguments get stuck in an infinite loop instead of throwing an error.

[yuyichao]

The whole point of multiple dispatch is that we don't need branches on types cluttering up our code!

Certain logic is still much cleaner when expressed as branches. This one can indeed use a float on the argument and only define the internal function for Complex64 and Complex128 and also promote Complex{Float16} in the way that is compatible to what we are doing now.

For promote_type, we'll want to promote it to Float64 (which is what we do now) and use the internal function _airy instead since it can be a infinite loop otherwise.

[yuyichao]

And if we do it this way, we should probably leave a comment about the intended behavior.

[andreasnoack]

You are right. Time for more coffee. I think an explicit MethodError method for Complex{BigFloat} is the best solution.

[simonbyrne]

Actually, a better solution might be

airy(k::Integer, z::Complex) = airy(k, float(z))
airy{T<:AbstractFloat}(k::Integer, z::Complex{T}) = throw(MethodError(airy, typeof((k,z)))

This should then (1) avoid throwing a warning if defined for BigFloat, and (2) make it easy to define new AbstractFloat types.

[simonbyrne]

I've made the changes in #15119 instead.