Mon 11 Sep 2017 03:43:42 AM UTC, comment #9:
I checked in the change here (http://hg.savannah.gnu.org/hgweb/octave/rev/ec3d37eeafa2).
I made two changes. First, when initializing two variables of the same type the Octave coding convention is too put them on separate lines.
Instead of
we write
Second, I changed the warning IDs to be capitalized, "Octave:...".
|
Sat 02 Sep 2017 06:21:18 AM UTC, comment #8:
Rik, thank you for your interest in the patch. I was already working on it.
Attached is a patch which also handles the case where a script would set the upper and lower axis limit to the same value. It also adds some BIST tests.
I did not yet cross check with what Matlab is doing in these cases and won't be able to until the week after next week. Posting the patch in case you think that Matlab compatibility is not so important in these corner cases.
(file #41714)
|
Fri 01 Sep 2017 10:42:21 PM UTC, comment #7:
Bother. It seems the code base keeps changing before anyone can get to review things. Could you refresh your patch? 3/5 hunks failed when I tried to apply it today (9/1/17).
|
Tue 20 Jun 2017 07:49:04 PM UTC, comment #6:
The patch no longer applies to the current tip. Attached is a refreshed patch.
This patch coincidently also fixes bug #48616 (without the patch provided there). Imho, the patch here is the better one.
(file #40959)
|
Tue 03 Jan 2017 08:06:58 AM UTC, comment #5:
Attached is an alternative patch that moves the checks for Inf limits and limits spanning 0 on logarithmic axes to the graphics backend. With this, setting these limits directly for the axes handle with the "set" function no longer results in an error and gives appropriate warnings.
Additionally, Inf limits are now tight limits for better Matlab compatibility.
I intentionally kept the Octave specific behavior that the adapted (actual) limits are returned when queried (e.g. with "get(gca, 'ylim')").
This change expands a little bit on the original scope of this bug report. I hope it is OK if I post it here.
(file #39353)
|
Fri 30 Dec 2016 02:12:41 PM UTC, comment #4:
Attached is a patch that treats limits that span 0 on logarithmic axes similarly to how Inf limits are treated: the "offending" limit is automatically adjusted.
This is slightly different to what Matlab seems to do. They keep the limits as set in the corresponding property (e.g. "YLim") and only adjust the on-screen limits. They do the same for "Inf".
That means that in Matlab there is no way that I'm aware of to get the actual axis limits. Thus, this difference might be a feature of Octave.
However, we might need to treat Inf and offending limits directly in the graphics backend anyway. They still fail when setting the properties directly rather than using the higher level functions (i.e. "set (gca, 'ylim', [-Inf 1]);" rather than "ylim ([-Inf 1])").
Should I open a new bug report for this or should we continue here?
(file #39331)
|
Wed 16 Nov 2016 11:47:58 PM UTC, comment #3:
Confirmed, there is still a problem in the current development version (4.3.0+) with the Qt toolkit running this example
Using gnuplot, the error message is still present but the plot figure is not affected and the area remains visible and unchanged.
|
Tue 17 Nov 2015 10:05:26 PM UTC, comment #2:
Seems to be solved:
The only problem is the line: "error: out of memory or dimension too large for Octave's index type". It should give the same error as before
"omitting non-positive data in log plot"
|
Fri 14 Nov 2014 02:43:23 PM UTC, comment #1:
My guess is that it is trying to take the log -.1
try ylim(.1,10) and see what the plot looks like.
Thanks for your answer. But the bug is not in ylim([-.1,10]) since a correct error message is given. The bug is for ylim([0,10]) where no error message is given and the figure disappears. Of course this is because log(0)=nan, though octave should handle this.
OK now it is clear where the bug is.
|
Fri 14 Nov 2014 12:29:20 PM UTC, original submission:
error: memory exhausted or requested size too large for range of Octave's index type -- trying to return to prompt
gave an error, plot does not change -> ok
plot disappears, the figure window gets empty, the cursor position is [nan,nan]
|