Type unstable? about quadgk.jl HOT 10 CLOSED

Which Julia version are you running this on?

from quadgk.jl.

Well on 0.6.1 the return type was Tuple{Any,Any} as well as on 0.6.2.
Somehow I expect it to return Tuple{Float64,Float64} with real valued input.

from quadgk.jl.

Looks like Julia has never been able to infer this particular method; I checked in 0.4, 0.5, 0.6, and current 0.7. If that's the case I don't think there's much we can do here.

from quadgk.jl.

Well as a workaround one could use explicit typeassertion for the return value, but I don't know if that will hurt the performance.

from quadgk.jl.

I'm a bit confused.. so there is nothing we can do?
Thanks

from quadgk.jl.

It's certainly possible, it just requires someone tracking down the underlying issue and addressing it. 🙂

from quadgk.jl.

See JuliaLang/julia#18928

from quadgk.jl.

Confirming this is still the case

@code_warntype QuadGK.quadgk(x -> x*fx7(x), 0.0, 3.0)

Variables:
  #self# <optimized out>
  f::##63#64
  a::Float64
  b::Float64
  c <optimized out>

Body:
  begin 
      SSAValue(1) = (Base.Math.sqrt_llvm)(2.220446049250313e-16)::Float64
      SSAValue(0) = $(Expr(:invoke, MethodInstance for power_by_squaring(::Int64, ::Int64), :(Base.power_by_squaring), 10, 7))
      return $(Expr(:invoke, MethodInstance for do_quadgk(::##63#64, ::Array{Float64,1}, ::Int64, ::Type{Float64}, ::Float64, ::Float64, ::Int64, ::Base.LinAlg.#vecnorm), :(QuadGK.do_quadgk), :(f), :($(Expr(:invoke, MethodInstance for vect(::Float64, ::Vararg{Float64,N} where N), :(Base.vect), :(a), :(b)))), 7, Float64, :((Base.sitofp)(Float64, 0)::Float64), SSAValue(1), SSAValue(0), :(QuadGK.vecnorm)))
  end::Tuple{Any,Any}

from quadgk.jl.

From the doc:
The integrand f(x) can return any numeric scalar, vector, or matrix type, or in fact any type supporting +, -, multiplication by real values, and a norm (i.e., any normed vector space). Alternatively, a different norm can be specified by passing a norm-like function as the norm keyword argument (which defaults to vecnorm).

I think this might come from this, we don't have a common type for these, so the compiler has to fall back on any

from quadgk.jl.

#21 got irrelevant for most parts, and some parts are contested.
One work-around I would propose: dispatch on a special case when we are in one dimension and make this one type-stable, let the rest as-is.

from quadgk.jl.