Sun Nov 20 22:26:30 2016, comment #6:
This (remaining) issue is still present in Octave 4.2.0.
(The code line from comment #5 still gives me yaxis limits of +300000.)

Thu Jul 11 16:32:20 2013, comment #5:
I overhauled fplot in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/b34202b24212). I upgraded it to be more Matlab compatible and I added an additional stopping condition to detect when the algorithm is failing. This works for functions which end up having a relative tolerance that won't converge because the function value at 0 is near 0. However, the real longterm fix is to add an adapative scaling algorithm of the sort used in the quadrature routines. Basically, the current algorithm is no good if the function contains discontinuities. Try
to see just how bad.

Thu May 16 14:26:06 2013, comment #4:
I've changed the category as this also occurs for OpenGL plotting.
I tried the example in Matlab R2013a. Matlab's fplot() limits the number of points to 111 for this example to 111.
I've included two more examples for reference.
I can run additional examples if it is helpful.

Fri May 10 23:34:02 2013, comment #3:
Ok, I looked at this a little deeper. The default tolerance is the same in all cases, 2e3. Fplot iteratively interpolates the given function over increasing ranges of x until the maximum error falls below that threshold. Your particular function simply never converges, at least using the calculation of error in there now.
I think convergence is failing on certain functions that have very small values near the origin where interpolation is slightly off, such that small absolute errors become large relative errors. Besides your function "x^2 * sin(x)", another example function that doesn't converge is "x^2 + x^4". Another is "(exp(x)1)^2".
It could be argued that the method for calculating convergence could be improved to fix this problem. Needs input from someone with a stronger mathematical background than mine.

Fri May 10 21:31:41 2013, comment #2:
Why does it use the default tolerance for the first but not the second? It shouldn't be dependent on the function. If it is, it shouldn't change by orders of magnitude by simply subtracting 1 from the function I'm plotting.
I'm creating an example for a tutorial and I'm wondering how to explain the unexpected behavior.

Fri May 10 17:58:39 2013, comment #1:
Confirmed, but no I don't think it's a bug. The third argument to fplot gives you control over how many points or how accurate the plot should be made. Your second plot is slow because of the particular function you are evaluating and the default tolerance of fplot, not simply because something was changed. If you limit the plot to a fixed number of points you should see no change in speed.
Does that address the problem?

Fri May 10 17:15:31 2013, original submission:
print takes a very long time when changing the plot in a minor way.
octave:1> fplot('x^2*sin(x)+1',[2 2]),tic,print(1, "a.png","dpng"),toc
Elapsed time is 0.707911 seconds.
octave:2> fplot('x^2*sin(x)+0',[2 2]),tic,print(1, "b.png","dpng"),toc
Elapsed time is 14.3234 seconds.
I'm not complaining, I just think it's very very odd. I get this behavior consistently. Can anyone offer an explanation if this isn't a bug?
