Closed HeuristicLab-Trac-Bot closed 11 years ago
r8684: fixed a bug related to the virtual call to RecalculateResults in the constructor of DiscriminantFunctionClassificationSolution
- added caching for variances of GaussianProcessRegressionSolution.
- changed hyperparameter initializers to generate initial values for hyperparameters in a larger range.
r8740: removed assertion for test R² in GPR unit test as we are testing on a benchmark problem where the test set is randomly created.
To do: check range of all input variables and deactivate if necessary.
r8829: fixed an issue that occurs in scaling if a variable is effectively constant in the training partition
Reviewing comments:
- Use folders for covariance and mean functions.
Util.AttachValueChangeHandler
is quite ugly- The
HyperParameter
class relies heavily on which methodSetValue
orValue.Set
is called and determines according to this whether the fixed flag applies or not.Util.SqrDist
: Is the scale array always exactly as large as the number of column indixes?.- Covariance functions expose methods with column indexes which are not always forwarded to the concrete util functions (e.g.,
CovarianceLinear.GetCrossCovariance
).I have also tested the implementation on sample problem instances for regression and classification and did not find any bugs. However, I must admit that I didn't completely understand how the implementation works as I am lacking the basics of GP.
Replying to [comment:58 mkommend]:
Reviewing comments:
Util.AttachValueChangeHandler
is quite ugly Please specify the problem in more detail. Do you mean that they should not be located in theUtil
class?
Replying to [comment:59 gkronber]:
Replying to [comment:58 mkommend]:
Reviewing comments:
Util.AttachValueChangeHandler
is quite ugly Please specify the problem in more detail. Do you mean that they should not be located in theUtil
class? The "problem" is that this event registration is implemented in quite a different way as the remaining parts of HL, which makes it harder to grasp what is going on (when is the local parameter cache updated, what happens on a value change, where is the new event registered, ...).
Replying to [comment:60 mkommend]:
Replying to [comment:59 gkronber]:
Replying to [comment:58 mkommend]:
Reviewing comments:
Util.AttachValueChangeHandler
is quite ugly Please specify the problem in more detail. Do you mean that they should not be located in theUtil
class? The "problem" is that this event registration is implemented in quite a different way as the remaining parts of HL, which makes it harder to grasp what is going onYes it is different to the remaining parts of HL and harder to grasp.
AttachValueChangeHandler
takes aValueParameter
and registers a handler that executes the action which is specified as second parameter. Because both the value of a parameter, as well as the value of the value of the parameter can change, we have to attach to both events- In case the value of the parameter is changed we have to attach the event handler to the new value.(when is the local parameter cache updated, what happens on a value change, where is the new event registered).
AttachValueChangeHandler
does not have a local parameter cache. Thus, I believe the real issue here is the caching of parameters and values in all covariance and mean functions and not the implementation ofAttachValueChangeHandler
.
- r8929: moved covariance and mean functions to folders
- r8931: fixed incorrect handling of dimension masking in CovarianceLinear (and checked all other covariance functions)
- r8932 to r8933: corrected handling of length-parameter arrays in ARD functions and prevented stacking of mask covariance functions to make sure that the length-parameter and the enumerable of selected column indexes are equally long.
I thought about possible changes to remove the caching of parameter values in covariance functions and came up with a possible solution returning functions with the cached value in the closure. This would remove the necessity for event registration. It also allows us to remove the
SetParameters
method. What do you think about this idea?#!c# public Func<double[,], int, int, double> GetCovarianceFunction(IEnumerable<int> columnIndices) { var inverseLength = inverseLengthParameter.Value.Value; var sf2 = scaleParameter.Value.Value; return (x, i, j) => { double d # i= j ? 0.0 : Util.SqrDist(x, i, j, inverseLength, columnIndices); return sf2 * Math.Exp(-d / 2.0); }; }
Is the proposed solution really working as intended? The inverseLength and scaleParameter could change its value over time, as they are optimized during the runtime. Now I have to know at which time I have to call
GetCovarianceFunction
to create a new closure containing the updated parameter value, if I am even aware of this issue.Due to this difficulties, I think the event registration fits the purpose better.
- removed class HyperParameter
- removed the parameter value caching and event handlers for parameter caching in the implemented covariance and mean functions
- the instances of mean and covariance functions configured in the GUI are now actually templates where the structure and fixed parameters of the functions can be specified. In the templates the optimized parameters are null.
- Templates are used in the
GaussianProcessModel
to create the actual covariance and mean functions asFunc
objects with specified parameter values (which are optimized using LM-BFGS).
r9104: fixed a bug occurring when the masking covariance function is used.
r9106: fixed a bug in ARD covariance functions that would occur when a parameter prior to the inverse length parameter would be fixed.
The gradients are not returned in the same order of the parameters! This should be checked for all covariance functions.
r9108: fixed bugs in ARD covariance functions (checked if parameter and gradient order matches for all functions)
r9111: fixed a calculation bug in the RQiso covariance function
GP should be a problem. Hyper-parameters are optimized, likelihood should be maximized.
I think I should do the same with NCA which can also be thought of as an optimization problem.
r9211: reformulated calculation of periodic covariance function
r9360: implemented neural network covariance function plus test case (comparison with GPML) for Gaussian processes
Issue migrated from trac ticket # 1902
milestone: HeuristicLab 3.3.8 | component: Algorithms.DataAnalysis | priority: medium | resolution: done
2012-07-25 11:24:53: @gkronber created the issue