Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

Thank you for the review @viclafargue!

LGTM, but do we want to remove the float or double instantiation? Is there any argument for one side or the other?

Typically, it seems that we support float32 more often than double in other areas of the codebase? float32 also has a better memory footprint.

Also instead of branching before the C++ call, would it be possible to use the BaseEstimator features to have the output type automatically match the input type while ensuring that the arrays internally always match the type that we choose for C++ instantiations.

What is the process to enable the BaseEstimator features? So BaseEstimator automatically handles the casting of user input and output?

What is the process to enable the BaseEstimator features? So BaseEstimator automatically handles the casting of user input and output?

Like :

@cuml.internals.api_base_return_array(input_arg="shap_values", get_output_type=True)
def _explain_single_observation(self,
                                shap_values,
                                row,
                                idx,
                                l1_reg) -> CumlArray:

See estimator guide.

But, just realized that the dtype doesn't come from data dtype, but from SHAPBase argument. I guess this is fine to route the C++ calls that way if we are doing the rest of calculations in the self.dtype dtype.