Doc error in scipy.optimize.fmin and missing info in ref guide
Hi, In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin. Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence. As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values. if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break Also, optional parameters for any optimize functions are not described in the draft of the Scipy reference manual I came across while googling this issue. For instance, at http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html... fmin does not have the optional arguments detailed. If this is automatically generated is there a reason why the optional parameters aren't being shown in this document? I think they should be, IMO. -Rob
On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
Also, optional parameters for any optimize functions are not described in the draft of the Scipy reference manual I came across while googling this issue. For instance, at
http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html...
fmin does not have the optional arguments detailed. If this is automatically generated is there a reason why the optional parameters aren't being shown in this document? I think they should be, IMO.
just a guess: http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/ shows that Other Parameters is in the wrong order. It could be that the section is ignored for rendering the html for this reason Josef
-Rob _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
I'll look into both problems. DG On Mon, Mar 15, 2010 at 4:13 PM, <josef.pktd@gmail.com> wrote:
On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
Also, optional parameters for any optimize functions are not described in the draft of the Scipy reference manual I came across while googling this issue. For instance, at
http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html...
fmin does not have the optional arguments detailed. If this is automatically generated is there a reason why the optional parameters aren't being shown in this document? I think they should be, IMO.
just a guess:
http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/
shows that Other Parameters is in the wrong order. It could be that the section is ignored for rendering the html for this reason
Josef
-Rob _______________________________________________ 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
This is *very* bizarre: in View mode, Other parameters is displayed before Returns, but in the edit frame in Edit mode, Returns is displayed above Other parameters, but then if I preview, the preview displays it incorrectly, even though in the edit frame, it's still correct!!! Can someone verify this on another platform/in another browser, please? (Mine: Windows Vista, Firefox 3.6). Thanks! DG On Mon, Mar 15, 2010 at 4:41 PM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
I'll look into both problems.
DG
On Mon, Mar 15, 2010 at 4:13 PM, <josef.pktd@gmail.com> wrote:
On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
Also, optional parameters for any optimize functions are not described in the draft of the Scipy reference manual I came across while googling this issue. For instance, at
http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html...
fmin does not have the optional arguments detailed. If this is automatically generated is there a reason why the optional parameters aren't being shown in this document? I think they should be, IMO.
just a guess:
http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/
shows that Other Parameters is in the wrong order. It could be that the section is ignored for rendering the html for this reason
Josef
-Rob _______________________________________________ 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
On Tue, Mar 16, 2010 at 7:50 AM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
This is *very* bizarre: in View mode, Other parameters is displayed before Returns, but in the edit frame in Edit mode, Returns is displayed above Other parameters, but then if I preview, the preview displays it incorrectly, even though in the edit frame, it's still correct!!! Can someone verify this on another platform/in another browser, please? (Mine: Windows Vista, Firefox 3.6). Thanks!
Not that bizarre. The rendered version simply always looks the same, and assumes that Other Params belongs before instead of after Returns. The doc standard simply disagrees with pydocweb here. I don't have a strong opinion on which one is preferable, but it should be fixed.
Cheers, Ralf
On Mon, Mar 15, 2010 at 4:13 PM, <josef.pktd@gmail.com> wrote:
On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
Also, optional parameters for any optimize functions are not described in the draft of the Scipy reference manual I came across while googling this issue. For instance, at
http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html...
fmin does not have the optional arguments detailed. If this is automatically generated is there a reason why the optional parameters aren't being shown in this document? I think they should be, IMO.
just a guess:
http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/
shows that Other Parameters is in the wrong order. It could be that the section is ignored for rendering the html for this reason
Josef
-Rob _______________________________________________ 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
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Mon, Mar 15, 2010 at 8:13 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Mar 16, 2010 at 7:50 AM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
This is *very* bizarre: in View mode, Other parameters is displayed before Returns, but in the edit frame in Edit mode, Returns is displayed above Other parameters, but then if I preview, the preview displays it incorrectly, even though in the edit frame, it's still correct!!! Can someone verify this on another platform/in another browser, please? (Mine: Windows Vista, Firefox 3.6). Thanks!
Not that bizarre. The rendered version simply always looks the same, and assumes that Other Params belongs before instead of after Returns. The doc standard simply disagrees with pydocweb here. I don't have a strong opinion on which one is preferable, but it should be fixed.
Independent of the display, the other parameters section doesn't show up in the html docs. The only example that I found in numpy is recarrays, there the sequence is reversed but it also doesn't show up in the html http://docs.scipy.org/numpy/docs/numpy.core.records.recarray/ http://docs.scipy.org/doc/numpy/reference/generated/numpy.recarray.html?high... Josef
Cheers, Ralf
On Mon, Mar 15, 2010 at 4:13 PM, <josef.pktd@gmail.com> wrote:
On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
Also, optional parameters for any optimize functions are not described in the draft of the Scipy reference manual I came across while googling this issue. For instance, at
http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html...
fmin does not have the optional arguments detailed. If this is automatically generated is there a reason why the optional parameters aren't being shown in this document? I think they should be, IMO.
just a guess:
http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/
shows that Other Parameters is in the wrong order. It could be that the section is ignored for rendering the html for this reason
Josef
-Rob _______________________________________________ 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
_______________________________________________ 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
On Tue, Mar 16, 2010 at 8:22 AM, <josef.pktd@gmail.com> wrote:
On Mon, Mar 15, 2010 at 8:13 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Mar 16, 2010 at 7:50 AM, David Goldsmith <
d.l.goldsmith@gmail.com>
wrote:
This is *very* bizarre: in View mode, Other parameters is displayed
before
Returns, but in the edit frame in Edit mode, Returns is displayed above Other parameters, but then if I preview, the preview displays it incorrectly, even though in the edit frame, it's still correct!!! Can someone verify this on another platform/in another browser, please? (Mine: Windows Vista, Firefox 3.6). Thanks!
Not that bizarre. The rendered version simply always looks the same, and assumes that Other Params belongs before instead of after Returns. The doc standard simply disagrees with pydocweb here. I don't have a strong opinion on which one is preferable, but it should be fixed.
Independent of the display, the other parameters section doesn't show up in the html docs.
Yes that seems to be a bug. I added this to the related pydocweb problem with section ordering here: http://code.google.com/p/pydocweb/issues/detail?id=45
The only example that I found in numpy is recarrays, there the sequence is reversed but it also doesn't show up in the html
http://docs.scipy.org/numpy/docs/numpy.core.records.recarray/
http://docs.scipy.org/doc/numpy/reference/generated/numpy.recarray.html?high...
There's an issue with section headers there as well because recarray is a
class and is not supposed to have a Returns section. So don't think that tells you anything. Cheers, Ralf
On Mon, Mar 15, 2010 at 5:13 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Tue, Mar 16, 2010 at 7:50 AM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:
This is *very* bizarre: in View mode, Other parameters is displayed before Returns, but in the edit frame in Edit mode, Returns is displayed above Other parameters, but then if I preview, the preview displays it incorrectly, even though in the edit frame, it's still correct!!! Can someone verify this on another platform/in another browser, please? (Mine: Windows Vista, Firefox 3.6). Thanks!
Not that bizarre. The rendered version simply always looks the same, and assumes that Other Params belongs before instead of after Returns. The doc standard simply disagrees with pydocweb here. I don't have a strong opinion on which one is preferable, but it should be fixed.
Right, I forgot that I myself reported this as a ticketed known problem in the Q&A section. So that half the problem is (un)solved. :-( DG
Cheers, Ralf
On Mon, Mar 15, 2010 at 4:13 PM, <josef.pktd@gmail.com> wrote:
On Mon, Mar 15, 2010 at 7:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
Also, optional parameters for any optimize functions are not described in the draft of the Scipy reference manual I came across while googling this issue. For instance, at
http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.fmin.html...
fmin does not have the optional arguments detailed. If this is automatically generated is there a reason why the optional parameters aren't being shown in this document? I think they should be, IMO.
just a guess:
http://docs.scipy.org/scipy/docs/scipy.optimize.optimize.fmin/
shows that Other Parameters is in the wrong order. It could be that the section is ignored for rendering the html for this reason
Josef
-Rob _______________________________________________ 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
_______________________________________________ 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
On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
OK, folks, so what's the _desired_ behavior: absolute or relative error (i.e., where's the bug: in the code or in the doc)? DG
On Fri, Mar 19, 2010 at 3:16 PM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
OK, folks, so what's the _desired_ behavior: absolute or relative error (i.e., where's the bug: in the code or in the doc)?
I think the docs should reflect the actual behavior of the function. Whether the criteria will be changed and made consistent across functions is a different question. But it's not a bug, so the docs should adjust. my opinion Josef
DG _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Fri, Mar 19, 2010 at 12:37 PM, <josef.pktd@gmail.com> wrote:
On Fri, Mar 19, 2010 at 3:16 PM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
OK, folks, so what's the _desired_ behavior: absolute or relative error (i.e., where's the bug: in the code or in the doc)?
I think the docs should reflect the actual behavior of the function. Whether the criteria will be changed and made consistent across functions is a different question. But it's not a bug, so the docs should adjust.
my opinion
Josef
Well, I'm pretty sure we formally adopted the opposite policy: the docs should reflect _desired_ behavior - if the code doesn't implement desired behavior then a bug report is to be filed. (I thought this was in the Wiki Q&A section, but apparently not, so, UIAM, it's "only" in an email thread somewhere). Can anyone else confirm and, hopefully, supply a link to the email thread in which this was discussed? DG
On Fri, Mar 19, 2010 at 4:05 PM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Fri, Mar 19, 2010 at 12:37 PM, <josef.pktd@gmail.com> wrote:
On Fri, Mar 19, 2010 at 3:16 PM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
OK, folks, so what's the _desired_ behavior: absolute or relative error (i.e., where's the bug: in the code or in the doc)?
I think the docs should reflect the actual behavior of the function. Whether the criteria will be changed and made consistent across functions is a different question. But it's not a bug, so the docs should adjust.
my opinion
Josef
Well, I'm pretty sure we formally adopted the opposite policy: the docs should reflect _desired_ behavior - if the code doesn't implement desired behavior then a bug report is to be filed. (I thought this was in the Wiki Q&A section, but apparently not, so, UIAM, it's "only" in an email thread somewhere). Can anyone else confirm and, hopefully, supply a link to the email thread in which this was discussed?
I know of that policy, but there are a lot of mistakes in the docs, and I don't think we change the code to match the mistakes in the docs. But you can also file a ticket for changing and reviewing convergence criteria I don't think relative (to what?) error makes much sense if x or f goes to zero. Josef
DG _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
On Fri, Mar 19, 2010 at 1:09 PM, <josef.pktd@gmail.com> wrote:
On Fri, Mar 19, 2010 at 4:05 PM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Fri, Mar 19, 2010 at 12:37 PM, <josef.pktd@gmail.com> wrote:
On Fri, Mar 19, 2010 at 3:16 PM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
OK, folks, so what's the _desired_ behavior: absolute or relative error (i.e., where's the bug: in the code or in the doc)?
I think the docs should reflect the actual behavior of the function. Whether the criteria will be changed and made consistent across functions is a different question. But it's not a bug, so the docs should adjust.
my opinion
Josef
Well, I'm pretty sure we formally adopted the opposite policy: the docs should reflect _desired_ behavior - if the code doesn't implement desired behavior then a bug report is to be filed. (I thought this was in the Wiki Q&A section, but apparently not, so, UIAM, it's "only" in an email thread somewhere). Can anyone else confirm and, hopefully, supply a link to the email thread in which this was discussed?
I know of that policy, but there are a lot of mistakes in the docs, and I don't think we change the code to match the mistakes in the docs.
No, of course not, but the idea is that a "mistake" in the doc is not a mistake if in fact it documents the desired behavior (and thus the real mistake is in the code, in which case we've basically agreed that we _will_ change the code to match the doc; for better or worse, this means that when "mistakes" are found in the docs - mistakes which in fact may not be mistakes but only appear to be so because they don't match code behavior - we will need to address them on a case-by-case basis, such as is being done in this instance).
But you can also file a ticket for changing and reviewing convergence criteria
OK, yours is a "vote" for "bug in the doc."
I don't think relative (to what?) error makes much sense if x or f goes to zero.
Josef
Agreed: the most robust behavior it to allow specification of both types of tolerance. DG
On Fri, Mar 19, 2010 at 4:51 PM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Fri, Mar 19, 2010 at 1:09 PM, <josef.pktd@gmail.com> wrote:
On Fri, Mar 19, 2010 at 4:05 PM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Fri, Mar 19, 2010 at 12:37 PM, <josef.pktd@gmail.com> wrote:
On Fri, Mar 19, 2010 at 3:16 PM, David Goldsmith <d.l.goldsmith@gmail.com> wrote:
On Mon, Mar 15, 2010 at 4:05 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
In both my old version and the one in the svn trunk there is an inconsistency in the docstring of scipy.optimize.fmin.
Other Parameters ---------------- xtol : float Relative error in xopt acceptable for convergence. ftol : number Relative error in func(xopt) acceptable for convergence.
As you see from the following code snippet from the body of the function, the convergence test is in terms of absolute error for both x and f, as the sim array contains x values and fsim the function values.
if (max(numpy.ravel(abs(sim[1:]-sim[0]))) <= xtol \ and max(abs(fsim[0]-fsim[1:])) <= ftol): break
OK, folks, so what's the _desired_ behavior: absolute or relative error (i.e., where's the bug: in the code or in the doc)?
I think the docs should reflect the actual behavior of the function. Whether the criteria will be changed and made consistent across functions is a different question. But it's not a bug, so the docs should adjust.
my opinion
Josef
Well, I'm pretty sure we formally adopted the opposite policy: the docs should reflect _desired_ behavior - if the code doesn't implement desired behavior then a bug report is to be filed. (I thought this was in the Wiki Q&A section, but apparently not, so, UIAM, it's "only" in an email thread somewhere). Can anyone else confirm and, hopefully, supply a link to the email thread in which this was discussed?
I know of that policy, but there are a lot of mistakes in the docs, and I don't think we change the code to match the mistakes in the docs.
No, of course not, but the idea is that a "mistake" in the doc is not a mistake if in fact it documents the desired behavior (and thus the real mistake is in the code, in which case we've basically agreed that we _will_ change the code to match the doc; for better or worse, this means that when "mistakes" are found in the docs - mistakes which in fact may not be mistakes but only appear to be so because they don't match code behavior - we will need to address them on a case-by-case basis, such as is being done in this instance).
Sorry if I was ambiguous, my initial statement was about the specific case of the fmin, not reflecting an opinion about a general policy. I agree we have to check case by case. my "bug in docs" is for this case only Josef
But you can also file a ticket for changing and reviewing convergence criteria
OK, yours is a "vote" for "bug in the doc."
I don't think relative (to what?) error makes much sense if x or f goes to zero.
Josef
Agreed: the most robust behavior it to allow specification of both types of tolerance.
DG _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
Hi,
Agreed: the most robust behavior it to allow specification of both types of tolerance.
Yes, definitely. Most numerical algorithms for optimization / root finding can benefit from a range of stopping conditions for different usage situations. But beyond just the abs and rel tolerances in x, it can be useful to also provide an absolute tolerance for the size of f to declare it small enough (ftol) regardless of how close the x values are. These conditions are very easy to add to the code. The whole point of absolute tolerances is to take care of the possibilities of x, f going to zero and ruining the meaning of relative error. But for large values of x or f their relative error tolerances make a lot of sense. -Rob
On Sat, Mar 20, 2010 at 9:30 AM, Rob Clewley <rob.clewley@gmail.com> wrote:
Hi,
Agreed: the most robust behavior it to allow specification of both types of tolerance.
Yes, definitely. Most numerical algorithms for optimization / root finding can benefit from a range of stopping conditions for different usage situations. But beyond just the abs and rel tolerances in x, it can be useful to also provide an absolute tolerance for the size of f to declare it small enough (ftol) regardless of how close the x values are. These conditions are very easy to add to the code.
The whole point of absolute tolerances is to take care of the possibilities of x, f going to zero and ruining the meaning of relative error. But for large values of x or f their relative error tolerances make a lot of sense.
-Rob
Rob: since no one else (besides Josef of course) is chiming in (in particular, to "block"), may I suggest/request that you: 0) file an "enhancement" ticket for this improvement; 1) if you have the time and wherewithal, "own" the ticket, implement the improvement (taking care to do so in such a way that the function's extant API is not broken), and submit your patch; 2) then either update the docstring accordingly or let me know when you're done (or at least have the details of your implementation mapped out) and I will update the docstring. If you need guidance in any of this (e.g., locating the scipy developer's Trac page whereon tickets are filed) - or are just to swamped - let me know and I'll be happy to help. Thanks for reporting this. DG
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
David,
Rob: since no one else (besides Josef of course) is chiming in (in particular, to "block"), may I suggest/request that you:
0) file an "enhancement" ticket for this improvement;
Done
1) if you have the time and wherewithal, "own" the ticket, implement the improvement (taking care to do so in such a way that the function's extant API is not broken), and submit your patch;
I don't see how to take ownership on the trac site. Please direct me!
If you need guidance in any of this (e.g., locating the scipy developer's Trac page whereon tickets are filed) - or are just to swamped - let me know and I'll be happy to help. Thanks for reporting this.
I am pretty swamped but sooner or later I will feel the OCD take over and do something about it. Of course others are welcome in the meantime. -Rob
On Sun, Mar 21, 2010 at 2:14 PM, Rob Clewley <rob.clewley@gmail.com> wrote:
David,
Rob: since no one else (besides Josef of course) is chiming in (in particular, to "block"), may I suggest/request that you:
0) file an "enhancement" ticket for this improvement;
Done
Great, thanks!
1) if you have the time and wherewithal, "own" the ticket, implement the improvement (taking care to do so in such a way that the function's extant API is not broken), and submit your patch;
I don't see how to take ownership on the trac site. Please direct me!
Yeah, I'm not getting an "Assign to" field either, nor could I readily find instructions vis-a-vis gaining ownership privileges: my guess is that you have to ask for "assume ownership" privileges (presumably here) and, assuming they're granted, when you re-login and visit the ticket's page, then you'll see the "Assign to" drop down w/ your account name in it. (This said, it appears that you can submit a patch w/out having to claim ownership, so I imagine you could treat this entire step as optional.)
If you need guidance in any of this (e.g., locating the scipy developer's Trac page whereon tickets are filed) - or are just to swamped - let me know and I'll be happy to help. Thanks for reporting this.
I am pretty swamped but sooner or later I will feel the OCD take over and do something about it. Of course others are welcome in the meantime.
Of course. ;-) Thanks again! DG
-Rob _______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (4)
-
David Goldsmith -
josef.pktd＠gmail.com -
Ralf Gommers -
Rob Clewley