Skip to content
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

Uniform integration measure for BQ #176

Merged

Conversation

mmahsereci
Copy link
Contributor

Issue #130 , if available:

Description of changes:
Structure for vanilla BQ integration against some measure. This PR only contains the uniform measure for simplicity. Gaussian will come later.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@codecov-io
Copy link

codecov-io commented Mar 18, 2019

Codecov Report

Merging #176 into master will decrease coverage by 0.92%.
The diff coverage is 71.42%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #176      +/-   ##
==========================================
- Coverage   90.05%   89.12%   -0.93%     
==========================================
  Files          99      100       +1     
  Lines        2583     2648      +65     
  Branches      255      264       +9     
==========================================
+ Hits         2326     2360      +34     
- Misses        214      244      +30     
- Partials       43       44       +1
Impacted Files Coverage Δ
emukit/quadrature/kernels/quadrature_kernels.py 81.48% <100%> (-0.67%) ⬇️
...kit/quadrature/acquisitions/squared_correlation.py 98% <100%> (ø) ⬆️
emukit/quadrature/kernels/quadrature_rbf.py 100% <100%> (ø) ⬆️
emukit/quadrature/interfaces/base_gp.py 75% <100%> (ø) ⬆️
emukit/model_wrappers/gpy_quadrature_wrappers.py 93.1% <100%> (ø) ⬆️
emukit/quadrature/methods/warped_bq_model.py 86.04% <100%> (+1.43%) ⬆️
emukit/quadrature/kernels/integral_bounds.py 100% <100%> (ø) ⬆️
emukit/quadrature/methods/vanilla_bq.py 63.04% <39.13%> (-36.96%) ⬇️
emukit/quadrature/methods/integration_measures.py 41.66% <41.66%> (ø)
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 324edde...19db29e. Read the comment docs.

@mmahsereci
Copy link
Contributor Author

Some additional explanation (to avoid confusion): The PR is also supposed to ensure that whenever the integration bounds are changed, it does so consistently, which has not been the case before. This is why there are some changes in other objects that use the integral bounds. There are also some tests which check if integral bounds are re-set correctly. All this was needed because the integration over the uniform measure is very easy to do by changing the integral bounds temporarily.


# setting new bounds also checks bound validity
self.integral_bounds = new_integral_bound_list
integral_mean_lebesgue, integral_var_lebesgue = self._integrate_lebesgue()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other approach would be to input integration_bounds to self._integrate_lebesgue() and then into all kernel methods that require the bounds instead of having the bounds as an attribute on the kernel. This would avoid needing to worry about the integration bounds setting and resetting. Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point, but I think that might cause bigger problems because then you need to make sure that whoever designs any integration method use the same bounds for all the methods of the kernel, which is very error prone. Having the attribute in the kernel (the only place where integration happens) avoids that. I'd rather make sure to write a nice setter.

Also, to be clear, I do not want the user to change the integral bounds. They are the parameter space and I see no point in changing them. It is just a way to internally do the uniform measure.

@javiergonzalezh javiergonzalezh self-requested a review April 2, 2019 10:38
Copy link
Contributor

@javiergonzalezh javiergonzalezh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work!

@mmahsereci mmahsereci merged commit d8d87fc into EmuKit:master Apr 2, 2019
@mmahsereci mmahsereci deleted the mmahsereci/integration-measures-for-bq branch April 2, 2019 10:42
apaleyes pushed a commit that referenced this pull request Dec 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants