Wed Mar 13 22:56:52 2013, 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.

Mon Aug 1 15:52:28 2011, 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 1e6): so, the default in oct_quad should be modified in [1e6,0]. After that, it is compatible and more general.
*) oct_quadl uses rel_tol (default eps(class(a))), ml_quad uses abs_tol (default 1e6): in my opinion, oct_quadl should be modified in order to support [abs_tol,rel_tol] with default [1e6,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=1e10, rel_tol=1e5), ml_quadgk uses only the latter syntax, with different default values depending on the class 'single' or 'double' (in any case, never [1e6,0]). It means that ml cannot use the common syntax
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 [1e6,0]?)
Marco

Mon Aug 1 15:12:58 2011, 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

Mon Aug 1 14:44:58 2011, comment #4:
Dear Ben,
Matlab passes because it uses the absolute tolerance, whereas Octave the relative. If you try
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

Tue Jul 19 18:20:14 2011, 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)

Mon Jul 18 11:37:00 2011, original submission:
"make check" on the default branch gives ....
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.
Ben
