On 10/17/10 2:26 PM, Robert Dodier wrote:
> On 10/14/10, Raymond Toy <toy.raymond at gmail.com> wrote:
>
>> fmin_cobyla(f, vars, initx[, ineq, eq, rhobeg, rhoend, iprint, maxfun])
>>
>> That is, the constraints parameter is now longer required and becomes
>> the ineq keyword parameter, and add the eq keyword parameter.
> It would be clearer to have a single list of constraints,
> and to have the constraint stated as such (either an inequality
> or equality).
>
> At present if you look at a call to fmin_cobyla you have to mentally
> reconstruct the inequalities and equalities from an undistinguished
> list of expressions. Why not just have the user enter the equality
> or inequality expressions and, in the Maxima front end to the
> translated Fortran code, inspect the expressions to set up the
> call to the Fortran-derived stuff.
>
> e.g. constraints = [x^2 + y^2 > 1, x + y = 1]
Programmer laziness prevents this from happening. I will look at it to
see how difficult this will be. Strict inequalities won't work,
though. I guess g(x) >= h(x) needs to be converted to g(x) - h(x) >= 0
and g(x) = h(x) becomes g(x) - h(x) = 0, which should be converted to
g(x)-h(x) >= 0 and -(g(x)-h(x)) >= 0.
Or maybe just require the user to enter constraints as g(x) >= 0 and
h(x) = 0, and give up on anything else.
> Also, I'm a little confused about the documentation.
> It says "Equality constraints g(X)=0 can often be implemented
> by a pair of inequality constraints g(X)>=0 and -g(X)>= 0."
> So it works sometimes but not always? (What is an example for
> which it doesn't work?) Anyway, can we leave that out since
> the Maxima front end is going to rewrite the inequalities, so the
> user need not?
Yeah, that's an oversight and should be removed.
Ray