Open ajgpitch opened 5 years ago
hi @ajgpitch . thanks for pointing out, this is definitely not something to expect from a well behaving library.
the problem now, however, is that gpyopt code has kind of grown since those lines were written 3 years ago, and it wouldn't be very realistic or practical to hunt down exact pieces of code that produce warnings and apply the good solution suggested in the Python docs. especially now when we don't develop GPyOpt any further, and focus our efforts on emukit.
we would be happy to apply some easy fix though, or consider a PR that fixes this issue properly. we can also consider enabling all warnings back, and reading some environment settings, and i'd rather think of these as the very last resort.
ideas?
Hi,
Thanks for getting back to me. I just turned warnings back on in my code. It's quite simple. I did get a few warnings from the BO about it being dangerous to set the data
object in some the dependent library (name escapes me now).
I think it would be best just to remove these lines and let the warnings appear. Someone may then be motivated to submit a PR to resolve those issues. Otherwise, at some point the the GPyOpt library could just start to not work for people and they have no idea why.
Users can always turn warnings off themselves if they don't want them.
Maybe you can also put something on the website if this emukit is somehow a replacement.
These two lines
in
methods/bayesian_optimization.py
mean that any code that imports GPyOpt does not show any warnings. This is not good practice. For instance it just cost me a few hours of my time trying to work out why valid warnings were not being issued.If there is some part of the code for which you wish to suppress warnings, then see: https://docs.python.org/3/library/warnings.html#temporarily-suppressing-warnings
Similarly this:
in
__init__.py
is also not good.