Strange inference problems here

I’m seeing some weird behavior with respect to type inference. Here’s the code:

function SimpleGraph{T}(nv::Integer, ne::Integer; rng::AbstractRNG=GLOBAL_RNG) where {T<:Integer}
    tnv = T(nv)
    maxe = div(Int(nv) * (nv - 1), 2)
    @assert(ne <= maxe, "Maximum number of edges for this graph is $maxe")
    ne > div((2 * maxe), 3)  && return complement(SimpleGraph(tnv, maxe - ne))
    g = SimpleGraph(tnv)
    while < ne
        source = rand(rng, one(T):tnv)
        dest = rand(rng, one(T):tnv)
        source != dest && add_edge!(g, source, dest)
    return g
SimpleGraph(nv::T, ne::Integer; rng::AbstractRNG=GLOBAL_RNG) where {T<:Integer} =
    SimpleGraph{T}(nv, ne, rng=rng)

The problem comes in when I try to create a SimpleGraph(10, 20, rng=MersenneTwister(1)):

julia> @code_warntype SimpleGraphs.Graph(10,20, rng=MersenneTwister(1))
  #unused#::Core.Compiler.Const(Core.var"#kw#Type"(), false)               
1 ─ %1  = Base.haskey(@_2, :rng)::Core.Compiler.Const(true, false)                                                                                    
│         %1                                                                                                                                          
│   %3  = Base.getindex(@_2, :rng)::MersenneTwister                                                                                                   
│   %4  = (%3 isa LightGraphs.SimpleGraphs.Generators.AbstractRNG)::Core.Compiler.Const(true, false)                                                  
│         %4
└──       goto #3
2 ─       Core.Compiler.Const(:(%new(Core.TypeError, Symbol("keyword argument"), :rng, LightGraphs.SimpleGraphs.Generators.AbstractRNG, %3)), false)
└──       Core.Compiler.Const(:(Core.throw(%7)), false)
3 ┄       (@_7 = %3)
─       goto #5
4 ─       Core.Compiler.Const(:(@_7 = LightGraphs.SimpleGraphs.Generators.GLOBAL_RNG), false)
5 ┄       (rng = @_7)
│   %13 = (:rng,)::Core.Compiler.Const((:rng,), false)
│   %14 = Core.apply_type(Core.NamedTuple, %13)::Core.Compiler.Const(NamedTuple{(:rng,),T} where T<:Tuple, false)
│   %15 = Base.structdiff(@_2, %14)::Core.Compiler.Const(NamedTuple(), false)
│   %16 = Base.pairs(%15)::Core.Compiler.Const(Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}(), false)
│   %17 = Base.isempty(%16)::Core.Compiler.Const(true, false)
│         %17
└──       goto #7
6 ─       Core.Compiler.Const(:(Base.kwerr(@_2, @_3, nv, ne)), false)
7 ┄ %21 = LightGraphs.SimpleGraphs.Generators.:(var"#SimpleGraph#2")(rng, @_3, nv, ne)::Any
└──       return %21

SimpleGraph(10, 20) infers correctly (no type warning). Also weird:

julia> @edit SimpleGraphs.Graph(10,20, rng=MersenneTwister(1))
ERROR: could not determine location of method definition
 [1] error(::String) at ./error.jl:33
 [2] functionloc(::Method) at ./methodshow.jl:131
 [3] functionloc at ./methodshow.jl:141 [inlined]
 [4] edit(::Function, ::Any) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/InteractiveUtils/src/editless.jl:102
 [5] top-level scope at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/InteractiveUtils/src/macros.jl:15

Now, what’s even WEIRDER is that if I start my REPL session off with a SimpleGraph(10, 20), subsequent SimpleGraph(10, 20, rng=MersenneTwister(1))s infer correctly.

This issue is causing new type inference problems in the package. I hope I’m just overlooking something trivial. Any ideas?

Not sure about your case, but any time I see order-dependent inference issues, this comes to mind, which describes why some seemingly valid things in Julia won’t infer:

It seems plausible its that since since you’ve got SimpleGraphs recursively calling itself, which is at least one of the conditions to get what’s described there.

If its really this, a possible workaround I think might be to add precompile statements that cause inference to go through things in the order that works, which you could do at least for some of the concrete types you care about.

A quick update: annotating the return type solves the problem. But this doesn’t happen for the almost identical SimpleDiGraph constructor.

There shouldn’t be any recursion here.

I think there is, it looks like there’s at least one branch in your code above where SimpleGraph{T}(...) calls SimpleGraph(...) which calls SimpleGraph{T}(...) with the argument types being (Int,Int) in the first and last calls, so that’d be the part I’d be suspicious could be related to what’s decsribed in that blog post (but I don’t really know enough about this to be sure though).

sorry, I’m lost. Where is this branch?

Inside your SimpleGraph{T} function, you have a call to SimpleGraph(...) with two arguments (specifically in complement(SimpleGraph(tnv, maxe - ne))), and that in turn calls SimpleGraph{T} again.

You could try changing it to complement(SimpleGraph{T}(tnv, maxe - ne)) (ie add a {T}, and maybe to the other call as well) so SimpleGraph{T} is only calling itself, which that post seems to suggest is better.

1 Like

That was it, precisely. Thank you so much!

1 Like