https://github.com/GPflow/GPflow
Revision f3c511060ce62072a34a50319237d28b82d10448 authored by Vincent Dutordoir on 27 August 2020, 11:22:49 UTC, committed by GitHub on 27 August 2020, 11:22:49 UTC
* Update pull request template (#1510)

Clarify template to make it easier for contributors to fill in relevant information.

* Temporary workaround for tensorflow_probability dependency issue (#1522)

* pin cloudpickle==1.3.0 as temporary workaround for tensorflow/probability#991 to unblock our build (to be reverted once fixed upstream)

* Update readme with new project using GPflow (#1530)

* fix bug in varying_noise notebook (#1526)

* Fix formatting in docs (intro.md) and restore link removed by #1498 (#1520)

* pin tensorflow<2.3 tensorflow-probability<0.11 (#1537)

* Quadrature Refactoring (#1505)

* WIP: quadrature refactoring

* Removing old ndiagquad code

* deleted test code

* formatting and type-hint

* merge modules

* black formatting

* formatting

* solving failing tests

* fixing failing tests

* fixes

* adapting tests for new syntax, keeping numerical behavior

* black formatting

* remove printf

* changed code for compiled tf compatibility

* black

* restored to original version

* undoing changes

* renaming

* renaming

* renaming

* reshape kwargs

* quadrature along axis=-2, simplified broadcasting

* black

* docs

* docs

* helper function

* docstrings and typing

* added new and old quadrature equivalence tests

* black

* Removing comments

Co-authored-by: Vincent Dutordoir <dutordoirv@gmail.com>

* Typo

Co-authored-by: Vincent Dutordoir <dutordoirv@gmail.com>

* notation

Co-authored-by: Vincent Dutordoir <dutordoirv@gmail.com>

* reshape_Z_dZ return docstring fix

* FIX: quad_old computed with the ndiagquad_old

Co-authored-by: Vincent Dutordoir <dutordoirv@gmail.com>

* more readable implementation

Co-authored-by: Vincent Dutordoir <dutordoirv@gmail.com>

* tf.ensure_shape added

* removed ndiagquad

* removed ndiagquad

* Revert "removed ndiagquad"

This reverts commit 7bb0e9f1e0f2b0e225a2b8a5b3092c4c2f24ba91.

* FIX: shape checking of dZ

* Revert "removed ndiagquad"

This reverts commit 8e235241a697696e361158c30ff9aa9b4cc69f8a.

Co-authored-by: Gustavo Carvalho <gustavo.carvalho@delfosim.com>
Co-authored-by: ST John <st@prowler.io>
Co-authored-by: Vincent Dutordoir <dutordoirv@gmail.com>

* Add base_conditional_with_lm function (#1528)

* Added base_conditional_with_lm function, which accepts Lm instead of Kmm

Co-authored-by: Neil Ferguson <neil@prowler.io>
Co-authored-by: Vincent Dutordoir <dutordoirv@gmail.com>
Co-authored-by: st-- <st--@users.noreply.github.com>

* Fixed separate_independent_conditional to correctly handle q_sqrt=None. (#1533)

* Fixed separate_independent_conditional to correctly handle q_sqrt=None.

Co-authored-by: Aidan Scannell <scannell.aidan@gmail.com>
Co-authored-by: st-- <st--@users.noreply.github.com>

* Bump version numbers to 2.1.0. (#1544)

* Re-introduce pytest-xdist (#1541)

Enables pytest-xdist for locally running tests (`make test`) on multiple cores in parallel.

* check dependency versions are valid on CI (#1536)

* Update to not use custom image (#1545)

* Update to not use custom image

* Add test requirements

* Update parameter to be savable (#1518)

* Fix for quadrature failure mode when autograph was set to False (#1548)

* Fix and test

* Change shape of quadrature tensors for better broadcasting (#1542)

* using the first dimension to hold the quadrature summation

* adapting ndiagquad wrapper

* Changed bf for bX in docstrings

Co-authored-by: Gustavo Carvalho <gustavo.carvalho@delfosim.com>
Co-authored-by: st-- <st--@users.noreply.github.com>
Co-authored-by: Vincent Dutordoir <dutordoirv@gmail.com>

* Update min TFP supported version to 0.10 (#1551)

* Broadcasting constant and zero mean function (#1550)

* Broadcasting constant and zero mean function

* Use rank instead of ndim

Co-authored-by: st-- <st--@users.noreply.github.com>
Co-authored-by: joelberkeley-pio <joel.berkeley@prowler.io>
Co-authored-by: gustavocmv <47801305+gustavocmv@users.noreply.github.com>
Co-authored-by: Gustavo Carvalho <gustavo.carvalho@delfosim.com>
Co-authored-by: ST John <st@prowler.io>
Co-authored-by: Neil Ferguson <nfergu@users.noreply.github.com>
Co-authored-by: Neil Ferguson <neil@prowler.io>
Co-authored-by: Aidan Scannell <as12528@my.bristol.ac.uk>
Co-authored-by: Aidan Scannell <scannell.aidan@gmail.com>
Co-authored-by: Sandeep Tailor <s.tailor@insysion.net>
Co-authored-by: Artem Artemev <art.art.v@gmail.com>
1 parent acaccfd
Raw File
Tip revision: f3c511060ce62072a34a50319237d28b82d10448 authored by Vincent Dutordoir on 27 August 2020, 11:22:49 UTC
Release 2.1.0 (#1552)
Tip revision: f3c5110
CONTRIBUTING.md
# Contributing to GPflow

This file contains notes for potential contributors to GPflow, as well as some notes that may be helpful for maintenance.

#### Table Of Contents

* [Project scope](#project-scope)
* [Code quality requirements](#code-quality-requirements)
* [Pull requests and the master branch](#pull-requests-and-the-master-branch)
* [Tests and continuous integration](#tests-and-continuous-integration)
* [Documentation](#documentation)
* [Version numbering](#version-numbering)
    * [Keeping up with TensorFlow](#keeping-up-with-tensorflow)


## Project scope

With GPflow, we aim to make an extensible library for Gaussian processes which makes building complex models easy. In order to do this, we aim to make GPflow a complete library for doing inference and prediction in sophisticated ways (focussing mainly on variational inference) for *single layer models* only. In order to allow more complicated models to be implemented, we also provide functionality for latent / uncertain inputs. Other models, like deep GPs, can be implemented in their own repository by using GPflow as a dependency. We choose to limit the scope deliberately in order to ensure a high-quality codebase.

We welcome contributions to GPflow. If you would like to contribute a feature, please raise discussion via a GitHub issue, to discuss the suitability of the feature within GPflow. If the feature is outside the envisaged scope, we can still link to a separate project in our Readme.

### I have this big feature/extension I would like to add...

Due to limited scope we may not be able to review and merge every feature, however useful it may be. Particularly large contributions or changes to core code are harder to justify against the scope of the project or future development plans. For such contributions, we suggest you publish them as a separate package that extends GPflow. We can link to your project from an issue discussing the topic or within the repository. Discussing a possible contribution in an issue should give an indication to how broadly it is supported to bring it into the codebase.

### ...but it won't work without changes to GPflow core?

We aim to have the GPflow core infrastructure be sufficiently extensible and modular to enable a wide range of third-party extensions without having to touch the core of GPflow. The `inducing_variables` module is an example of this to enable interdomain approximations (multiscale inducing features, Fourier features, etc.). If your feature/extension does not work outside of GPflow-core because something is hard-coded, please open an issue to discuss this with us! We are happy to discuss and implement changes to the core code that make it easier for you to extend GPflow with a separate package.

## Code quality requirements

- Code must be covered by tests. We strongly encourage you to use the [pytest](https://docs.pytest.org/) framework.
- The code must be documented. We use *reST* in docstrings. *reST* is a [standard way of documenting](http://docs.python-guide.org/en/latest/writing/documentation/) in python.\
If the code which you are working on does not yet have any documentation, we would be very grateful if you could amend the deficiency. Missing documentation leads to ambiguities and difficulties in understanding future contributions and use cases.
- Use [type annotations](https://docs.python.org/3/library/typing.html). Type hints make code cleaner and _safer_ to some extent.
- Python code should generally follow the *PEP8* style. We use some custom naming conventions (see below) to have our notation follow the Gaussian process literature. Use `pylint` and `mypy` for formatting and _type checking_. GPflow project has a `.pylintrc` with some relaxed naming conventions.
- Practise writing good code as far as is reasonable. Simpler is usually better. Reading the existing GPflow code should give a good idea of the expected style.

### Naming conventions

Variable names: scalars and vectors start lowercase, but following the notation used in Gaussian process papers, all matrices are denoted with upper case. For example, `lengthscales` denotes a vector (i.e., rank 1, for example a tensor with shape [D]), whereas `Xnew` denotes a matrix (i.e., rank 2, for example a tensor with shape [N, D]; note that a [N, 1] tensor is a matrix, not a vector).

### Formatting

GPflow uses [black](https://github.com/psf/black) for formatting, calling it with `black -t py36 -l 100`. Simply run `make format` from the GPflow root directory.

## Pull requests

If you think that your contribution falls within the project scope (see above) please submit a Pull Request (PR) to our GitHub page.
(GitHub provides extensive documentation on [forking](https://help.github.com/en/github/getting-started-with-github/fork-a-repo) and [pull requests](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests).)

In order to maintain code quality, and make life easy for the reviewers, please ensure that your PR:

- Only fixes one issue or adds one feature.
- Makes the minimal amount of changes to the existing codebase.
- Is testing its changes.
- Passes all checks (formatting, types, tests - you can run them all locally using `make check-all` from the GPflow root directory).

All code goes through a PR; there are no direct commits to the master and develop branches.

## Tests and continuous integration

GPflow is ~97% covered by the testing suite. We expect changes to code to pass these tests, and for new code to be covered by new tests. Currently, tests are run by CircleCI and coverage is reported by codecov. Pull requests should aim to have >97% *patch* coverage (i.e., all the lines that are *changing* should be covered by tests).

## Documentation

GPflow's documentation is not comprehensive, but covers enough to get users started. We expect that new features have documentation that can help others get up to speed. The docs are mostly IPython notebooks (stored in the git repository in Jupytext format) that compile into HTML via Sphinx, using nbsphinx.

## Version numbering

The main purpose of versioning GPflow is user convenience.

We use the [semantic versioning scheme](https://semver.org/). The semver implies `MAJOR.MINOR.PATCH` version scheme, where `MAJOR` changes when there are incompatibilities in API, `MINOR` means adding functionality without breaking existing API and `PATCH` presumes the code update has backward compatible bug fixes.

When incrementing the version number, this has to be reflected both in `./VERSION` and in `./doc/source/conf.py`.

### Keeping up with TensorFlow

GPflow tries to keep up with API changes in TensorFlow as far as is reasonable, so that the latest GPflow will work with the latest stable TensorFlow release. Changing the version of TensorFlow that we're compatible with requires a few tasks:

- Update `README.md`
- Increment the GPflow version (see above).
back to top