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
As pointed out in the README, PDMat always stores both Cholesky factorisation and full matrix. For many operations that are commonly used downstream, such as logdet and the quadratic forms, the full matrix is never used. So when the PDMat is constructed from an already known Cholesky factor (e.g. because we optimize for a variationally optimal covariance matrix), this is an unnecessary computation (see JuliaGaussianProcesses/ParameterHandling.jl#41 (comment)).
What are the design reasons for the current setup? What would it take to change this? Could we, for example, have some lazy way of computing mat (or chol) only when it is actually required [and then caching it]?
The text was updated successfully, but these errors were encountered:
st--
changed the title
PDMat without constructing full matrix
Design question/discussion: PDMat without constructing full matrix
Oct 28, 2021
As pointed out in the README,
PDMat
always stores both Cholesky factorisation and full matrix. For many operations that are commonly used downstream, such as logdet and the quadratic forms, the full matrix is never used. So when thePDMat
is constructed from an already known Cholesky factor (e.g. because we optimize for a variationally optimal covariance matrix), this is an unnecessary computation (see JuliaGaussianProcesses/ParameterHandling.jl#41 (comment)).What are the design reasons for the current setup? What would it take to change this? Could we, for example, have some lazy way of computing
mat
(orchol
) only when it is actually required [and then caching it]?The text was updated successfully, but these errors were encountered: