Issues using multithreading with Combinatorics

When I try to run the following code

using Combinatorics
using Base.Threads
five_letter_words = ["taxis", "deans", "krone", "unset", "other", "ovens", "spilt", "yanks", "flout", "clang"]
@threads :static for combo in combinations(five_letter_words, 5)
                     if length(intersect(combo)==0)

I get the following error

ERROR: TaskFailedException
 [1] wait
   @ ./task.jl:334 [inlined]
 [2] threading_run(func::Function)
   @ Base.Threads ./threadingconstructs.jl:38
 [3] top-level scope
   @ ./threadingconstructs.jl:97

    nested task error: MethodError: no method matching firstindex(::Base.Generator{Combinatorics.Combinations, Combinatorics.var"#10#13"{Combinatorics.var"#reorder#11"{Vector{String}}}})
    Closest candidates are:
      firstindex(::Any, ::Any) at ~/packages/julias/julia-1.7/share/julia/base/abstractarray.jl:396
      firstindex(::Tuple) at ~/packages/julias/julia-1.7/share/julia/base/tuple.jl:25
      firstindex(::Number) at ~/packages/julias/julia-1.7/share/julia/base/number.jl:88
     [1] (::var"#83#threadsfor_fun#8"{Base.Generator{Combinatorics.Combinations, Combinatorics.var"#10#13"{Combinatorics.var"#reorder#11"{Vector{String}}}}})(onethread::Bool)
       @ Main ./threadingconstructs.jl:70
     [2] (::var"#83#threadsfor_fun#8"{Base.Generator{Combinatorics.Combinations, Combinatorics.var"#10#13"{Combinatorics.var"#reorder#11"{Vector{String}}}}})()
       @ Main ./threadingconstructs.jl:52

Is this a multi-threading problem, a problem with the combinatorics package, or a problem between chair and keyboard?

Thank you for your help

combinations returns a lazy iterator, so there isn’t a defined length. The @threads macro partitions jobs based on the total number, i.e. length. If you call collect(combinations(...)), that will force the iterator to be realized as a vector.

However, if you’re looking to do something like the recent StandUpMaths video and want all 5-element combinations of a huge set, then you should be aware that the vector will be quite huge. So big in fact that the allocation might be more expensive than any boost you get from multithreading.

1 Like