Indeed, I had forgotten about this closed report. I reviewed and checked in your changes here (http://hg.savannah.gnu.org/hgweb/octave/rev/47dd094a6239).
Some of the BIST tests were now failing so I redid them and grabbed the BIST tests from quadcc, those with "WayPoints" from quadgk, and kept the ArrayValued tests from quadv.
I changed to using a simple if statement rather than using ifelse since it is more efficient unless the computed branches are particularly simple, like a constant.

oops, always a second too late. I see that patch version had the wrong bug number. fixed here in v3
(file #42185)

tweaked version of the last patch that preserves type single output.
(file #42184)

patch updating integral to make more use of new quadcc attached. again, I'm not set up to compile and actually use the new quadcc until it appears in a released windows build, so you may want to check the tests before pushing this.
(file #41903)

ok, now that the integral2 and 3 patch is pushed, I'll tweak integral to use quadcc sometime soon.

I think so. Not only is quadcc faster than quadgk, because it is a compiled function rather than an mfile, but it can readily handle nonsmooth integrands with weird discontinuities including NaNs. If a user knows something about the specifics of the integrand, such as it being smooth and continuous, then they can choose the integrator that best suits the problem. But if you don't know anything about it, and only have a handle to the function, you need an integrator that can handle strange behavior.

now that quadcc takes both abs and reltol, would it be preferred to mod this function to use quadcc over quadgk if the requested parameters permit? (i.e., use quadcc unless waypoints (then use quadgk) or arrayvalued(then use quadv)...

remembering now. opened a new bug report for integral2 and 3. will detail any issues over there. See Bug #52074

re: dblquad  I initially thought so too when I made this one, but ran into a few problems and stopped. I don't recall what. I'll review and maybe open a new bug report once i have an idea.

I checked in a slightly different change here (http://hg.savannah.gnu.org/hgweb/octave/rev/6570fdb7d3a0). A lot of users will be scientists, not mathematicians, so rather than give them vague advice as Matlab does, "Single precision integrations may require larger tolerances", I chose to use the sensible defaults that quadgk has. They can always try again if their integration fails, but this will allow most integrands to complete successfully.
Also, I redid the precisions in the BIST tests. The tolerance argument of the assert() function is an absolute tolerance when TOL is positive and a relative tolerance when TOL is negative. I used this fact to match a BIST test where AbsTol is specified to a positive TOL for assert() and vice versa if RelTol was specified.
I think enough progress has been made to close this report.
Incidentally, integral2 can probably be implemented similarly as a wrapper around dblquad.

quadv has a default abstol of 1e6 which matches matlab. so for compatibility reasons I think quadv should stay as is.
Simply passing abstol = 1e10 to that integral test has it pass, and best as I can tell versus matlab 2017a this is compatible behavior.
Also, the different error values for double and single are unique to quadgk best as I can tell, and matches matlab quadgk default tolerances according to the help.
There is no specification of different tolerance limits based on class in the help for integral. I had just kept that text there from quadgk, but integral documentation simply states tha abstol default is 1e10, and RelTol is 1e6, and "Single precision integrations may require larger tolerances."
My thoughts on the simplest thing to do that also maintains compatibility is just to pass 1e10 and 1e6 down to the quad functions (throwing a reltol unimplemented warning for quadv until that gets fixed), and remove the 'single' distinction in the help text.
The attached update_integral.diff patch (builds on the checked in version) makes that change to default reltol and abstol and the help text. Also, added tests for checking single vs double input and output to maintain compatibility. last, I switched the matrixvalued test from 1/sqrt(x) to exp(x) to get rid of the singularity warnings during test. a couple minor spacing fixes too.
Also changed my Octave editor setting from CRLF (default on windows) to LF.
(file #41845)

I made some other changes including using the default Copyright notice for Octave, using spaces between the function name and the opening parenthesis, using lower case for variable names such as q, f, a, b, and using only one '#' for singleline comments appearing after code. I checked everything in here (http://hg.savannah.gnu.org/hgweb/octave/rev/2eae2ad53eb9).
I changed one of the arrayvalued tests to use the default AbsTol of 1e10 which now causes it to fail. Although quadgk uses a default of 1e10, quadv uses a default of 1e6.
The integral() function could be changed to pass abstol of 1e10 down to quadv, but I think it would be better to change quadv to simply use these new default values. For one thing, quadv does not distinguish between double and single values and always uses 1e6 by default. That seems wrong. There is code in the input validation for quadgk which could be copied to quadv to make this work.

Sorry, please find attached a new revised version in which I removed a (failing) demo, leftover from a brave (but aborted) intention to add demos :).
I also tried to make tests fit into 80 columns and added ";" at the end of each "assert" call.
(file #41838)

Hi,
I reviewed the coding style (see attached) :
 Not operator: replaced ~ by !
 Comments: replaced % by # and removed a few redundant comments
 Encoding: changed to utf8 with unix LF
 Removed the "author" entry at the end of the help text
I also removed "integral" from the list of unimplemented functions.
I did not change the comments about eventually calling quadgk using arrayfun but I really don't see how this would be possible: quadgk expects a function that accepts vector inputs while "arrayvalued" is supposed to be used with functions that accept scalar inputs.
I will push the patch in the coming days unless someone wants to have a last look.
(file #41835)

I have reviewed mainly its functional behavior (checking the BISTs and some corner cases), and less
coding style and performance issues.

@Avinoam: I think I saw that you had already given one review. Is that correct? That means the second review before committing can be shorter.

Thanks,
@Maintainers: Can you review and push this patch?

oops. here's a patch that includes the function.
(file #41734)

Integral.m seems to be missing

v2 patch attached that fixes the style issues.
(file #41729)

Will check and reupload with style cleanups sometime this weekend
The MATLAB and math works comments just note a section with example problems to solve for compatibility, taken from public facing help and documentation. One of them is integral of log(x)... No copying of code or similar. Could remove or come up with alternate expressions but don't see any issue testing it with the same expressions.
I would prefer any fixes to the inf error be in quadgk and keep this a wrapper. If numerical fixes appear in here it could be a mess to keep track if later if changes happen in quadgk.
If we can make a test do the same with quadgk, and IR the other quads, it might be worth a separate bug report.

Thanks for implementing integral.
I have checked integral function on Win7
All test pass:
Coding style:
1. In the test code, some of the keywords are given with double quotes ("RelTol") and some with single quotes ('AbsTol')
2. Missing some spaces after commas.
Using Matlab examples  Is it legal? What about copyright issues?
Problem with Inf:
Matlab result:
38 is not Inf. Probably the problem is in quadgk and not in integral
What about a simple demo, like:

Here's a first attempt at a wrapper function for integral. Function and patch attached.
For compatibility integral needs to handle only 4 options: RelTol, AbsTol, Waypoints, and Arrayvalued.
If option "ArrayValued" is true, it calls quadv.
Otherwise it will call quadgk. one issue with this approach is that you cannot call ArrayValued along with Waypoints or RelTol. (quadv only takes abstol). at the moment I have it continue with a warning. these could be changed to errors if you think that's a better handling method.
Also, it's possible the combination could be handled by calling arrayfun and quadgk for those cases, but I wasn't able to come up with a form for arrayfun that actually worked.
In any case, this passes all tests and should provide some bit of improved compatibility. haven't looked at whether adding similar wrappers for integral2 and integral3 will be as straightforward.
(file #40052, file #40053)

This issue is still valid in Octave 4.2.0.
(There is still no Octave implementation of integral.)

Sorry, you're quite right. I thought quadcc had been extended to include WayPoints.

>The "WayPoint" feature is also implemented in quadcc.
I cannot find such description in help and manual concerning quadcc.
So I tried: (octave3.8.1 on windows 7)
I simply substitute quadgk by quadcc. The result is
It seems that "WayPoints" feature of quadcc seems not to be implemented in the same way for quadgk.
I pull the code of quadcc.cc in the source tree and search by the keyword 'Waypoints' but nothing is found.
I also the error messages in quadcc.cc,
quadcc: integrand F must return a single, realvalued vector"
quadcc: integrand F must return a single, realvalued vector of the same size as the input
MATLAB function 'integral' supports complex integral so that it can be used only real case.
My observation, only quadgk can handle complex integral in octave.

The "WayPoint" feature is also implemented in quadcc which is a good default integration algorithm because it handles discontinuities, Infinities, WayPoints, as well as simple continuous functions.

I have looked into octave code for quadl, quadv, and quadgk
The 'Waypoints' feature is implemented in quadgk.
Sorry for my poor knowledge for this matter.

The similar discussion is also posted in octavemaintainers ML.
http://octave.1599824.n4.nabble.com/quadwillberemovedinafuturereleaseofMATLABtd4665467.html
MATLAB integral seem to be not just renaming the function from quad to integral.
is new feature of MATLAB integral. In particular, when Name is 'Waypoints', the implementation seems not to be straightforward.
The 'Waypoints' supports complex integral via complex integral path.
http://www.mathworks.co.jp/jp/help/matlab/ref/integral.html?lang=en#btdd9y9

Matlab is deprecating the quad function for numerical integration in favor of integral: http://www.mathworks.com/help/matlab/ref/integral.html
I suppose we should add it for compatibility.
