commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thom Brown <thomas.braunsber...@gmail.com>
Subject Re: [math] Usage of Marquardt Optimizer for an Equation
Date Sat, 12 Sep 2015 22:12:51 GMT
On Sat, Sep 12, 2015 at 10:57 PM, Gilles <gilles@harfang.homelinux.org>
wrote:

> Hello.
>
> On Sat, 12 Sep 2015 13:12:36 +0200, Thom Brown wrote:
>
>> Hey,
>>
>> I think I'm almost set up and I'm positive about my jacobian, but I can't
>> solve two - rather simple? - problems on my own.
>>
>> double[] prescribedValues = new double[observedValues.length];
>>
>>> for (int i = 0; i < prescribedValues.length; i++) {
>>>       prescribedValues[i] = observedValues[i];
>>> }
>>>
>>>
>> I don't know if that makes sense. All I do here is to set the target on my
>> observations. Because I can't think of another way to get observed "F"
>> values, but I think that's rather correct.
>>
>
> I'm not familiar with the problem itself ("triple exponential smoothing")
> so I'm a bit lost now with all the "previous period" and "previous season"
> etc.
> I hope I didn't put you on the wrong track.
>
> However:
>>
>>
>> RealVector startVector = new ArrayRealVector(new double[] { 1.0, 0.0 });
>>> startVector.append(new ArrayRealVector(new double[] { 1.0, 0.0 }));
>>> startVector.append(new ArrayRealVector(new double[] { 1.0, 0.0 }));
>>> LeastSquaresProblem problem = new LeastSquaresBuilder().start(startVector
>>> ).model(distanceToCurrentF)
>>> .target(prescribedValues).lazyEvaluation(false
>>> ).maxEvaluations(1000).maxIterations(100).build();
>>>
>>
>>
>> this won't work.
>>
>
> Well you use arrays of size 2 as arguments while you have 3 parameters...
> I also don't understand the "append" calls...
>
> What I want to do is to set three points each for alpha,
>> beta and gamma that contain the possible values (0 <= alpha, beta, gamma
>> <=
>> 1). Apparently equal entries are merged to one? Anyways, I also doubt I
>> can
>> access my parameters by using:
>>
>> Vector3D approx = new Vector3D(params.getEntry(0), params.getEntry(1),
>>
>>> params.getEntry(2));
>>>
>>
> I don't see the purpose of using "Vector3D", the "RealVector" is already
> holding the values of the parameters; no need to copy them elsewhere.
>
>
>> [...]
>>
>> helper.calculateSmoothedObservation(i, approx.getX(), approx.getY(),
>> approx
>>
>>> .getZ());
>>>
>>
>>
>> at the very beginning of my jacobian function.
>> calculatedSmoothedObservation(int index, double alpha, double beta, double
>> gamma) should always update the S, b and I parameters by using the alpha,
>> beta and gamma values of the optimization. I think I'm not on the right
>> track here.
>>
>> I'm positive that we (okay, you did more than I did here) can solve that
>> too :P
>>
>
> We can provide a few guidelines, but you should really look at the unit
> tests, and discover "what is what" in your problem...
> See also the function fitting classes in the package "o.a.c.m.fitting";
> e.g.
> the "HarmonicCurveFitter" and its "AbstractCurveFitter" base class.
>
> I looked a little at the code referred to in your other post. Some trivial
> suggestions:
> * Avoid "Double" when "double" would be fine.
> * Avoid variables named "l" (can easily be confused with "1").
> * Give meaningful names ("HelperClass" and "Test" do not describe what the
>   should do).
> * Comment abundantly. [Comments could help people help you...]
> * Devise unit tests for every case for which you can figure out the result
>   (or for which you have reference values).  Even trivial tests could point
>   you to where the code is getting off tracks.
> * Use a class to represent each concept of the problem at hand (this will
>   make the above "meaningless class name" problem vanish).
>
>
Yes, I'm sorry about that. I was just putting together a code sniplet as my
underlying data structure is a little more complicated than a double array.
So I'm dealing most likely with Objects, that is why I endet up using a
Double array instead of double. A little careless of me.

The methods calculating the smoothing parameters do work, I tested them
already and I think that is not the problem. If there is anything wrong in
the code it's probably:
- getModelFunction() or
- getModelFunctionJacobian()

I will look into the tests you mentioned tomorrow - just one short question:
Do I have the possibility to set the boundaries for the parameters? I.e., I
would like to say that alpha, beta and gamma are only allowed in the
interval (0, 1). Because the optimizer is also "testing" very large values
(e.g., 50.13895840733627, -51.64110306423619, 64.58128946884025 for alpha,
beta and gamma). Maybe that might help to get a better result.

I think you helped me a lot already, at least I'm close to finding a
solution. Before you answered my questions I had no idea about how to start
off. :)

Greetings,
Thom

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message