Passing return_std to predict

[evolbio]

Various Scikitlearn models accept return_std=true when calling predict, for example BayesianRidgeRegressor, see this example. For example, with a BayesianRidgeRegressor or similar machine, I would like to call
y_predict, y_std = predict(machine, X, return_std=true)
I am using MLJ to make calls through ScikitLearn.jl. I have looked through ScikitLearn.jl and MLJScikitLearnInterface.jl and do not see anyway to make this work, but maybe I am missing something simple like the right way to pass additional arguments? Thanks.

[evolbio]

Very helpful response from @tlienart at discourse, copied here:

You’re not missing something, there’s currently no way to pass that argument. It might be good to open an issue at MLJScikitLearnInterface to discuss this (and you could paste what follows).

I doubt that MLJ’s predict signature will be adapted to match this one but I’ll let @ablaom or @samuel_okon discuss that).

What could work is to pass the return_std as a new field of BayesianRidgeRegressor here MLJScikitLearnInterface.jl/linear-regressors.jl at 36882f14321e7e9889aac31447eeed0102eb052f · JuliaAI/MLJScikitLearnInterface.jl · GitHub

then pick that up at predict time here MLJScikitLearnInterface.jl/macros.jl at 36882f14321e7e9889aac31447eeed0102eb052f · JuliaAI/MLJScikitLearnInterface.jl · GitHub

this would also require ScikitLearn.jl to allow passing a return_std=true to predict, that might also require opening an issue there cc @cstjean

[cstjean]

Hi @evolbio. We're generally aiming to match the scikit-learn python interface, so supporting return_std=true would be perfectly in line. It might be as simple as adding a ; kwargs... somewhere. It would be a welcome contribution.

[tlienart]

This can be closed, it already works (I should have checked). This part of the code:

ScikitLearn.jl/src/Skcore.jl

Lines 70 to 104 in 9f15da6

	# Julia => Python
	api_map = Dict(:decision_function => :decision_function,
	:fit! => :fit,
	:fit_predict! => :fit_predict,
	:fit_transform! => :fit_transform,
	:get_feature_names => :get_feature_names,
	:get_params => :get_params,
	:inverse_transform => :inverse_transform,
	:predict => :predict,
	:predict_proba => :predict_proba,
	:predict_log_proba => :predict_log_proba,
	:partial_fit! => :partial_fit,
	:score_samples => :score_samples,
	:sample => :sample,
	:score => :score,
	:transform => :transform,
	:set_params! => :set_params)
	# PyCall does not always convert everything back into a Julia value,
	# unfortunately, so we have some post-evaluation logic. These should be fixed
	# in PyCall.jl
	tweak_rval(x) = x
	function tweak_rval(x::PyObject)
	numpy = importpy("numpy")
	if pyisinstance(x, numpy.ndarray) && length(x.shape) == 1
	return collect(x)
	else
	x
	end
	end
	for (jl_fun, py_fun) in api_map
	@eval $jl_fun(py_model::PyObject, args...; kwargs...) =
	tweak_rval(py_model.$(py_fun)(args...; kwargs...))
	end

shows that kwargs can already be passed to predict (and to all other api functions) without restrictions (L101-102) and, indeed:

using ScikitLearn
@sk_import linear_model: BayesianRidge
X, y = randn(100,2), randn(100)
reg = BayesianRidge()
fit!(reg, X, y)
ym, ys = predict(reg, X, return_std=true)

just works, kudos to @cstjean for thinking generic from the start.