commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [Math] MATH-519
Date Mon, 21 Feb 2011 12:49:24 GMT
Hi Gilles,

----- "Gilles Sadowski" <gilles@harfang.homelinux.org> a écrit :

> [Please refer to
>   https://issues.apache.org/jira/browse/MATH-519
> for the context of this discussion.]
> 
> Hi Luc.
> 
> > Anyway, returning NaN or POSITIVE_INFINITY would work only with
> some
> > optimizers.
> 
> Do you mean that it would fail with some optimization _algorithms_ or
> some
> unsafe _implementations_ of those algorithms?

I think algorithms.
Typically direct methods like Nelder-Mead or Torczon's multidirectional method
behave well with discontinuous functions. In fact, one often use penalty functions
in the form of large additive constants to mimic constraints with such algotithms.

Clearly, this does not work with gradient-based methods like Levenberg-Marquardt or
simpler ones like steepest descent or conjugate gradients.

> 
> In the former case, would "Double.MAX_VALUE" be OK?

No. Gradient-based methods need smooth functions and using Double.MAX_VALUE
would not even be continuous.

> In the latter, wouldn't there be a way to make the implementations
> behave
> correctly in the face of those "special" values?
> 
> > For simple bounds on estimated parameters, this can be done using
> > intermediate variables and mapping functions, [...]
> 
> Yes, but that would be slightly less efficient (because of additional
> function calls).

Yes, but for simple bounds this would not be too much (using a logarithm or exponential).
For double bounds, one typically uses a scaled logit function.

> If this is the best choice, I'll implement a "conversion" class (for
> the
> "simple" bound case).

It is a simple intermediate solution, but certainly not a best solution.
I don't if we should implement it because its simple or if we should already
go all the way and implement properly constrained optimization. I'm leaning
towards a complete solution.

What do other people think ?

best regards,
Luc

> 
> 
> Best,
> Gilles
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message