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

Refactor GaussianProcesses #346

Open
odunbar opened this issue Jan 17, 2025 · 0 comments
Open

Refactor GaussianProcesses #346

odunbar opened this issue Jan 17, 2025 · 0 comments

Comments

@odunbar
Copy link
Member

odunbar commented Jan 17, 2025

Issue

Though we have modularity/extensibility of the current GaussianProcess framework. It currently depends to heavily on the similarity of how GP packages work and the objects they create.

Currently we create a GaussianProcess{<:GPPackage} object and dispatch off the package. And this gets quite messy as, for example we end up with many Union-types of the fields inside this object.

Possible solution

I think a better solution is to keep the GPPackage types and the GaussianProcess could now become an abstract type. Then we can create (bad names->) SKLJLGP, GPJLGP, AGPJLGP, ... <: GaussianProcess, that is, different objects for the different packages.

These can contain a variety of different fields and options, and will have typed fields that avoids needing unions between different packages

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

No branches or pull requests

1 participant