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
If you do ExpSquaredKernel(metric=30, metric_bounds=[(10, 100)]) it will fail with an unhelpful "non-finite log prior value". Why? Because the initial value is 30, but the bounds are e^10 and e^100, which doesn't include the initial value. Same applies if you do Metric(30, bounds=[(10, 100)], ndim=1). You really wanted to write ExpSquaredKernel(metric=30, metric_bounds=[(np.log(10), np.log(100))]).
It would be nicer to change the interface (either to take the bounds as linear and take the log internally, or rename the arg as log_metric_bounds) but that would be a breaking change, so perhaps you could just clearly document the existing behavior and provide an example?
Also, the code that produces that "non-finite log prior" message knows that it's doing a bounds check, so how about making the message something more like metric prior value 30 outside of bounds [22026.46579, 2.68811714e+43] which would tip people off as to where things went wrong.
The text was updated successfully, but these errors were encountered:
Yeah - that interface is all a little janky! All of these suggestions are good. I don't have a huge amount of time for george maintenance these days, but I'd be very happy to review a PR.
If you do
ExpSquaredKernel(metric=30, metric_bounds=[(10, 100)])
it will fail with an unhelpful "non-finite log prior value". Why? Because the initial value is 30, but the bounds are e^10 and e^100, which doesn't include the initial value. Same applies if you doMetric(30, bounds=[(10, 100)], ndim=1)
. You really wanted to writeExpSquaredKernel(metric=30, metric_bounds=[(np.log(10), np.log(100))])
.It would be nicer to change the interface (either to take the bounds as linear and take the log internally, or rename the arg as
log_metric_bounds
) but that would be a breaking change, so perhaps you could just clearly document the existing behavior and provide an example?Also, the code that produces that "non-finite log prior" message knows that it's doing a bounds check, so how about making the message something more like
metric prior value 30 outside of bounds [22026.46579, 2.68811714e+43]
which would tip people off as to where things went wrong.The text was updated successfully, but these errors were encountered: