-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fit_*_random_forest: Drop parameter max_variables? #358
Comments
+1 for this one |
On the other hand, I don't see why the current definition is problematic. Back-ends can now choose which options they allow by adapting the schema/enum. |
We should avoid that, I think. It's bad for the user experience if there is divergence between the process docs at openeo.org, the docs of the python client (online or in the user's IDE) and the process definitions at openeo.vito.be. |
We have that in many places because it just doesn't work otherwise with the many underlying implementations. That's why we have the JSON Schemas in the first place, so that clients can actually adapt to it. Ideally, you'd implement everything, but that's not realistic (see recent issues about max_variables, ard processes, aggregate_temporal_period etc). Just search for "enum" in openeo-processes and you'll already find over 20 processes with a customizable enum. And this doesn't even include the "options" objects in some processes. The Python client diverges by design so I don't buy that argument. |
as touched in the dev telco today: it could also be an option to leave mtry/max_variables out of the spec for now (backends will be able to pick a good enough default behavior), and just introduce it when we are sure about how we are going to handle it
Originally posted by @soxofaan in #351 (comment)
The text was updated successfully, but these errors were encountered: