You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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 theGaussianProcess
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
The text was updated successfully, but these errors were encountered: