Stricter `check_params` protocol for DA module would simplify debugging
Opened this issue · 1 comments
Describe the bug
ot.utils.check_params
is used rather heavily throughout ot.da
functions. The function itself checks for None
(s) in the input and returns False
if at least one was spotted. Now, there are 2 patters of how check_params
is used in the code that are somewhat hard to debug when argument passed is, in fact, "invalid":
fit
function works whencheck_params
returnsTrue
, otherwise just returnsself
(example). As there's no exceptions thrown, the downstream code safely assumes that fitting is done.transform
returns the result of the transformation only in casecheck_params
returnsTrue
, otherwise returnsNone
(example).
In both cases, it's rather hard to find the cause as the issue is only reported using print
statements.
Expected behavior
Suggestion here is rather simple: to follow stricter convention, for example similar to check_array
in sklearn. Throwing ValueError
in case invalid argument is provided seems to be safer option. What do you think? Happy to make a PR with the changes.
Make sens, we should also probably move check_param in ot.da and change its name that is too generic.