[FEA] Gracefully accept scikit-learn-specific parameters in estimator APIs as pass-throughs

[beckernick]

Some estimators do not accept all parameters accepted by their corresponding scikit-learn estimator, while others do. For API compatibility, it would be nice to support these arguments to constructors as "pass-through" parameters and perhaps raise a warning or error if they are passed and not None. This additional API compatibility would improve the process of building cuML into downstream libraries and applications.

RandomForestClassifier and Regressor currently take this pass-through approach. cuDF takes a similar pass-through approach to pandas compatibility to enable using some methods with Dask, where these "unsupported" parameters are expected to be None (or the supported default).

Today, Random Forest takes an explicit, hard-coded approach to this task:

cuml/python/cuml/ensemble/randomforest_common.pyx

Lines 75 to 90 in 54ea23c

	sklearn_params = {"criterion": criterion,
	"min_weight_fraction_leaf": min_weight_fraction_leaf,
	"max_leaf_nodes": max_leaf_nodes,
	"min_impurity_split": min_impurity_split,
	"oob_score": oob_score, "n_jobs": n_jobs,
	"warm_start": warm_start,
	"class_weight": class_weight}
	for key, vals in sklearn_params.items():
	if vals:
	raise TypeError(
	" The Scikit-learn variable ", key,
	" is not supported in cuML,"
	" please read the cuML documentation at "
	"(https://docs.rapids.ai/api/cuml/nightly/"
	"api.html#random-forest) for more information")

@dantegd were chatting about this offline. Hard-coding to the current API is one way to do this. Another potential way he suggested to broadly enable this for other estimators might be to wrap this concept into a decorator that inspects the corresponding function signature.

[beckernick]

I suspect any solution would also need to innocuously handle the following scenario, which may call down to the Base class depending on the estimator implementation.

clf = Estimator()
clf.set_params(**{"n_jobs": None})

[github-actions]

This issue has been labeled inactive-30d due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d if there is no activity in the next 60 days.