Mon 13 Nov 2017 05:34:49 PM UTC, comment #11:
This issue might be related to bug #49167.
There is probably something wrong in axes::properties::sync_positions in graphics.cc that leads to an erroneous "position" property after certain changes.
|
Tue 24 Oct 2017 10:48:40 PM UTC, comment #10:
Yes, the position value looks bonkers. Interestingly, if I run the failing code, but then set the position value back to its default, the plot looks okay.
My new guess is that the behavior is caused by something wrong with the order of callbacks and listeners. After the plot command, because the axes are set to auto-adjust, there should be a cascade of listeners fired.
|
Mon 23 Oct 2017 11:15:49 PM UTC, comment #9:
This looks like an important difference in the axes properties when plotting rand(20,1)/100 versus rand(20,1)/1000 after hold on:
All other properties look comparable / sane.
This is the same with gnuplot, even though the axes actually fit in the gnuplot window.
|
Mon 23 Oct 2017 10:46:38 PM UTC, comment #8:
Actually with the gnuplot toolkit I get the warning message from legend, indicating that something in the underlying properties may be behaving the same, but the on-screen rendering in the gnuplot window looks correct. It may be that Octave is doing the same incorrect thing in all toolkits, but gnuplot is compensating for the bad instructions in its on-screen rendering.
|
Mon 23 Oct 2017 10:38:39 PM UTC, comment #7:
As a temporary workaround, even though the syntax is supposed to work, it would be better to plot the data and only afterwards add annotations such as labels and legends.
|
Mon 23 Oct 2017 10:35:58 PM UTC, comment #6:
This seems to only be a problem with the OpenGL toolkits. With gnuplot it works. This suggests that there might be a problem with the limited resolution (single) of OpenGL versus the doubles that gnuplot uses. But that might be a red herring.
|
Mon 23 Oct 2017 08:40:52 PM UTC, comment #5:
It seems to me the problem has to do with calling "hold on" before plotting any data, then plotting a series that is vastly out of range of the axes that are shown, which already messes up the plot even before legend is called.
For example
This results in a figure that has a y axis scaled out of proportion and out of the plot area. Calling legend now shows the original warning message, but legend is not really the problem here. It's the interaction between a held axes and the relative scaling of the data that is plotted next.
|
Mon 23 Oct 2017 04:33:30 PM UTC, comment #4:
yes -- hold on is causing the problem
load xx % loads a data file (attached)
#figure(4)
hold on
xlabel('age')
ylabel('var field')
plot(res(1,:),res(5,:))
legend('b;sim-up;')
hold off
this fails
|
Mon 23 Oct 2017 04:16:24 PM UTC, comment #3:
It is "hold on" that causing the problem.
Dmitri.
--
|
Mon 23 Oct 2017 04:07:14 PM UTC, comment #2:
Yes, that works, but my syntax should also be allowed, right?
That's how 'help plot' shows it.
Note that the bug only occurs reliably on a fresh instance.
|
Mon 23 Oct 2017 02:37:11 PM UTC, comment #1:
is this what you wanted?
load xx % loads a data file (attached)
figure(4)
xlabel('age')
ylabel('var field')
plot(res(1,:),res(5,:))
legend('b;sim-up;')
|
Mon 23 Oct 2017 02:01:07 PM UTC, original submission:
The following script produces a weird warning about division by zero in the legend code.
load xx % loads a data file (attached)
figure(4)
xlabel('age')
ylabel('var field')
hold on
plot(res(1,:),res(5,:),'b;sim-up;')
This produces the warnings
#warning: division by zero
warning: called from
legend at line 815 column 20
_plt_ at line 152 column 7
plot at line 223 column 10
warning: division by zero
warning: called from
legend at line 900 column 11
_plt_ at line 152 column 7
plot at line 223 column 10
In legend.m there is a division by lpos(3) on those lines.
I have been trying to narrow it down, but
interestingly, most variants work ok....
octave-cli -v
GNU Octave, version 4.2.1
I'm using gnuplot but fltk also gives the problem.
|