Open jhj0411jhj opened 1 year ago
Hi @jhj0411jhj,
If you're adding code in the future, I highly recommend a PR. I think the scope of this is a lot more in line with the linked PR #280 which adds callable in forbidden relations. We also would not like to add a new kind of class just to enable one feature so this would have to be integrated into the main code itself.
Perhaps you can comment on the linked PR itself and see about getting this integrated there!
The intention of this issue is to provide an extention to others without modifying ConfigSpace code, which is written in cython and is a little hard for users to modify without downloading the source code. I didn't create a PR because I'm not very familiar with cython, and I'm afraid to make the code broken.
My implementation is more like a matter of expediency, rather than a perfect one. Implementing forbidden is a more compatible choice with current APIs, but might be complicated. I'll be happy to see such features to be supported in ConfigSpace.
Okay, I wasnt fully sure of your intentions but thanks for making them clear! Ill leave this open in the meantime but I guess there's no much that needs to be followed up from on our side for now. Thanks for the snippet!
I implement a
ConditionedConfigurationSpace
that supports complex conditions between hyperparameters (e.g., x1 <= x2 and x1 * x2 < 100). User can define asample_condition
function to restrict the generation of configurations.The following functions are guaranteed to return valid configurations:
Here is an example:
Implementing this feature using fobiddens like
ForbiddenClause
orForbiddenRelation
might be a viable option, but it's a little complicated, and user may need to pass the full config space to the forbidden object.The implementation does not consider serialization (of sample_condition function).
Here is the implementation of
ConditionedConfigurationSpace
: