Re: [matplotlib-devel] Plots with two scales for the y axis

[Baptiste C. <bap...@al...>]

John Hunter a =E9crit :
> Here is what I think would be ideal, and I wanted to sketch some of
> these ideas in hopes that you might have some ideas on how to apply
> them.  Basically, the idea is that we want one axes to be able to
> share the x or y limits with another axes in a more general way.  Your
> approach works fine as long as the two axes are overlayed.  It would
> be nice if we could do something like
>=20
>     # separate axes
>     ax1 =3D subplot(211)
>     plot([1,2,3])
>=20
>     ax2 =3D subplot(212, twinx=3Dax1)
>     plot([4,5,6])
>=20
That sounds like a good syntax.
Its not a problem the share the x/ylims. As long as you can get the lazy=20
values at Axes creation, you can set the transforms correctly. The=20
question is whether or not to share the Axis instance. If you do, you=20
will have trouble drawing, if you don't, you have trouble when you want=20
to change the attributes (see below). I got away with this only because=20
I have to draw only one "physical" axis.

> To do overlayed axes, you could do
>=20
>     # overalyed axes
>     ax1 =3D subplot(111)
>     plot([1,2,3])
>=20
>     ax2 =3D subplot(111, twinx=3Dax1, yticks=3D'right')
>     plot([4,5,6])
>=20
OK, you also have to set the frame to off, we'll see the details later.=20
Maybe we can keep just the twin function in pylab.py as a shortcut.

> I think this would be a nice consistent interface and in both cases
> ax2 would share the xlim with ax1.  As far as I can see, the only
> thing getting in the way of extending your approach to handle this
> case are the tick labels, since they would be in the wrong place for
> ax2 in the separate axes case.  For the separate axes case, you would
> typically want tick labeling on the lower axes, but it would be ideal
> to be able to control that as well.
>=20
> I've been meaning to decouple the axis line and tick locations from
> the main axes frame so that you could have offset labels and ticks.
> Perhaps this would be a good time to make both changes together.
>=20
That one is more tricky. All of matplotlib drawing model is based on the=20
premise that one objet draws at one given place. This has many=20
advantages. It allows the object to draw itself, which is good design.=20
It is also necessary for the cases where the final size matters (fonts,=20
linewidth). I don't think we want to change that.

< I stopped here, thought about it for some time, went back later >

I'm starting to wonder which properties of Axis we really want to share=20
between axes: limits, scale (linear/log), fmtdata, label, tick positions=20
(thus a common "tick factory"), tick label texts, viewLim, dataLim (we=20
need to think about update_datalim).

and which we do *not* want to share: all graphic objects, visibility of=20
labels (ticks ?), style of ticks and tick labels (you may want smaller=20
fonts in an inset), type of axis (XAxis, YAxis, ThetaAxis, Color, ...,=20
for ex. we may want to plot z(x,y) as pcolor and z(x) as line with=20
shared z lims)

Maybe we want to split an axis into 2 objects ? I need to think more=20
about this.

> The other problem in the current implementation (and in your patch)
> stems from the fact that for event handling, only one axes gets the
> event.  So in your two_scales.py example, if you pan/zoom the xlimits
> behave correctly but only one axes gets the pan/zoom event for y.  It
> would be nice to pass these events on to all the axes the user is over
> to handle the case of overlapping axes.
>=20
This is uncorrelated, and probably easier than the one above. We would=20
need to modify event.inaxes to be a list (in backend_bases), and act=20
upon all those axes in pan/zoom. When only one axes can be used (for ex.=20
the coordinates of the mouse in the status bar), we would use=20
event.inaxes[0], or maybe the most recently used axes (more difficult,=20
but maybe more consistent...we'll see at implementation time).

> Just some thoughts on what I think the proper behavior should be.  If
> you have any ideas on how to handle these, let me know. =20
>=20
well, we need to discuss that a little bit more, so we'll get a clearer=20
view of where we go :-)

Cheers,
Baptiste