Fri 26 Aug 2016 08:44:17 AM UTC, comment #10:
@Lachlan,
Are you still planning to work on this?
I've regularly applied the cset but I've recently discovered that it gives rise to FAILs in copyobj.m and hgsave.m.
Maybe it is just the way the tests are set up, but I have no time for looking into it for a while.

Tue 03 May 2016 08:20:19 AM UTC, comment #9:
I just noticed that there is overlap between this bug report and bug #39036. I'm adding a link, and will look into merging the patches.

Tue 05 Apr 2016 09:06:01 PM UTC, comment #8:
I finally got round to testing this patch the last days. AFAICS it works OK.
Can this be pushed?

Fri 19 Feb 2016 11:28:42 PM UTC, comment #7:
The attached patch supports all of the forms that Philip proposed, and leaves the properties of the lines as close to Matlab compatible as I could manage.
(file #36402)

Fri 19 Feb 2016 12:22:59 AM UTC, comment #6:
Good point, jwe. I was totally forgetting that it is possible to access the data again.
The reason I wasn't getting any line was that I was drawing vertical lines,
and so each line was reduced to a single point.
Fortunately, Matlab gives
so it seems we can just transpose the data  much better than having to modify some subset of graphics toolkits to reinterpret the data.
Similar to your last example, Octave gives a diagonal line for the oneshot command
Thanks for all your guidance.

Thu 18 Feb 2016 05:34:32 AM UTC, comment #5:
I see this behavior:
Then if I change the axis limits, the horizontal lines appear in the plot window.
So it looks like the problem is that line is doing something similar to broadcasting and creating two line objects instead of recognizing that there are two vectors of the same length.
When fixing this, it's important to make sure that the x and y data stored in the line object are oriented in a Matlabcompatible way. Do they retain their original orientation, or is one transposed so they are both row (or column) vectors?
I see that the following appears to work, so I think the bug is just in making line recognize the case of vectors with different orientations.

Thu 18 Feb 2016 02:20:40 AM UTC, comment #4:
Thanks, Philip. I'll have a go at coding that somewhat efficiently.
Note that the bug report was about the lowlevel "line" command rather than highlevel "plot" command. I think that Octave's "plot" already handles these rotations, but "line" doesn't. (I checked your examples in Matlab, and it handles line flexibly too.) I just don't want to put too much additional checking into "line" because a "stem" command can call it hundreds of times, last I checked.

Wed 17 Feb 2016 04:39:18 PM UTC, comment #3:
Lachlan, in your title example the length of the vector matches. That is all that Matlab needs.
What works (in ML 2014a) is e.g. (by the absence of error messages),
(note that in the last example the plot is rotated 90 degrees relative to the previous examples).
But ML has limitations:
...so one of the arguments to plot must be a vector, the other can be a matrix of which at least one dimension must have the same length as the vector argument.
AFAICS Matlab first tries to match dimensions/orientations as specified on the command line/instruction, and if it finds no match, tries rotating arguments until it finds common lengths, otherwise fails with an error message.

Tue 16 Feb 2016 10:41:41 PM UTC, comment #2:
Thanks for checking, Philip. In the example I gave, neither dimension matches, but Matlab still draws the line. When I get to work, I'll check further.
Do we want to copy Matlab's forgiving behaviour exactly, partially or not at all? I'm in favour of copying whatever is quick to check for.

Mon 15 Feb 2016 09:40:38 AM UTC, comment #1:
Matlab is very forgiving even if one is a matrix. AFAICS Matlab only checks which dimensions of the input vectors/matrices match and then use that for plotting.

Mon 15 Feb 2016 02:12:16 AM UTC, original submission:
If all X, Y and Z are vectors of the same length, Matlab doesn't seem to care whether they are row or column vectors.
Octave plots nothing if X is a column and Y is a row.
