[SciPy-User] scipy optimization: inequality constraint type

[David Goldsmith]

The KKT reference exceeds my numeracy...

Anyway, i doubt this is the case, but if it's really a problem, you can
always write wrappers to automate the desired transformations, yes?

DLG

On The, May 25, 2017 at 2:53 PM Kirill Balunov <kirillbalunov at gmail.com>
wrote:

> No, no, the constraints only affect the feseable set of the problem. Min
> or Max depends on the sign of objective function. From mathemtical point of
> view, the problem is that the KKT conditions are derived for standard
> formulation (with "less than ..") of NLP.
>
> Cheers,
>
> -gdg
>
>
> 2017-05-26 0:36 GMT+03:00 David Goldsmith <eulergaussriemann at gmail.com>:
>
>> Ah, yes, that convention i am familiar with; maybe to accommodate the
>> "inflexibility" of less numerate potential users (who may be fixated, e.g.,
>> on wanting to maximize profit or yield)?  Of course, at some point such
>> people may want to minimize something, so hopefully they have someone
>> around to tell them to simply multiply by negative one. ;-)
>>
>> DLG
>>
>> On Thu, May 25, 2017 at 2:29 PM Kirill Balunov <kirillbalunov at gmail.com>
>> wrote:
>>
>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>
>>
> _______________________________________________
> 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/20170525/7232aeec/attachment.html>