-
Notifications
You must be signed in to change notification settings - Fork 5
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
Interface with Distributions #47
Comments
I think that for quick and dirty likelihood creations, it would be more practical to have a
And for other likelihoods, users can always create their own type
and do whatever they want with it. The interest of having different subtypes is that one can easily multiple-dispatch on them. What you proposed with the aliases would work but be a bit lengthy |
Ah, I screwed up the const BernoulliLikelihood{T} = GPLikelihood{<:Bernoulli, T} where T etc. Apart from the question of what is the best way to construct likelihoods, the issue here (I think) is whether it would be possible to have fallbacks for some or most of the methods that are used by the other packages in the ecosystem. Is there already a consensus on what would be the standard API for subtypes of AbstractLikelihoods? Things like |
That's another good point. We never really set on a proper API. This issue could be a good start for a discussion.
but it would be nice to generally not be too opinionated about the choices we make. Another thing planned is to move some expectation computation tools from |
To get a better understanding of all the moving pieces, it'd be really good to have some concrete examples (in code) of likelihoods both with additional parameters and multiple latent functions (e.g. Normal with trainable but scalar variance, Normal with both mean and variance parameterised by GPs...) |
Following issue #231 in AbstractGPs.jl, I would like to propose an interface that allows to automatically use Distributions.jl's large library of distributions. Something like (I haven't tested this yet):
and then have convenience structs for special cases:
Would this be useful?
The text was updated successfully, but these errors were encountered: