commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <>
Subject [jira] Commented: (MATH-165) Simplify use of "EstimationProblem"
Date Wed, 08 Aug 2007 15:17:00 GMT


Luc Maisonobe commented on MATH-165:

I don't think the signature for the two addParameter methods is wise.
The first problem is the bound/unbound property should not be forced when the problem is set
up because it may be changed later (it is a dynamic property of the EstimatedParameter class).
Providing both a parameter which contains such a property and a boolean is misleading. It
is also important to let the user change the bound/unbound property at will after the problem
has been set up, for example to allow interactive applications were the user change settings
until he gets satisfied.
The second problem is that partial derivatives cannot be linked only to parameters, this is
possible only for estimation problems using only one type of measurements. If we have n parameters
and m measurements belonging to q different types, we usually need n*q partial derivatives
functions, not n.

So I am going to implement a very basic class handling only data storage and bound/unbound
filtering based on the current settings. In order to add more problem-specific logic, this
class should be extended, one use case is yours, with partial derivatives directly linked
to parameters, another use case is mine, with complex interdependencies on a measurement basis.

Does this seem sensible ?

> Simplify use of  "EstimationProblem"
> ------------------------------------
>                 Key: MATH-165
>                 URL:
>             Project: Commons Math
>          Issue Type: Improvement
>            Reporter: Gilles
>            Assignee: Luc Maisonobe
>            Priority: Minor
>             Fix For: 1.2
> The use of the "EstimationProblem" interface could be simplified by providing a helper
(abstract) class that would implement
> the "getMeasurements" "getAllParameters" and "getUnboundParameters" methods.  Currently,
each new implementation of the interface has to do it even if they are typically only called
from the "Estimator" class (and not by the user code).
> That same helper class could also take care of storing the partial derivatives.
> A skeleton for the requested class could be as follows:
> public abstract class SimpleEstimationProblem
>     implements EstimationProblem {
>     // ... storage for measurements and partial derivatives ...
>     protected void addParameter(EstimatedParameter p,
>                                 ComputableFunction partial,
>                                 boolean isBound) {
>          // ...
>     }
>     protected void addParameter(EstimatedParameter p,
>                                 ComputableFunction partial) {
>         addParameter(p, partial, false);
>     }
>     protected double getPartial(EstimatedParameter p,
>                                 double x) {
>         // ...
>     }
>     protected void addMeasurement(WeightedMeasurement m) {
>         _observations.add(m);
>     }
>     public WeightedMeasurement[] getMeasurements() {
>         // ...
>     }
>     public EstimatedParameter[] getAllParameters() {
>         // ...
>     }
>     public EstimatedParameter[] getUnboundParameters() {
>         // ...
>     }
> }
> Best,
> Gilles

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message