[SciPy-User] scipy optimization: inequality constraint type

[Kirill Balunov]

I'm sorry, perhaps I should more clearly formulate the question. David you
are totally right. What I mean by classical: is "less than or equal"
type. Of course it's a question of a sign, but still...

-gdg

2017-05-26 0:07 GMT+03:00 David Goldsmith <eulergaussriemann at gmail.com>:

> I would assume that it's because the "or equal to" option allows greater
> flexibility: if that criterion is allowed by the problem, and the algorithm
> can find such a solution (e.g., by checking all such corner points), then
> that's better than not even providing the option, yes?  And if you try to
> "rig" the strict inequality approach by allowing for a little extra room
> around the corner, then the exact solution might not be found, yes?
> Indeed, i'm no expert, but i did have a course in this, and IIRC, if your
> problem allows for equality, then you _must_ separately check all the
> corners, yes?  (In other words, what you state about the "classical
> formulation" is not what i was taught: I was taught that the specifics of
> the problem dictate whether any given inequality should be strict or
> "weak.")
>
> DLG
>
> On Thu, May 25, 2017 at 1:49 PM Kirill Balunov <kirillbalunov at gmail.com>
> wrote:
>
>> Hi,
>> I've tried some scipy optimization routines, they work great!!! But I
>> wondered, why historically for inequality constraints the type was chosen
>> to be "greater than or equal" type? This is inconsistent with the classical
>> formulation of non-linear programming problems.
>>
>> Thanks!
>>
>> -gdg
>> _______________________________________________
>> SciPy-User mailing list
>> SciPy-User at python.org
>> https://mail.python.org/mailman/listinfo/scipy-user
>>
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at python.org
> https://mail.python.org/mailman/listinfo/scipy-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-user/attachments/20170526/8f6139f6/attachment.html>