bugGNU Octave - Bugs: bug #35761, surf() fails when Z values are...

 
 

bug #35761: surf() fails when Z values are within eps of each other

Submitter:  None
Submitted:  Thu 08 Mar 2012 05:13:25 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Anders Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.4.3
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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).

Rik <rik5>
Group administrator
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

Marco Caliari <caliari>
Group Member
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'

Rik <rik5>
Group administrator
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)

Marco Caliari <caliari>
Group Member
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?

Rik <rik5>
Group administrator
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.



Ben Abbott <bpabbott>
Group Member
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.


Rik <rik5>
Group administrator
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


fprintf (plot_stream, "set cbrange [%g:%g];\n", clim);


with


fprintf (plot_stream, "set cbrange [%.15e:%.15e];\n", clim);


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

Marco Caliari <caliari>
Group Member
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


else if (std::abs (min_val - max_val) <=
         sqrt (std::numeric_limits<double>::epsilon ()) *
         std::max (std::abs (min_val), std::abs (max_val)))


For the Octave test code I used


[x, y] = meshgrid (-1:1);
z = 0.8 * ones (3);
z(:,1) -= eps/2;
surf (x,y,z)


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.



Rik <rik5>
Group administrator
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.

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Thu 15 Mar 2012 08:28:57 AM UTC, comment #5: 

You are right, in fact the test should be relative


if (std::abs (min_val - max_val) <= sqrt (DBL_EPSILON) *
    std::max (std::abs (min_val), std::abs (max_val)))


as already mentioned in some FIXME comments. Also notices that I put <= instead of <, otherwise this test


x = y = ones (3);
z = zeros (3);
surf (x,y,z)


fails.

Marco

Marco Caliari <caliari>
Group Member
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.


graphics_toolkit fltk;
[X,Y,Z] = peaks ();
Z * = 1e-30;
surf (X,Y,Z);


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].

Rik <rik5>
Group administrator
Wed 14 Mar 2012 03:14:45 PM UTC, comment #3: 

What about replacing all


if (min_val == max_val)


with


if (std::abs (min_val - max_val) < sqrt (DBL_EPSILON))


in graphics.cc?
The problematic line, in this case, is 6505. But I don't see any reason to leave the strict comparisons.

Marco

Marco Caliari <caliari>
Group Member
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


graphics_toolkit gnuplot;
x = y = ones (3);
z = 0.8 * ones (3);
z(:,1) -= eps/2;
surf (x, y, z)



Rik <rik5>
Group administrator
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


graphics_toolkit gnuplot
KON


Rik <rik5>
Group administrator
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


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #25402:  surf.diff added by caliari (1KiB - text/x-patch)
file #25368:  original.png added by rik5 (61KiB - image/png)
file #25369:  patched.png added by rik5 (61KiB - image/png)
file #25298:  KON.m added by None (3KiB - text/x-matlab)
file #25299:  ROTATION.m added by None (503B - text/x-matlab)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by caliari (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-03-25 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2012-03-19 caliari Attached File- Added surf.diff, #25402
    2012-03-16 rik5 Carbon-Copy- Added bpabbott
    2012-03-15 rik5 Attached File- Added original.png, #25368
        Attached File- Added patched.png, #25369
    2012-03-09 rik5 SummaryProbably float64-representation bug. surf() fails when Z values are within eps of each other
    2012-03-09 rik5 StatusNone Confirmed
    2012-03-08 None Attached File- Added KON.m, #25298
        Attached File- Added ROTATION.m, #25299

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code