On Sun, 13 Sep 2015 00:12:51 +0200, Thom Brown wrote:
[...]
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?
Bounds are not directly supported by the two least-squares solving
methods
(Gauss-Newton and Levenberg-Marquardt) implemented in CM.
I think that a safe way to constrain the parameters is to use the
"Logit"
and "Sigmoid" function (defined in package
"o.a.c.m.analysis.function").
I.e. the optimizer should "see" unconstrained values (ranging from -INF
to +INF).
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.
Will "out of range" values create a wrong evaluation of the model?
If not, then if you start within the preferred interval, and if there
is
a solution there, it should not matter, and the solution will be found.
It will just take a little time to explore the "far away" regions.
Best regards,
Gilles
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
