matplotlib-users Mailing List for matplotlib

Looks like I've been able to help myself on this one. I'll post this 
here b/c others had asked about this in prior emails and I never saw 
an answer given.
You can make your own custom legend by keeping the return values from 
each plot command:
e.g.
l1 = plot(<y1's stuff>)
twinx()
l2 = plot(<y2's stuff>)
legend([l1,l2],['y1s tag','y2s tag'])
works like a charm.
HTH
--b

Note: there is a type-o in the above email.
 "W/MacPorts, I've been able to get the TkAgg backend to work"
should be
 "W/MacPython, I've been able to get the TkAgg backend to work"

Below is the last (or nearly so) message of a thread from last summer. 
I have now implemented option 3 in svn, so:
If y is 2-D, plot(y) plots the columns of y against the row-index.
If x is 1-D and y is 2-D, plot(x,y) plots the columns of y against x. 
(In this case, x can also be 2-D if it is a single column.)
If x is 2-D and y is 1-D, plot(x,y) plots y against each successive 
column of x. (Again, y can also be a single column.)
If x and y are both 2-D, plot(x,y) plots columns of y against the 
corresponding columns of x. They must have the same number of columns.
All of this is consistent with Matlab, as far as I know. Apart from 
this compatibility aspect, the design tradeoff is between the appeal of 
plotting rows, on the grounds that they correspond to C storage order, 
versus the appeal of plotting columns, on the grounds that one tends to 
think of columns in a table as the natural vectors to be plotted. I 
don't think it makes much difference in efficiency; transposing is cheap 
in numpy. It is possible that plotting non-contiguous values triggers 
an additional array copy somewhere in the chain of operations. I have 
not tried to figure out whether it does, or what the time penalty would 
be if it does, but I strongly doubt it would be a noticeable fraction of 
the total plot generation time.
The changes are only very lightly tested so far, so please look for bugs.
Eric
Mark Bakker wrote:
> You are right, concerning your comment below.
> That will work just fine,
> Mark
> 
> On 7/13/06, *Eric Firing* <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
> 
> 
> But why is this better than the following?
> 
> plot(Z[0,:], Z[1:,:])
> 
> The latter would accomplish the same, be completely consistent with
> option 4, be completely explicit and unambiguous, require no more typing
> than using a kwarg, require no extra logic in the plot code, and
> require
> no extra documentation for the plot command.
> 
> Eric
> >
> > As you said, there will be many more opinions,
> >
> > Mark
> >
> >
> >
> > To summarize, the options seem to be:
> >
> > 1) Leave plot argument parsing alone.
> > 2) Accept an Nx2 array in place of a pair of arguments
> containing x
> > and y.
> >
> > 3) Implement the Matlab model.
> > 4) Implement the Matlab model, but taking rows instead of
> columns in an
> > X or Y array that is 2-D.
> >
> > I am open to arguments, but my preference is the Matlab
> model. I don't
> > think that the difference in native array storage order
> matters much.
> > It is more important to have the API at the plot method and
> function
> > level match the way people think.
> >
> > Eric

Hi,
This mailing list is great---I've gotten a couple very useful replies 
from others in a very short time period. Thanks!
And now, onto my next question. I need to construct a two-y-axis 
plot. I've found some hints on how to do this on the mailing archive 
(Subject: secondary y-axis, Date: 9/28/05).
I've got the basics working, but have run into the same problem this 
prior post did: I want a legend that lists content from both the 
"left-hand-sided" plots and the "right-hand-sided" ones.
It appears only one axis or the others data can appear in a legend.
Is there anyway to merge the two axes into a single legend?
Also, the mail archives I'm viewing look terrible: line breaks aren't 
in the usual place, things are presented with >'s in them (which 
would make sense if the line breaks were preserved, b/c they 
correspond to pieces of prior email content). I'm using Safari 2.0.4 
w/Mac OS X 10.4.8. Do others see the same thing, and if the answer is 
yes, are folks satisfied with this state of affairs?
Thanks,
--b