Tue 29 Mar 2011 11:08:07 PM UTC, comment #21:
I've pushed the changeset.
|
Tue 29 Mar 2011 08:53:20 PM UTC, comment #20:
I don't see this error on my machine, but the patch also doesn't cause any new problems for me. Can it be committed and this bug report closed?
|
Fri 11 Mar 2011 08:22:46 PM UTC, comment #19:
This is getting embarrassing for me! ;-)
(file #22905)
|
Fri 11 Mar 2011 04:47:23 PM UTC, comment #18:
And we need a fifth one: I still see min instead of max in tmp_lims(1)...
Marco
|
Fri 11 Mar 2011 03:42:30 PM UTC, comment #17:
Ok. Fourth version is attached.
(file #22902)
|
Fri 11 Mar 2011 03:09:18 PM UTC, comment #16:
And it is not correct: it should be
(max and not min).
Marco
|
Fri 11 Mar 2011 03:02:40 PM UTC, comment #15:
Your patch also contains something related with listeners. Was it intentional?
Marco
|
Fri 11 Mar 2011 02:57:32 PM UTC, comment #14:
Good point Marco.
My 3rd changeset is attached.
(file #22901)
|
Fri 11 Mar 2011 08:43:18 AM UTC, comment #13:
Dear Ben,
your patch works for me (I get 7.0 and 7.5 from get(gca,"ylim")). I would change the last part of your patch into
which gives me the same result, should work in general and does not introduces spurious DBL_EPSILON.
Marco
|
Thu 10 Mar 2011 05:58:39 PM UTC, comment #12:
Thanks Marco. Have the problem isolated makes the job much easier.
I've attached another changeset that works for me. I'd appreciate is if you could verify this one works for you.
I'm still unfamiliar with this part of the code, so I've cc'd jwe and Shai.
(file #22881)
|
Thu 10 Mar 2011 08:38:45 AM UTC, comment #11:
Dear Ben,
with your patch and few additional lines I was able to fix the problem for me. Your patch did not work because tmp_lims(0) was equal to lo (and to min_val) and both greater than xmin.
I'm not sure it is a real fix or just a workaround, because just printing the value of min_val was enough for me to fix. I would like to understand how just printing a value can change it!
My patch is versus 3.4.0.
Marco
(file #22876)
|
Wed 09 Mar 2011 05:20:54 PM UTC, comment #10:
Ok. If you have any idea where the code needs to be changed, please make a suggestion.
I'm not very good at following the c++ code, but I'll take another look.
|
Wed 09 Mar 2011 03:56:06 PM UTC, comment #9:
Dear Ben,
your patch does not work for me. I think the problem is more hidden: in fact, if I put
before AND after
in axes::properties::get_axis_limits, I get your y_limits.
Marco
|
Wed 09 Mar 2011 03:42:20 PM UTC, comment #8:
I've attached a changeset. The axis limits were calculated correctly for me with and without this patch.
So, this will need to be tested by someone who sees this problem.
(file #22867)
|
Wed 09 Mar 2011 01:54:33 PM UTC, comment #7:
Thanks Marco.
I've isolated the problem, and will post a patch when I get it fixed.
Ben
|
Wed 09 Mar 2011 11:17:28 AM UTC, comment #6:
Hi.
I have the same behaviour of Moritz (linux x86 octave 3.4.0). I observed the following:
that is y_limits(1) > y(1) (due to floating point) with axis auto.
Marco
|
Tue 08 Mar 2011 05:32:45 PM UTC, comment #5:
with
or
the plot is correct
only axis auto swallows the first row.
|
Tue 08 Mar 2011 04:24:41 PM UTC, comment #4:
Looks like the axis limits are not be set property. What do you get with ...
I see ...
... and after "axis tight" ...
|
Tue 08 Mar 2011 04:16:48 PM UTC, comment #3:
with the command
axis tight
the plot is correct.
with axis auto the first row will be missed.
I think axis tight will solve my problem.
But axis auto works correct with other y-values and there are differences in the behavior in cygwin-octave and debian-ocatve.
|
Tue 08 Mar 2011 02:43:03 PM UTC, comment #2:
Moritz,
If you get the same values for x/y/zdata that I obtained below, please run the command below and attach the debug.gp file.
We can examine the debug.gp plot stream and determine if the problem is with Octave or gnuplot.
|
Tue 08 Mar 2011 02:34:53 PM UTC, comment #1:
I tried the first exampled with the developer's sources and got the correct result.
I'm running MacOS and using the gnuplot (v4.4) backend.
I've attached a pdf of the result (I added a "axis tight" before generating the pdf).
What do you get when you check the x/y/xdata properties?
|
Mon 07 Mar 2011 04:38:08 PM UTC, original submission:
Maschine: Intel Core 2 Duo E6600 2.00GB RAM
XP Professional Sp3
Cygwin 1.7.8-1
Octave 3.4
Gnuplot 4.4
The first row will not be drawed!
(possibly a problem of floating point condition?)
x = [10:2:30];
y = [7.1:0.1:7.5];
z = [1:11;2:12;3:13;4:14;5:15];
surf (x,y,z)
-> Plot missing: y = 7.1
x = [11:1:14];
y = [7.1:0.1:7.3];
z = [1:4;2:5;3:6];
surf (x,y,z)
-> Plot missing y = 7.1
x = [11:1:14];
y = [7.2:0.1:7.4];
z = [1:4;2:5;3:6];
surf (x,y,z)
-> Plot y = 7.2 exist
The first row is drawed!
----------------------------------
the same with:
Linux Debian 5.0 Kernel 2.6.26
(Lenny live)
gnuplot_4.2.2-1.2
octave 3.0.1:3.0.1-6lenny3
x = [10:2:30];
y = [7.1:0.1:7.5]
z = [1:11;2:12:3:13;4:14;5:15];
surf (x,y,z)
-> Plot missing: y = 7.1
x = [11:1:14];
y = [7.1:0.1:7.3];
z = [1:4;2:5;3:6];
surf (x,y,z)
-> Plot missing y = 7.1
x = [11:1:14];
y = [7.2:0.1:7.4];
z = [1:4;2:5;3:6];
surf (x,y,z)
-> Plot y = 7.2 exist
|