Conflict with KernelDensity

[FedeClaudi]

Describe the bug
This is not a InfiniteOpt bug per se, but a situation in which using InfiniteOpt causes some headaches.
Basically, as discussed here, importing InfiniteOpt breaks KernelDensity.jl and any package that relies on it (e.g. AlgebraOfGraphics.jl).

To reproduce

import InfiniteOpt
import KernelDensity: kde
x = randn(1000)
kde(x) 

while

import KernelDensity: kde
x = randn(1000)
kde(x) 

alone works.

This is an example stacktrace:

Stacktrace:
  [1] _empty_reduce_error()
    @ Base ./reduce.jl:301
  [2] reduce_empty_iter(op::Base.BottomRF{typeof(Base.mul_prod)}, itr::Base.Iterators.Rest{Base.Generator{UnitRange{Int64}, AbstractFFTs.var"#17#18"{Tuple{Int64}}}, Int64}, #unused#::Base.EltypeUnknown)
    @ Base ./reduce.jl:358
  [3] reduce_empty_iter
    @ ./reduce.jl:356 [inlined]
  [4] foldl_impl
    @ ./reduce.jl:49 [inlined]
  [5] mapfoldl_impl
    @ ./reduce.jl:44 [inlined]
  [6] #mapfoldl#244
    @ ./reduce.jl:162 [inlined]
  [7] mapfoldl
    @ ./reduce.jl:162 [inlined]
  [8] #mapreduce#248
    @ ./reduce.jl:289 [inlined]
  [9] mapreduce
    @ ./reduce.jl:289 [inlined]
 [10] #prod#254
    @ ./reduce.jl:559 [inlined]
 [11] prod
    @ ./reduce.jl:559 [inlined]
 [12] #_reduce_by_first#211
    @ ~/.julia/packages/InfiniteOpt/xZSyh/src/nlp.jl:458 [inlined]
 [13] _reduce_by_first
    @ ~/.julia/packages/InfiniteOpt/xZSyh/src/nlp.jl:458 [inlined]
 [14] prod(itr::Base.Generator{UnitRange{Int64}, AbstractFFTs.var"#17#18"{Tuple{Int64}}}; kw::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ InfiniteOpt ~/.julia/packages/InfiniteOpt/xZSyh/src/nlp.jl:465
 [15] prod
    @ ~/.julia/packages/InfiniteOpt/xZSyh/src/nlp.jl:463 [inlined]
 [16] normalization
    @ ~/.julia/packages/AbstractFFTs/Ih3rT/src/definitions.jl:259 [inlined]
 [17] #plan_irfft#27
    @ ~/.julia/packages/AbstractFFTs/Ih3rT/src/definitions.jl:332 [inlined]
 [18] plan_irfft(x::Vector{ComplexF64}, d::Int64, region::UnitRange{Int64})
    @ AbstractFFTs ~/.julia/packages/AbstractFFTs/Ih3rT/src/definitions.jl:332
 [19] plan_irfft(x::Vector{ComplexF64}, d::Int64; kws::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ AbstractFFTs ~/.julia/packages/AbstractFFTs/Ih3rT/src/definitions.jl:285
 [20] plan_irfft(x::Vector{ComplexF64}, d::Int64)
    @ AbstractFFTs ~/.julia/packages/AbstractFFTs/Ih3rT/src/definitions.jl:285
 [21] irfft(x::Vector{ComplexF64}, d::Int64)
    @ AbstractFFTs ~/.julia/packages/AbstractFFTs/Ih3rT/src/definitions.jl:283
 [22] conv(k::KernelDensity.UnivariateKDE{StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}}, dist::Distributions.Normal{Float64})
    @ KernelDensity ~/.julia/packages/KernelDensity/2Ktu5/src/univariate.jl:139
 [23] kde(data::Vector{Float64}, weights::KernelDensity.UniformWeights{1000}, midpoints::StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, dist::Distributions.Normal{Float64})
    @ KernelDensity ~/.julia/packages/KernelDensity/2Ktu5/src/univariate.jl:152
 [24] kde(data::Vector{Float64}, dist::Distributions.Normal{Float64}; boundary::Tuple{Float64, Float64}, npoints::Int64, weights::KernelDensity.UniformWeights{1000})
    @ KernelDensity ~/.julia/packages/KernelDensity/2Ktu5/src/univariate.jl:159
 [25] kde(data::Vector{Float64}; bandwidth::Float64, kernel::Type, npoints::Int64, boundary::Tuple{Float64, Float64}, weights::KernelDensity.UniformWeights{1000})
    @ KernelDensity ~/.julia/packages/KernelDensity/2Ktu5/src/univariate.jl:173
 [26] kde(data::Vector{Float64})
    @ KernelDensity ~/.julia/packages/KernelDensity/2Ktu5/src/univariate.jl:171
 [27] top-level scope
    @ ~/Documents/Github/LocomotionControl/thesis/chpt3/fig3.ipynb:3
 [28] eval
    @ ./boot.jl:373 [inlined]
 [29] include_string(mapexpr::typeof(REPL.softscope), mod::Module, code::String, filename::String)
    @ Base ./loading.jl:1196
 [30] #invokelatest#2
    @ ./essentials.jl:716 [inlined]
 [31] invokelatest
    @ ./essentials.jl:714 [inlined]
 [32] (::VSCodeServer.var"#164#165"{VSCodeServer.NotebookRunCellArguments, String})()
    @ VSCodeServer ~/.vscode/extensions/julialang.language-julia-1.6.17/scripts/packages/VSCodeServer/src/serve_notebook.jl:19
 [33] withpath(f::VSCodeServer.var"#164#165"{VSCodeServer.NotebookRunCellArguments, String}, path::String)
    @ VSCodeServer ~/.vscode/extensions/julialang.language-julia-1.6.17/scripts/packages/VSCodeServer/src/repl.jl:184
 [34] notebook_runcell_request(conn::VSCodeServer.JSONRPC.JSONRPCEndpoint{Base.PipeEndpoint, Base.PipeEndpoint}, params::VSCodeServer.NotebookRunCellArguments)
    @ VSCodeServer ~/.vscode/extensions/julialang.language-julia-1.6.17/scripts/packages/VSCodeServer/src/serve_notebook.jl:13
 [35] dispatch_msg(x::VSCodeServer.JSONRPC.JSONRPCEndpoint{Base.PipeEndpoint, Base.PipeEndpoint}, dispatcher::VSCodeServer.JSONRPC.MsgDispatcher, msg::Dict{String, Any})
    @ VSCodeServer.JSONRPC ~/.vscode/extensions/julialang.language-julia-1.6.17/scripts/packages/JSONRPC/src/typed.jl:67
 [36] serve_notebook(pipename::String, outputchannel_logger::Base.CoreLogging.SimpleLogger; crashreporting_pipename::String)
    @ VSCodeServer ~/.vscode/extensions/julialang.language-julia-1.6.17/scripts/packages/VSCodeServer/src/serve_notebook.jl:136
 [37] top-level scope
    @ ~/.vscode/extensions/julialang.language-julia-1.6.17/scripts/notebook/notebook.jl:32
 [38] include(mod::Module, _path::String)
    @ Base ./Base.jl:418
 [39] exec_options(opts::Base.JLOptions)
    @ Base ./client.jl:292
 [40] _start()
    @ Base ./client.jl:495

As you can see, KernelDensity calls AbstractFFTs and this causes some InfiniteOpt code to be executed (around frame 14) which results in the error. If I understand it correctly InfiniteOpt re-defines this method:

prod(itr::Base.Generator{UnitRange{Int64}, AbstractFFTs.var"#17#18"{Tuple{Int64}}};...

which gets called in InfintieOpt has been imported.

This wouldn't be a huge problem, but in my case I'm trying to plot a KDE of some results, but loading/processing the data requires that my main module be imported and that makes use of InfiniteOpt, so I can't do the KDE.

[pulsipher]

Thanks for finding this. This is a bug with the nonlinear interface where we currently have some temporary hacky code to deal with efficient nonlinear sums and products. I will look into this and make a patch.

[FedeClaudi]

Thank you