Forum: developers

RE: optimal value access function [ Reply ] By: Arne Henningsen on 2016-02-16 07:40	[forum:42958]
OK, thanks for the explanation! I agree that other features have a higher priority.

RE: optimal value access function [ Reply ]
By: Ott Toomet on 2016-02-15 03:17

[forum:42946]

both gradient and maxValue done now. I also added df attribute to logLik() as specified in the stats::logLik documentation.

lastStep: maxNR & friends return last unsuccessful step if something goes wrong with stepping. Currently the component is called 'unsucc.step' but maybe return it anyway (not just if something goes wrong) and name the getter 'lastStep()'. I have never used it, so not a high-priority task.

RE: optimal value access function [ Reply ] By: Arne Henningsen on 2016-02-14 07:41	[forum:42940]
Good :-) I think that constraints() is a good name to extract the constraints. What should lastStep() return?

RE: optimal value access function [ Reply ] By: Ott Toomet on 2016-02-13 03:17	[forum:42930]
Just implemented "maxValue". Will also do "gradient" soon, and then we only need like "lastStep" and "constraints" (good names suggestions welcome ;-). I also changed maxNR documentation accordingly, may be a bit messy right now. Comments welcome as well

RE: optimal value access function [ Reply ]
By: Arne Henningsen on 2015-10-31 20:42

[forum:42702]

* regarding coef(): I agree. It seems that I misunderstood your sentence "I would leave 'maximum/optimum' to describe the corresponding parameter values."

* I agree with gradient(). A function gradient() is already defined in package "mpoly" but I don't think that this is a major problem.

* Currently, all functions that return objects of class "maxim" maximize the function value (at least by default). Hence, it would be reasonable to call the extractor function maximum() or maxValue(), whereas I prefer the latter (maxValue()).

RE: optimal value access function [ Reply ]
By: Ott Toomet on 2015-10-31 19:34

[forum:42701]

coef = estimated parameters. We already have it for 'maxim' and 'maxLik'.
What we need is the maximum value (at estimated parameters).
* A related question: what is a good name for the gradient value at estimated parameters? I suggest 'gradient' (cf 'hessian').
* optimum() may be a good choice, although it leaves a bit unclear whether it is about the value or parameters. So perhaps optValue()? Or perhaps maxValue()? Should we consistently only talk about maximum, or should we try to be more general and talk about optimum?

RE: optimal value access function [ Reply ]
By: Arne Henningsen on 2015-10-31 15:48

[forum:42700]

Good idea to implement a likelihood surface plotting function!

I think that value() is not a very informative name for this function. I prefer maximum(), optimum(), maxValue(), maximValue(), optValue(), or optimValue.

I suggest to use something like coef(), param(), parameters(), maxPar(), maximPar, optPar(), or optimPar() to obtain the parameter values.

Function optimum() is already used in package "qualityTools" and a generic function param() is already defined in package "hoa".

I prefer maxValue() / maxPar() or maximValue() / maximPar(). What do you think?

optimal value access function [ Reply ]
By: Ott Toomet on 2015-10-28 21:22

[forum:42693]

I am designing a likelihood surface plotting function (maybe to be released at one point of time). In this context I need to extract the value at (estimated) optimum. Do you have suggestions for a good accessor function name?

x < maxim(...)
val <- value(x)?

maximum(x)? optimum(x)? In case of maxLik, logLik(x) will do the trick, but I don't want to carry the same name over for 'maxim' class. The component is called 'maximum', in nlm it is 'minimum', for 'optim' it is 'value'.

I am in favor of 'value' and I would leave 'maximum/optimum' to describe the corresponding parameter values.