Skip to main content

Browse the archive

https://github.com/GPflow/GPflow
21 November 2022, 03:07:34 UTC
Revision 9d238398ce11b8beaad3811e67bfa7de006d79d5 authored by st-- on 20 June 2018, 14:59:06 UTC, committed by James Hensman on 20 June 2018, 14:59:06 UTC 
Notebook to demonstrate advanced usage such as combining GP with Neural Network (#712)
 
* added notebook

* added vanilla conv net accuracy

* Tidy up notebook

* ran notebook

* ran notebook #2

* add untested notebooks to test_notebooks

* fix bug in natural_gradients notebook

* add nb_niter and nb_range to only run a small number of iterations in continuous integration notebook tests

* make advanced_usage.ipynb use nb_iter()

* don't add natural_gradients.ipynb and upper_bound.ipynb notebook tests in this PR

* make advanced_usage run faster in CI

* clean up advanced_usage

* Update test_notebooks.py

* fix notebook_niter

* missing input_dim for CI

* update notebook

* another reset_default_graph_and_session call
1 parent 3a16991
Raw File
Tip revision: 9d238398ce11b8beaad3811e67bfa7de006d79d5 authored by st-- on 20 June 2018, 14:59:06 UTC
Notebook to demonstrate advanced usage such as combining GP with Neural Network (#712)
Tip revision: 9d23839
PULL_REQUEST_TEMPLATE.md 
# Standard GPflow pull request

At first, thank you very much for spending time on contributing to GPflow.\
This template exists to help us to grasp your work without asking very common questions. The template helps you to get thorough feedback as well.


## PR content:

* [Title](#title)
* [Description](#description)
* [Minimal working example](#minimal-working-example)

### Title

Squeeze it. Be creative. There is no necessity for any marks like [BUG], {feature} and cetera. We have github labels for that.

### Description

Describe your contribution by writing down the context and reasons. Make it clear whether it is a **bug fix**, **feature** or **enhancement**. Do not make it very wordy, keep it short and simple.

* Bad example: `This is a bug-fix found at #111.`
* Bad example: `Add new SuperMagic optimizer.`
* Good example: `Working on feature #111, we found that parameters of VGP are not instantiated properly. It causes arbitrary failures at training. The bug is fixed by adding necessary parameters to the list of trainables.`


### Minimal working example

No matter how good the description is, the best thing you can do for making a reviewer's life much easier is to add a minimal working example (MWE). Ideally, it should be a short code snippet with relevant comments. If a MWE is big (> 50 lines), you should consider [gist](https://gist.github.com) instead.

* If your PR is a *bug* related fix, then your MWE must disclose the bug explicitly showing what happened before and after.
* When you propose a new *feature*, the MWE must show different use cases and demonstrate its benefits.

## Code quality requirements

For details, look at the code quality requirements section in [contributing.md](../contributing.md). The *main* points are repeated here:

* _New feature's_ code must be accompanied with [detailed](../contributing.md) docstrings.
* _New features_ must be covered with tests.
* _Fixed bug_ must be proved by test suites.
* Use type annotations.
* Use `.pylintrc` for code formatting.
back to top