Tue 17 Sep 2013 02:08:01 PM UTC, comment #18:
Opps! ... They're attached
(file #29162, file #29163)
|
Tue 17 Sep 2013 01:38:59 PM UTC, comment #17:
Ben, could you try attaching the files again? I don't see them.
|
Tue 17 Sep 2013 02:33:21 AM UTC, comment #16:
Rik, I've attached the results from Matlab. Looks like Octave and Matlab produce the same result for this example.
|
Tue 17 Sep 2013 12:30:22 AM UTC, comment #15:
Thanks Ben. From Matlab's documentation, 'align' is the default option and only option that can be set. In other words, there isn't actually a choice. it looks like it is equivalent to what Octave is doing by default. Octave also has a different mode, activated by 'align', which aligns the 'position' properties rather than 'outerposition'. Should we get rid of this?
This script, shows the different results of using align, or not, in Octave.
I uploaded the two png files so you can see the difference. Because of a bug with multi-line labels in FLTK I had to take screenshots rather than send the results of the print command.
(file #29156, file #29157)
|
Mon 16 Sep 2013 11:21:29 PM UTC, comment #14:
Rik, I've attached subplot_tst.png using Matlab R2013a
(file #29155)
|
Mon 16 Sep 2013 10:53:16 PM UTC, comment #13:
Can someone with Matlab run the following and upload the png file to this bug report? According to Matlab documentation the "align" option is the default, but Octave does not default to that.
|
Mon 16 Sep 2013 10:48:33 PM UTC, comment #12:
I checked in a change which mostly works (http://hg.savannah.gnu.org/hgweb/octave/rev/9304514b566c). It uses the "outerposition" versus "position" to determine if an axes has changed.
|
Mon 16 Sep 2013 10:46:31 PM UTC, comment #11:
I'm adding Ben to the e-mail list for this bug since it seems to be related to behavior around using "position" versus "outerposition".
|
Wed 28 Aug 2013 10:31:14 PM UTC, comment #10:
I think that treating this as a bug and fixing it
is the right choice. This provides compatibility
with 3.6.4 and even with Matlab!
And, having a call to subplot() on an existing
plot be destructive is not very friendly.
|
Wed 28 Aug 2013 04:40:02 PM UTC, comment #9:
This bug was caused by the vagueness of the Matlab documentation. The backend low-level plotting routines were recently overhauled and the documentation seemed to suggest that calling subplot would initialize the axes, and that the way to switch to an existing axes was to use a handle:
This can be fixed.
|
Tue 27 Aug 2013 01:48:50 PM UTC, comment #8:
Thanks for checking Matlab.
The bug and documentation will be fixed.
|
Tue 27 Aug 2013 08:41:30 AM UTC, comment #7:
Sorry, it seems that it wasn't enough in my previous post.
Michael Goffioul said:
>> I think what the OP means is that if a plot already exists in subplot 211, then the simple call subplot(2,1,1) should not erase it.
Yes, I think so.
To Michael Godfrey:
When I checked that on Matlab, 2nd call of "subplot(2,1,1)" does not erase it.
|
Tue 27 Aug 2013 03:58:49 AM UTC, comment #6:
Forgot to add: documentation should be fixed
when bug is corrected.
|
Tue 27 Aug 2013 03:57:38 AM UTC, comment #5:
This is a regression with respect to 3.6.4,
so it is a bug. If compatibility with 3.6.4
is wanted then subplot(2,1,INDEX) should
just make it current, as you said.
When/if my license server gets going I will
check on Matlab.
|
Tue 27 Aug 2013 03:32:38 AM UTC, comment #4:
Below Michael Goffioul said: I think what the OP means is that if a plot already exists in subplot 211, then the simple call subplot(2,1,1) should not erase it.
That might be a good choice, but the documentation of subplot
does say that the call initializes the subplot.
I tried to see what Matlab does, but server license server
seems to be down.
|
Tue 27 Aug 2013 03:24:25 AM UTC, comment #3:
I think what the OP means is that if a plot already exists in subplot 211, then the simple call subplot(2,1,1) should not erase it. It should only make the subplot 211 the current one (that is, the one where the next plot command will be applied).
If I understand correctly, you can't do the following at the moment:
|
Tue 27 Aug 2013 03:17:04 AM UTC, comment #2:
It is not clear what you wanted.
subplot(2,1,INDEX) initializes
the subplot given by INDEX. This
is what happened in your example.
If you wanted to draw another subplot,
subplot(2,1,2) will initialize the
second subplot.
There does not appear to be a bug
in this.
|
Tue 27 Aug 2013 02:51:46 AM UTC, comment #1:
Sorry. I forgot to write my environment in my previous post.
GNU Octave Version 3.7.6+
GNU/Linux Debian 7(Wheezy) x86
|
Tue 27 Aug 2013 02:45:17 AM UTC, original submission:
I found a bug about subplot().
#EXAMPLE
subplot(2,1,1);
plot(1:100);
subplot(2,1,1); % the plot disappears at this timing.
|