Thu 29 Aug 2013 11:49:12 PM UTC, comment #20:
Re-visiting this bug report, I found that we got nearly everything right except for a typo in the input processing of 'agrs' instead of 'args'. With that fix (http://hg.savannah.gnu.org/hgweb/octave/rev/1391dc953ae2) I'm closing this report.
|
Fri 04 May 2012 05:19:15 PM UTC, comment #19:
Arnaud, for help please use email.
help-octave Octave <help-octave@octave.org>
|
Fri 04 May 2012 05:15:17 PM UTC, comment #18:
hello,
I get the same problem trying to convert some files using the patch function from matlab to octave :
"warning: "interp" not supported, using 1st entry of cdata"
Could you explain how to fix it ?
thanks
|
Fri 14 Oct 2011 10:44:22 PM UTC, comment #17:
I found the problem (local to me). Now I get the same result as jwe.
I have a new example that works differently from ML.
Matlab and Octave return the same facevertexcdata ...
But gnuplot complains
The FLTK backend produces the correct result.
|
Fri 14 Oct 2011 10:31:51 PM UTC, comment #16:
John,
Before, I start digging deeper, those results were produced from the code below, correct?
|
Fri 14 Oct 2011 02:04:57 PM UTC, comment #15:
With the current version of Octave on my system, and with fltk+opengl graphics, I see
With gnuplot, I see
|
Thu 13 Oct 2011 11:56:06 PM UTC, comment #14:
For the two patches in comment #12, the facevertexcdata is empty, for ML.
Same for Octave.
I ran the test below.
Matlab returned,
Octave gives an error for me.
|
Thu 13 Oct 2011 11:15:10 PM UTC, comment #13:
What is the orientation of facevertexcdata in Matlab?
Does my change get the order of the elements right? Maybe the transpose is not needed, just the (:)?
I was trying to fix a problem where x, y, and c are all matrices. There was some size mismatch if I did not force facevertexcdata to be a column vector. I thought that was how Matlab stores this property, but maybe I got the order of the elements wrong.
|
Thu 13 Oct 2011 11:08:24 PM UTC, comment #12:
Rik,
John just pushed a patch that looks to conflict with your original changeeset.
Yours ...
http://hg.savannah.gnu.org/hgweb/octave/rev/41c2f4633a62
John's ..
http://hg.savannah.gnu.org/hgweb/octave/rev/276bb0dd9d24
There have been other changes as well.
Presently, the code below does not produce the intended result.
|
Mon 10 Oct 2011 03:16:01 AM UTC, comment #11:
Second patch works for me.
|
Mon 10 Oct 2011 12:28:29 AM UTC, comment #10:
I've attached my 2nd attempt.
Qualifier: Interpolating lines between vertices is not supported by the gnuplot bacekd (I didn't check the fltk backend).
(file #24123)
|
Sun 09 Oct 2011 03:00:23 PM UTC, comment #9:
I got to this faster than I'd expected. Before pushing another reversion, does this look ok?
I'll do some more testting before I push.
(file #24122)
|
Sun 09 Oct 2011 02:35:17 PM UTC, comment #8:
Thanks for catching this. I'll take a look later today.
|
Sun 09 Oct 2011 03:01:59 AM UTC, comment #7:
Ben,
With your new patch in place (e9f6a6edec42) I went to try the list of test cases at http://www.mathworks.com/help/techdoc/ref/patch.html.
The first 'cdata' case no longer works. It appears that zdata is being interpreted as cdata.
|
Mon 03 Oct 2011 03:04:41 AM UTC, comment #6:
Yes. The stable branch is essentially frozen. Release Candidate 0 was put on the FTP site and I only know of one bug which may be incorporated into RC1. Even though bug fixes would normally go on to stable I am putting them on to default as 3.6 will be the next release.
|
Sun 02 Oct 2011 04:41:00 PM UTC, comment #5:
Rik,
I've prepared a changeset for the remaining problems I found. While I was finishing it, I noticed you pushed this change to default (rather than to stable).
Was that done on purpose?
|
Fri 30 Sep 2011 04:00:53 PM UTC, comment #4:
Ben,
No. I needed to resolve the orientation of cdata issue so that I could close another bug. Matlab documentation has extensive references for what should happen in every situation ((http://www.mathworks.com/help/techdoc/ref/patch.html). I went through the examples last night and there are some failures with Octave when trying to do the most complex colorings such as having the edges one color and the facecolor something else or having gradients across the faces. Results were better when using the 'faces','vertices' style of patch creation rather than x,y data but Octave is still imperfect in this regard.
If you like, you can hijack this bug and re-title it to something more specific. Otherwise, you could close it and open up another bug report for your issue.
|
Fri 30 Sep 2011 11:24:55 AM UTC, comment #3:
Rik,
Do you plan to continue working on the patch() command?
Ben
|
Fri 30 Sep 2011 05:08:03 AM UTC, comment #2:
I've gone ahead and applied the patch in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/41c2f4633a62).
|
Fri 30 Sep 2011 01:03:52 AM UTC, comment #1:
I ran the plot demos, and did not see any regressions. However, I tried using scalar colors in the way I've done with ML, and discovered they fail with and without your patch.
Perhaps some new tests should be included when this is fixed?
|
Wed 28 Sep 2011 04:24:16 PM UTC, original submission:
There are two ways of setting the color for patches. The first method is to create the patch with 'faces' and 'vertices' and use 'facevertexcdata'. This approach works. The second method is to create the patch with x and y vertices and use 'cdata' to set the color. This approach seems to fail. Extensive reference on how to set the color of patch faces is given here (http://www.mathworks.com/help/techdoc/ref/patch.html).
Sample code for method 1 (Working)
Sample code for method 2 (Not Working)
My hunch is that cdata and facevertexcdata are supposed to be transposes of each other. If one is a row vector the other needs to be a column vector.
The following change to _patch_.m at line 292 eliminates the error for me.
I have attached a changeset which does just that. If someone could verify that this doesn't mess up anything else I think it should be adopted.
|