PR #196: simplification of optimization wrappers
Hi, In pull request #196, I am proposing to simplify the signature of optimization wrappers (minimize, minimize_scalar, etc.) to get something like: x, info = minimize(fun, x0, [jac, constraints], options) This boils down to eliminating the full_output and retall parameters from respective function. Besides, the info dictionnary would always be returned. Comments welcome - https://github.com/scipy/scipy/pull/196 Thanks, -- Denis
Hi, 18.04.2012 22:26, Denis Laxalde kirjoitti:
In pull request #196, I am proposing to simplify the signature of optimization wrappers (minimize, minimize_scalar, etc.) to get something like:
x, info = minimize(fun, x0, [jac, constraints], options)
How about going even further, and not even returning `x`. Rather, stuff it inside `info`: sol = minimize(fun, x0, [jac, constraints], options) x = sol.x Just change the solution object to a dict subclass with attribute accessors, and you're done. And maybe even add `def __array__(self): return self.x`, so you can do `asarray(sol)`? Pauli
If I recall correctly, a similar approach is used in CVXOPT. On Apr 18, 2012 4:38 PM, "Pauli Virtanen" <pav@iki.fi> wrote:
Hi,
18.04.2012 22:26, Denis Laxalde kirjoitti:
In pull request #196, I am proposing to simplify the signature of optimization wrappers (minimize, minimize_scalar, etc.) to get something like:
x, info = minimize(fun, x0, [jac, constraints], options)
How about going even further, and not even returning `x`. Rather, stuff it inside `info`:
sol = minimize(fun, x0, [jac, constraints], options) x = sol.x
Just change the solution object to a dict subclass with attribute accessors, and you're done.
And maybe even add `def __array__(self): return self.x`, so you can do `asarray(sol)`?
Pauli
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Wed, Apr 18, 2012 at 8:23 PM, Gustavo Goretkin <gustavo.goretkin@gmail.com> wrote:
If I recall correctly, a similar approach is used in CVXOPT.
On Apr 18, 2012 4:38 PM, "Pauli Virtanen" <pav@iki.fi> wrote:
Hi,
18.04.2012 22:26, Denis Laxalde kirjoitti:
In pull request #196, I am proposing to simplify the signature of optimization wrappers (minimize, minimize_scalar, etc.) to get something like:
x, info = minimize(fun, x0, [jac, constraints], options)
How about going even further, and not even returning `x`. Rather, stuff it inside `info`:
sol = minimize(fun, x0, [jac, constraints], options) x = sol.x
Just change the solution object to a dict subclass with attribute accessors, and you're done.
And maybe even add `def __array__(self): return self.x`, so you can do `asarray(sol)`?
What's the overhead of retall, especially fmin with a few thousand iterations? The rest of info looks all calculated as a byproduct, so there shouldn't be much extra cost, is there? I don't think I ever used or looked at retall. Josef
Pauli
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
josef.pktd@gmail.com wrote:
What's the overhead of retall, especially fmin with a few thousand iterations?
The retall parameter is replaced by the field 'return_all' in the options dictionary which, if True, will lead to an 'allvecs' field in info. So there's no extra overhead as it remains optional.
The rest of info looks all calculated as a byproduct, so there shouldn't be much extra cost, is there?
No, I don't think so. -- Denis
On Wed, Apr 18, 2012 at 9:27 PM, Denis Laxalde <denis@laxalde.org> wrote:
josef.pktd@gmail.com wrote:
What's the overhead of retall, especially fmin with a few thousand iterations?
The retall parameter is replaced by the field 'return_all' in the options dictionary which, if True, will lead to an 'allvecs' field in info. So there's no extra overhead as it remains optional.
good, I don't see any problem then.
The rest of info looks all calculated as a byproduct, so there shouldn't be much extra cost, is there?
No, I don't think so.
Another question: I just saw that the options use a mutable keyword, dict. Are we running into problems? It might be safer to set it to None instead of an empty dict, given that an empty dict doesn't make a more informative signature either. (I saw a reminder on this on planet python today. http://reinout.vanrees.org/weblog/2012/04/18/default-parameters.html ) Josef
-- Denis _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
josef.pktd@gmail.com wrote:
I just saw that the options use a mutable keyword, dict. Are we running into problems? It might be safer to set it to None instead of an empty dict, given that an empty dict doesn't make a more informative signature either.
I'm not sure to see the problem but, AFAICT, setting its default value to None would not prevent an existing options dictionary (or any mutable object) that would be passed as an argument to be modified. It seems there might a problem iff the default value is not an empty dictionary. At least, {} as a default value ensures that dictionary methods always work. -- Denis
On Thu, Apr 19, 2012 at 3:28 PM, Denis Laxalde <denis@laxalde.org> wrote:
josef.pktd@gmail.com wrote:
I just saw that the options use a mutable keyword, dict. Are we running into problems? It might be safer to set it to None instead of an empty dict, given that an empty dict doesn't make a more informative signature either.
I'm not sure to see the problem but, AFAICT, setting its default value to None would not prevent an existing options dictionary (or any mutable object) that would be passed as an argument to be modified. It seems there might a problem iff the default value is not an empty dictionary. At least, {} as a default value ensures that dictionary methods always work.
{} as a default value is fine iff you are careful to treat the passed-in dictionary as read-only. E.g. this is bad def dosomething(options={}): options.setdefault("quickly", True) if options["quickly"]: ... -- Nathaniel
Nathaniel Smith wrote:
I just saw that the options use a mutable keyword, dict. Are we running into problems? It might be safer to set it to None instead of an empty dict, given that an empty dict doesn't make a more informative signature either.
I'm not sure to see the problem but, AFAICT, setting its default value to None would not prevent an existing options dictionary (or any mutable object) that would be passed as an argument to be modified. It seems there might a problem iff the default value is not an empty dictionary. At least, {} as a default value ensures that dictionary methods always work.
{} as a default value is fine iff you are careful to treat the passed-in dictionary as read-only. E.g. this is bad
def dosomething(options={}): options.setdefault("quickly", True) if options["quickly"]: ...
AFAICT, that dictionary is not modified. Yet I am now convinced that it is safer to use None. -- Denis
On 2012-04-18 7:34 PM, Denis Laxalde wrote:
Pauli Virtanen wrote:
How about going even further, and not even returning `x`. Rather, stuff it inside `info`:
sol = minimize(fun, x0, [jac, constraints], options) x = sol.x
Ok, if no one objects, I'm fine with this as well. Actually, x is already in info['solution'].
Hi, I am a user of various SciPy optimization functions. Since I am interested primarily in 'x', I'm not sure of the benefit of burying this information in a dictionary. Perhaps this can be clarified. Thanks. -gyro
Gyro Funch wrote:
I am a user of various SciPy optimization functions. Since I am interested primarily in 'x', I'm not sure of the benefit of burying this information in a dictionary. Perhaps this can be clarified.
'x' is not that « buried », you can easily access it as sol.x. So, if you only want 'x', do: x = minimize(fun, x0, [jac, constraints], options).x (Note that there's no 'x' attribute defined. It is currently named 'solution'.) -- Denis
participants (6)
-
Denis Laxalde -
Gustavo Goretkin -
Gyro Funch -
josef.pktd＠gmail.com -
Nathaniel Smith -
Pauli Virtanen