You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The most natural way of representing this would be a tuple of length 2, one to choose the hyperparams, and the second for the actual value. This may not work in ConfigSpace, because the code base assumes that the vector representation has one value per hyper-parameter.
Another way to do this is to map the choices in UnionHyperparameter to different sections of the real line.
@mfeurer What are your thoughts on a UnionHyperparameter?
The text was updated successfully, but these errors were encountered:
Thanks for this suggestion. Indeed, having multiple types and ranges for single hyperparameter would be great to model spaces like the search space of scikit-learn. Can you think of any other use case of this feature?
Besides the issue you mentioned (ConfigSpace assumes that there's a one-to-one mapping between hyperparameters and the vector representation) it will also add a bit of burden on hyperparameter optimization packages using the ConfigSpace (okay, these are only two) because they need to implement additional logic to handle such union hyperparameters (vs. the hpo user currently having to implement this).
Currently the method to implement a "union" type is to use conditional hyperparameters:
It would be interesting to wrap this logic into a
UnionHyperparameter
datatype:The most natural way of representing this would be a tuple of length 2, one to choose the
hyperparams
, and the second for the actual value. This may not work in ConfigSpace, because the code base assumes that the vector representation has one value per hyper-parameter.Another way to do this is to map the choices in
UnionHyperparameter
to different sections of the real line.@mfeurer What are your thoughts on a UnionHyperparameter?
The text was updated successfully, but these errors were encountered: