Hi Gilles,

----- "Gilles Sadowski" <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to