Introduce NonNegativeReal parameters #512
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist
hatch run dev:format
before committing.I've added docstrings for the new code.N/ADescription
Introduced a new NonNegativeReal parameter type. This has two primary applications.
Kernel variance parameter
This has been implemented into kernel variance parameters. This allows kernels to be 'turned off' as required by setting
variance=gpx.parameter.Static(0.0)
. This is potentially useful for kernel searching algorithms.I have been using this feature as an optional add-on kernel which defaults to 'off'.
Gaussian likelihood
obs_stddev
By allowing
gpx.likelihoods.Gaussian()
to acceptobs_stddev=0.0
we can 'turn off' the likelihood. This is important for GP emulators of computer models. The easiest way to see this working well is by removing the observation noise from the regression example on the documentation.There is perhaps a cleaner solution by defining a new likelihood class,
emulator
say, with noobs_stddev
argument which simply returns the required number of zeros when called.Why is this needed at all?
One could argue that this is not necessary as using
gps.Prior()
should be sufficient for building emulators. From a development point of view, it is easier to build tools that rely purely on theAbstractPosterior
class with a likelihood of fixed structure baked in rather than also having to account for thePrior
class thus rendering a likelihood 'optional'. Hence a quick 'hack' such as my implementation, or potentially an arguably cleaneremulator
likelihood is easier to account for.Issue Number: N/A