tol parameter to minimize_scalar is inconsistent [without HTML this time]
![](https://secure.gravatar.com/avatar/4f556b64c7fdd817b07158057b2becc2.jpg?s=120&d=mm&r=g)
[sorry for the HTML in the first try] Hi, I'm a longtime user of scipy and greatly appreciate your work. I'd like to ask/suggest something about minimize_scalar. It seems to me that the tol parameter is relative tolerance when the method is 'brent' and absolute tolerance when the method is 'bounded'. Isn't this confusing? Perhaps this parameter should be deprecated, until both methods can support either relative or absolute tolerance? Meanwhile, parameters with names such as 'abs_xtol' and 'rel_xtol' can be introduced, and invalid combinations of parameters and method would be rejected with a ValueError? Cheers. This mail was sent via Mail-SeCure system. ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************
![](https://secure.gravatar.com/avatar/ed4f792c8377b54b8718a8716b9d8129.jpg?s=120&d=mm&r=g)
Hi, Micky Latowicki wrote:
I'd like to ask/suggest something about minimize_scalar. It seems to me that the tol parameter is relative tolerance when the method is 'brent' and absolute tolerance when the method is 'bounded'. Isn't this confusing?
This appears to be correct. It is indeed confusing. You might want to submit a bug report about this. See http://www.scipy.org/scipylib/bug-report.html.
Perhaps this parameter should be deprecated, until both methods can support either relative or absolute tolerance? Meanwhile, parameters with names such as 'abs_xtol' and 'rel_xtol' can be introduced, and invalid combinations of parameters and method would be rejected with a ValueError?
This should at least be documented. On the other hand, adding support for both relative and absolute tolerances in underlying solvers might not be too hard. Greetings, Denis
![](https://secure.gravatar.com/avatar/da3a0a1942fbdc5ee9a9b8115ac5dae7.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 12.09.2013 09:08, Denis Laxalde kirjoitti: [clip: tol in minimize_scalar]
This should at least be documented. On the other hand, adding support for both relative and absolute tolerances in underlying solvers might not be too hard.
It would probably be best to harmonize tol to work in the way it does in `minimize`, and provide per-solver parameters for more special tolerance needs. - -- Pauli Virtanen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIx9vMACgkQ6BQxb7O0pWBuqwCdEK1K6cEhpe+hY/7rf+8Z53y0 ISgAn1lB++ttOWeO7zABCheimLVo2Mbh =jIag -----END PGP SIGNATURE-----
![](https://secure.gravatar.com/avatar/42768cd3c97f61bce3d24ec4318e28d2.jpg?s=120&d=mm&r=g)
Pauli Virtanen <pav <at> iki.fi> writes:
...
It would probably be best to harmonize tol to work in the way it does in `minimize`, and provide per-solver parameters for more special tolerance needs.
I'd prefer an interface where the meaning of a parameter does not depend on the value of another. I'd like to be able to change the tolerance and the method in separate. Optimally, the user should be able to specify both relative and absolute tolerance, and the selected method will use the tolerance it supports. I've created a github issue to work on this, and intend to submit a pull request along the lines of my suggestion. Any further comments would be welcome. https://github.com/scipy/scipy/issues/2859
participants (4)
-
Denis Laxalde
-
Micky Latowicki
-
Micky Latowicki
-
Pauli Virtanen