Sun 25 Mar 2012 09:00:30 PM UTC, comment #15:
Marco,
I went ahead and committed your patch here (http://hg.savannah.gnu.org/hgweb/octave/rev/319660795df1).
The original reporter can access the fix by building from Mercurial sources or waiting for the next major release of Octave (3.8.0).
|
Mon 19 Mar 2012 04:29:46 PM UTC, comment #14:
I cannot really test the patch: clim is correctly computed by octave, it is the string sent to gnuplot to be wrong in the case %g. I see that surf and mesh do not contain tests, so I stay with surf.diff.
Marco
|
Mon 19 Mar 2012 03:28:13 PM UTC, comment #13:
The easiest way might to be two separate patches. One to fix the problem and one to add tests.
If you have only committed to your local repository and haven't pushed to Savannah (which seems to be the case) then you could use 'hg strip REVXXX' where REVXXX is the number of the revision in your local repository. Once the revision is gone use 'hg import --no-commit surf.diff'. This will import the changes from the patch you posted to this bug report (surf.diff). At that point you are ready to make the rest of the changes and can finish with 'hg ci'
|
Mon 19 Mar 2012 08:38:47 AM UTC, comment #12:
After making the attached changeset, I realized that I forgot to add to surf.m the tests we discussed. Can you please explain me how to go back and produce a complete changeset? I tried with hg revert without success...
(file #25402)
|
Fri 16 Mar 2012 10:02:41 PM UTC, comment #11:
Marco,
Ben gave the OK and I checked all of the previous examples and they now work. You do need to change the line at 1437 and the line at 1440. Can you go ahead and push your changeset?
|
Fri 16 Mar 2012 09:44:54 PM UTC, comment #10:
The choice of format can vary depending upon context. I think it is a mistake to use %15e or %15g for ticklabels (ugly plots).
For specifying the colorbar, clim, xlim, ylim, or zlim range 15 or maybe 16 digits of precision makes sense.
Looks like %g is the wrong choice in this instance. Either %.15e or %.16g should fix the problem.
|
Fri 16 Mar 2012 09:20:55 PM UTC, comment #9:
I'm adding Ben to the bug list. I swear that we addressed some similar issue with %g not producing the correct output and we made a similar change. If that could be confirmed then I think this is the way to go.
Also, in the ancient changelogs there was some confusion about wether %g or %e should be used.
+2007-09-21 John W. Eaton <jwe@octave.org>
+
+ * optimization/sqp.m: Fix typo.
+
+ * plot/__go_draw_axes__.m (do_tics_1): Use %g, not %.15g here.
+2007-09-18 David Bateman <dbateman@free.fr>
+
+ * plot/__go_draw_axes__.m (_gnuplot_write_data_): Use %e instead
+ of %g when writing data.
+2005-11-22 John W. Eaton <jwe@octave.org>
+
+ * plot/axis.m: Use %.16g instead of just %g to format ranges for
+ gnuplot set command.
|
Fri 16 Mar 2012 07:58:34 AM UTC, comment #8:
Rik,
probably you are right, it is just a problem of gnuplot. Restoring graphics.cc at the original state and changing
with
around line 1440 of _go_draw_axes_.m, I get all the examples mentioned in this thread working. In that file, three lines above there is a similar one that probably should be changed, too. Can you confirm that both lines should be changed?
Thanks,
Marco
|
Thu 15 Mar 2012 05:21:54 PM UTC, comment #7:
I tried Marco's latest patch, with Jordi's modification. The code for line 6505 in graphics.cc was
For the Octave test code I used
The figure produced by the old version of Octave is correct. There are only two cdata values [0.8-eps/2, 0.8]. Octave scales the cdata to fit the colormap and with only two values the two colors should be the first color of the colormap and the last value of the colormap. These colors are blue and red for the default jet colormap.
With the patch applied, the resulting plot is all green. I have attached the two images.
I still think this may be a specific problem with how we are calling gnuplot, rather than a general problem that affects both FLTK and gnuplot.
(file #25368, file #25369)
|
Thu 15 Mar 2012 01:44:15 PM UTC, comment #6:
Please use C++'s std::numeric_limits<double>::epsilon() instead of a CPP macro. There are good reasons to do so.
|
Thu 15 Mar 2012 08:28:57 AM UTC, comment #5:
You are right, in fact the test should be relative
as already mentioned in some FIXME comments. Also notices that I put <= instead of <, otherwise this test
fails.
Marco
|
Wed 14 Mar 2012 06:50:11 PM UTC, comment #4:
I think the fix lies somewhere else.
This sample code works in the current version of Octave, but produces a monotone green image with your patch applied.
The issue is that sometimes the difference between min_val and max_val can be less than sqrt (DBL_EPSILON) but this doesn't mean there is any problem. The color values are scaled so [-1, 0, 1] are just as good as [-1e-30, 0, 1e30].
|
Wed 14 Mar 2012 03:14:45 PM UTC, comment #3:
What about replacing all
with
in graphics.cc?
The problematic line, in this case, is 6505. But I don't see any reason to leave the strict comparisons.
Marco
|
Fri 09 Mar 2012 05:34:05 PM UTC, comment #2:
The problem seems to be caused by values which are within eps ("single") or so of each other. A simpler example to reproduce the problem is
|
Fri 09 Mar 2012 05:20:45 PM UTC, comment #1:
To be clear, here are the steps necessary to reproduce the bug.
1) Download the two m-files KON.m and ROTATION.m
2) Start octave
3) Execute the following
|
Thu 08 Mar 2012 05:13:25 PM UTC, original submission:
octave:62> figure(1); clf; surf(Z-.8);
octave:63> figure(1); clf; surf(Z);
gnuplot> splot "-" binary format='%float64' record=19x19 using ($1):($2):($3):($4) title "" with pm3d linestyle 1 ;
^
line 0: Can't plot with an empty cb range!
octave:73> sum(sum(Z)) - .8(size(Z)(1,1)size(Z)(1,2))
ans = 5.68434188608080E-14
octave:74> sum(sum(Z-.8))
ans = 2.95319324550292E-14
octave:75> size(Z)
ans =
1.90000000000000E+01 1.90000000000000E+01
|