Menu ▾ ▴

#5 Hide computational details in stk_param_relik

SomeDay
closed
Julien Bect
None
2020-08-04
2013-12-02
Julien Bect
No

stk_param_relik uses a combination of "filtering matrix" (obtain using QR) and a Cholesky factorizations of the filtered covariance matrix. This computational approach could/should be encapsulated in a class similar to (but distinct from) stk_kreq_qr.

Other parts of the toolbox work with a different computational approach, encapsulated in stk_kreq_qr (QR factorization of the "kriging matrix"). Why not use the same technique in stk_param_relik as well? For instance, it should be possible to compute the restricted likelihood from an stk_model_gpposterior object very quickly (since everything has been pre-computed).

Ideally, once both approaches have been properly encapsulated, it should be possible to switch transparently between them for all computations in the toolbox (likelihoods and predictions).

Discussion

  • Julien Bect

    Julien Bect - 2014-05-12
    • Milestone: 2.2 --> 2.3
     

  • Julien Bect

    Julien Bect - 2015-03-11
    • Milestone: 2.3 --> 2.4
     

  • Julien Bect

    Julien Bect - 2016-02-15
    • Description has changed:

    Diff:

    --- old
+++ new
@@ -1,3 +1,5 @@
-stk_param_relik explicitely uses a QR and a Cholesky factorizations.
+stk_param_relik uses a combination of "filtering matrix" (obtain using QR) and a Cholesky factorizations of the filtered covariance matrix. This computational approach could/should be encapsulated in a class similar to (but distinct from) stk_kreq_qr.

-The corresponding computations should be encapsulated in the stk_kreq_qr class (or perhaps a "generalized covariance matrix" class, to be defined later), to make it possible in the future to switch transparently between several computation techniques.
+Other parts of the toolbox work with a different computational approach, encapsulated in stk_kreq_qr (QR factorization of the "kriging matrix"). Why not use the same technique in stk_param_relik as well? For instance, it should be possible to compute the restricted likelihood from an stk_model_gpposterior object very quickly (since everything has been pre-computed).
+
+Ideally, once both approaches have been properly encapsulated, it should be possible to switch transparently between them for all computations in the toolbox (likelihoods and predictions).
    • Milestone: 2.4 --> 2.5
     

  • Julien Bect

    Julien Bect - 2016-02-15
    • summary: Hide the use of QR in stk_param_relik --> Hide computational details in stk_param_relik
     

  • Julien Bect

    Julien Bect - 2017-06-24

    This ticket is still relevant but not likely to be addressed anytime soon.

    Changing to target 3.0 to reflect the fact that this is a rather long-term goal.

     

  • Julien Bect

    Julien Bect - 2017-06-24
    • Milestone: 2.5 --> 3.0
     

  • Julien Bect

    Julien Bect - 2018-05-22
    • Milestone: 3.0 --> SomeDay
     

  • Julien Bect

    Julien Bect - 2020-08-04
     

  • Julien Bect

    Julien Bect - 2020-08-04
    • status: open --> closed