Thank you Rémi. I think it's going in the right direction.
But please don't submit separate paches unless they really are separate patches (dealing with sufficiently isolated issues). You can use, e.g., Mercurial's "mq" extension to handle patches, amend them, merge them, etc.
Also, please try to conform to STK coding conventions when submitting patches. Most of them are unwritten, but easy to guess from existing code. Three of them are:
Function and class names are made of lowercase letters only. You have several functions with mixed-case names.
All public functions and classes start with "stk_" (the only exception being the getters and setters in some recently introduced classes). Your function isnoisy breaks this rule.
Help texts are located before the "function" keyword. They start with a one-liner. Calling syntaxes are introduced by "CALL: ". etc.
As a first step, I have merged your commits and relocated everything inside the "paramestim" directory (please avoid introducing new directories when working on experimental changes). The unified commit is attached. Start from there for your next contributions.
I will discuss the actual content of your proposal in other posts.
I have started a super-experimental branch named "parametrized-noisevar" (it should have been "parameterized", I think...) to work on this more easily.
The first issue I want to deal with is this "isnoisy" function. I don't think it makes sense, semantically, to have such a function for "noise variance parameters". We should be asking "are you noisy ?" to a model, not to a paramer object. This an easy change, I think I can even implement it directly on default.
Then there is a deeper issue to consider. The interface that you propose for parameterized noise variance functions is very different from what we currently have for parameterized covariance functions. For a covariance function we have three fields (covariance_type, param, prior); it is possible to handle parameterized covariance function without having to construct classes. In what you propose, there are only two fields (lognoisevariance, noiseprior), and classes are mandatory if we want to use something else than a constant noise variance function. I think we should think of some generic design (that we can also use later for parameterized linear models)...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Work is in progress to bring the contributions from branch parametrized-noisevar to default.
Although this will perhaps not be the final implementation & API of parmetrized objects (covariances, noise models, linear models, etc.) this will be part of STK 2.6 with an "experimental" status.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Add features to implement heteroscedastic noise.
Adapt functions using log-noise variance to the case of noise variance parameter
objects.
See work in progress in the experimental branch named "covmat".
I believe your first patch is no longer necessary given the changes I made there.
The second one will have to be adapted...
More work has been done in the experimental branch named "covmat".
Please try to adapt your second patch to introduce parameterized noise variance functions.
Propose some adaptations to introduce parameterized noise variance functions.
The first patch (1562) is the introduction of the class parameterized noise variance (under the name "stk_noisevar_param").
The second patch (1563) adapts the function stk_covmat and stk_covmat_noise.
The third patch (1564) adapts the initalization and estimation functions (function in the folder "paramestim").
The last patch (1565) debugs the typing errors.
A test file (test_classParameters.m) is furnished with. Tests on STK and this file succed to give a result (no error).
Thank you Rémi. I think it's going in the right direction.
But please don't submit separate paches unless they really are separate patches (dealing with sufficiently isolated issues). You can use, e.g., Mercurial's "mq" extension to handle patches, amend them, merge them, etc.
Also, please try to conform to STK coding conventions when submitting patches. Most of them are unwritten, but easy to guess from existing code. Three of them are:
Function and class names are made of lowercase letters only. You have several functions with mixed-case names.
All public functions and classes start with "stk_" (the only exception being the getters and setters in some recently introduced classes). Your function
isnoisybreaks this rule.Help texts are located before the "function" keyword. They start with a one-liner. Calling syntaxes are introduced by "CALL: ". etc.
As a first step, I have merged your commits and relocated everything inside the "paramestim" directory (please avoid introducing new directories when working on experimental changes). The unified commit is attached. Start from there for your next contributions.
I will discuss the actual content of your proposal in other posts.
Last edit: Julien Bect 2016-05-06
I have started a super-experimental branch named "parametrized-noisevar" (it should have been "parameterized", I think...) to work on this more easily.
The first issue I want to deal with is this "isnoisy" function. I don't think it makes sense, semantically, to have such a function for "noise variance parameters". We should be asking "are you noisy ?" to a model, not to a paramer object. This an easy change, I think I can even implement it directly on default.
Then there is a deeper issue to consider. The interface that you propose for parameterized noise variance functions is very different from what we currently have for parameterized covariance functions. For a covariance function we have three fields (covariance_type, param, prior); it is possible to handle parameterized covariance function without having to construct classes. In what you propose, there are only two fields (lognoisevariance, noiseprior), and classes are mandatory if we want to use something else than a constant noise variance function. I think we should think of some generic design (that we can also use later for parameterized linear models)...
I have replaced your isnoisy() function by an stk_isnoisy() function, which acts on models instead of parameter objects.
Work is in progress to bring the contributions from branch parametrized-noisevar to default.
Although this will perhaps not be the final implementation & API of parmetrized objects (covariances, noise models, linear models, etc.) this will be part of STK 2.6 with an "experimental" status.
The experimental branch parametrized-noisevar has now been closed.
It is now possible (but not documented) to have an object instead a numerical value for model.lognoisevariance.
We should provide at least one example to illustrate how it works (even it's currently considered experimental).
An example is now available on default
(see commit c4e10b7f4b9d56655293eb2dc494dc72531b8bc6)
This is enough for STK 2.6.0. More work on this issue : later...
Moved to github: https://github.com/stk-kriging/stk/issues/8. Closing this ticket.
Last edit: Julien Bect 2020-08-24