bugGNU Octave - Bugs: bug #33792, default tolerances for quad...

 
 

bug #33792: default tolerances for quad integration routines differ from Matlab

Submitter:  Ben Abbott <bpabbott>
Submitted:  Mon 18 Jul 2011 11:37:00 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Confirmed Assigned to:  None
Originator Name:  Ben Abbott Open/Closed:  * Closed
Release:  * dev Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 13 Mar 2013 10:56:52 PM UTC, comment #9: 

It appears that there is more to this than just tolerance
value changes.  There is the rel/abs tol question below.

Also, Matlab's handling of 754 precision is not seen as
helpul by Kahan.  See:
http://www.cs.berkeley.edu/~wkahan/MxMulEps.pdf

It seems to me that while Matlab compatibility is a good
general goal, sacrificing available precision to achieve
"compatibility" is not appropriate.  Maybe "as good as
or better" would make sense here.

So, at least for now, since the main bug reported below has been
fixed, I would say to close this unless someone has a definite
reason (other than Matlab) to change some tolerances.

Michael Godfrey <godfrey>
Group Member
Wed 13 Mar 2013 10:24:32 PM UTC, comment #8: 

This is quite old now, but should we move Octave integration tolerances to match Matlab's?  It just means editing the defaults in the m-files and this bug report contains the values from Matlab.

Rik <rik5>
Group administrator
Thu 25 Aug 2011 05:01:27 PM UTC, comment #7: 

The original error of not working with large tolerances has been fixed in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/85dac13a911b).  I have re-titled the bug report to reflect the other discussion points raised about default tolerances differing from Matlab.

Rik <rik5>
Group administrator
Mon 01 Aug 2011 03:52:28 PM UTC, comment #6: 

Here is the comparison (oct_ vs. ml_):

*) oct_quad uses abs_tol or [abs_tol,rel_tol] (default [sqrt(eps),sqrt(eps)], ml_quad uses abs_tol (default 1e-6): so, the default in oct_quad should be modified in [1e-6,0]. After that, it is compatible and more general.

*) oct_quadl uses rel_tol (default eps(class(a))), ml_quad uses abs_tol (default 1e-6): in my opinion, oct_quadl should be modified in order to support [abs_tol,rel_tol] with default [1e-6,0]. After that, it is compatible and more general.

*) oct_quadgk uses abs_tol or quadgk(...,'AbsTol',abs_tol,'RelTol',rel_tol,...) (default abs_tol=1e-10, rel_tol=1e-5), ml_quadgk uses only the latter syntax, with different default values depending on the class 'single' or 'double' (in any case, never [1e-6,0]). It means that ml cannot use the common syntax


quadgk(f,a,b,tol)


In this case, I would keep the possibility to give abs_tol, [abs_tol,rel_tol] or quadgk(...,'AbsTol',abs_tol,'RelTol',rel_tol,...). About the default values, I don't know what is best (ml default or [1e-6,0]?)

Marco

Marco Caliari <caliari>
Group Member
Mon 01 Aug 2011 03:12:58 PM UTC, comment #5: 

Marco,

Assuming you've looked into it, can you give us a short summary for how the tolerance for Octave's quad, quadl, quadgk differ from ML's?

I assume we'd like to patch each of them so that they are ML compatible.

Ben

Ben Abbott <bpabbott>
Group Member
Mon 01 Aug 2011 02:44:58 PM UTC, comment #4: 

Dear Ben,

Matlab passes because it uses the absolute tolerance, whereas Octave the relative. If you try


>> quadl(@(x) sin (2 + 3*x).^2, 0, 10, 0.3 * 7.6082)


where 7.6082 is the (quite bad) value used by Octave as magnitude estimate, you get the same result 8.1963 in Matlab. In the Matlab help, it is written that "QUAD may be most efficient for low accuracies": may we also add such a warning in the help?

Now, among the four quadrature formulas quad, quadl, quadgk and quadcc there are four different default values for the tolerances and three types of absolute/relative choices of the tolerance. Isn't it confusing?

Best regards,

Marco

Marco Caliari <caliari>
Group Member
Tue 19 Jul 2011 06:20:14 PM UTC, comment #3: 

Up to you whether this test should be in an xtest or not.  My only concern is that if it moves in to an xtest it will be forgotten, but maybe that isn't a problem since this bug report will remain.

As for xassert, I'm attaching a trivial implementation.  The only issue is that test.m assumes it can call a function xassert which means I needed to add xassert.m to the test/ directory.  One could be fancier and strip off the 'x' before calling eval and then restore it when printing and get around needing another function.

(file #23677)

Rik <rik5>
Group administrator
Tue 19 Jul 2011 04:19:25 PM UTC, comment #2: 

Maybe this test (and any others that represent unfixed but known bugs) should be inside xtest blocks?

BTW, since %!assert is just short for %!test assert ..., maybe we should also have %!xassert as a shorter way of saying %!xtest assert ...?

John W. Eaton <jwe>
Group administrator
Mon 18 Jul 2011 11:17:18 PM UTC, comment #1: 

This problem was uncovered during the code sprint and a test was added to highlight the fact.  The issue is that at large, sloppy integration tolerances quadl seems to fail completely.  The same sloppy tolerances work fine with other integrators such as quadcc and quadv so it is definitely an issue with quadl.

Rik <rik5>
Group administrator
Mon 18 Jul 2011 11:37:00 AM UTC, original submission:  

"make check" on the default branch gives ....


  ***** assert ( quadl (@(x) sin (2 + 3*x).^2, 0, 10, 0.3, []),
        (60 + sin(4) - sin(64))/12, -0.3)
!!!!! test failed
assert (quadl (@(x) sin (2 + 3 * x) .^ 2, 0, 10, 0.3, []),(60 + sin (4) - sin (64)) / 12,-0.3) expected
 4.8603
but got
 8.1963
maximum relative error 0.686392 exceeds tolerance 0.3


I get the same result with the stable branch (although the test does not part of quadl)

Matlab passes, so I assume the test is correct, but there is some problem with quadl.


>> [quadl(@(x) sin (2 + 3*x).^2, 0, 10, 0.3, []),
        (60 + sin(4) - sin(64))/12]

ans =

   4.859710511212103
   4.860264288874607


Ben

Ben Abbott <bpabbott>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #23677:  xassert.changeset added by rik5 (3KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by caliari (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by bpabbott (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-03-19 rik5 Open/ClosedOpen Closed
    2011-08-25 rik5 Item GroupIncorrect Result Matlab Compatibility
        Summaryquadl fails for large integeration tolerances default tolerances for quad integration routines differ from Matlab
    2011-07-19 rik5 Attached File- Added xassert.changeset, #23677
    2011-07-18 rik5 StatusNone Confirmed
        Summaryquadl test failure on default branch quadl fails for large integeration tolerances

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code