matplotlib-devel Mailing List for matplotlib

>>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes:
 Malte> You are looking for matplotlib.axes.Subplot.set_position
That will work, but what you are really looking for is to not use
subplot at all, but rather axes; a Subplot is just an Axes that happens
to lie on a regular grid
 axes_top = fig.add_axes([0.1, 0.3, 0.8, 0.6])
 axes_bottom = fig.add_axes([0.1, 0.1, 0.8, 0.15])
If you want the two axes to touch and share and xaxis, see
examples/ganged_plots.py. There are nice tricks you can do to share
an xaxis so for example when you pan/zoom in one the xaxis in both
plots move together; see examples/shared_axis_demo.py
JDH

You are looking for
matplotlib.axes.Subplot.set_position
set_position(self, pos) method of matplotlib.axes.Subplot instance
 Set the axes position with pos = [left, bottom, width, height]
 in relative 0,1 coords
 ACCEPTS: len(4) sequence of floats
axes_top.set_position([left, bottom, width, height])
etc.
On Friday 31 March 2006 08:38, Andrew B. Young wrote:
> Hello:
>
> How does one go about controlling the size of a subplot?
> I've got--
>
> figure = matplotlib.pylab.Figure()
> canvas = FigureCanvas( figure )
> axes_top = figure.add_subplot(211)
> axes_bottom = figure.add_subplot(212)
>
> and I want the _top to occupy 4/5 of the png
> and the _bottom to occupy the remaining 1/5.
>
> Thanks!
> Andrew

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I dont think that can work, since
 Darren> set_xticklabels(['foo',...]) makes its own call to
 Darren> set_text('foo').
ax.set_xticklabels calls ax.xaxis.set_ticklabels which creates a new
Formatter with 
 self.set_major_formatter( FixedFormatter(ticklabels) )
ticklabels are kind of funny, and this is related to the question on
the user's list about setting the location of ticklabels. The
location and string are determined at draw time by the Locator and
Formatter class, which is why well-intentioned but naive attempts to
control their location and text directly often fail. One has to set
the locator and formatter, and this is highly configurable and
customizable. For the most part, I think it works fine.
The one use case brought up on the users list that the framework
doesn't address is the "centering" issue of ticklabels, trying to get
the labels centered between ticks. I'm mostly -1 on this, and I think
the major/minor hack I suggested can solve this use case fairly
cleanly, but I'm open to counter arguments. What might be nice,
however, is to add a padx, pady properties to text instances in
general or maybe just ticklabels in specific, that will shift their
horizontal and vertical position by a fixed amount in points.
JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> John, At >4600 lines, axes.py is getting unwieldy, as is the
 Eric> Axes class that makes up the bulk of it. I propose to
 Eric> reorganize it and split it into at least two files.
 Eric> The main organizational change would separate the
 Eric> functionality that is directly involved in manipulating the
 Eric> axes from the more specific plotting methods. This could be
 Eric> done, for example, by putting the former in an AxesBase
 Eric> class, and then letting Axes inherit that. At the very
 Eric> least it would be nice to rearrange the methods so that all
 Eric> the pure Axes manipulation methods are together at the
 Eric> beginning.
 Eric> What do you think?
I don't want overarching ambitions to get in the way of a simple
refactor, but....
I've discussed this with Fernando and Perry on a couple of occasions,
and I think it would be useful to create high level Artists like
LinePlot, ScatterPlot, BarChart, etc, that carried the lines, etc, etc
around with them with useful configuration methods. The pylab.plot
would be a thin wrapper to Axes.plot which would instantiate a
LinePlot. A bit like what you recently did for the contour function.
High level plot objects like this would allow us to easily support
things like a FunctionPlot, which always returns the sin(x) at any
given scale, with some configurable, intelligent way to determine the
granularity of sampling at a given scale.
So that is background on the general topic of refactoring axes.py. As
for your specific suggestion, I have no problem with it. I have never
had a problem with one large file since emacs and judicious use of
search-forward and search-backward work fine for me. But I know that
code better than most, and I think your proposed changes would make it
much easier for people approaching the code for the first time to
understand what is going on. It might also make it clearer how to
pursue the grand refactor down the road. But I mention it now so you
can think about it while you are working :-)
JDH

On Thursday 30 March 2006 3:44 am, Jouni K Seppanen wrote:
> John Hunter <jdh...@ac...> writes:
> > Jouni> label: any string
> > Jouni> text: string
> >
> > a 'label' is a property of any matplotlib.artist.Artist (the base
> > class for Line2D, Patch, Text, etc), and is used to attach a string to
> > any object that renders into a figure (including the Figure itself).
> > This is most used for auto-legending
>
> Oh, of course. I was confused by the name "tick labels" for the text
> that accompanies tick marks.
>
> > matplotlib.text.Text.set_text, however, does set the to-be-rendered
> > string for the Text instance.
>
> It doesn't seem to work for tick labels. E.g.
>
> gca().get_xticklabels()[0].set_text('foo')
>
> has no effect. This is quite understandable, since the text comes from
> a Formatter object. It might be a neat hack to have set_text('foo')
> automatically call set_xticklabels(['foo',...]).
I dont think that can work, since set_xticklabels(['foo',...]) makes its own 
call to set_text('foo').

Eric Firing <ef...@ha...> writes:
> The main organizational change would separate the functionality that
> is directly involved in manipulating the axes from the more specific
> plotting methods. This could be done, for example, by putting the
> former in an AxesBase class, and then letting Axes inherit that.
IMHO, it would make sense in the long term to make Axes a low-level
class with a well-defined interface, and implement high-level plotting
methods such as bar, boxplot, cohere, hist, specgram and what have you
using that interface outside of Axes. Currently at least some of these
methods "peek under the hood" by doing things like
 if not self._hold: self.cla()
This looks like it will be a pain to maintain if the implementation
details ever change. self._hold could probably be easily replaced by
self.ishold(), but moving the methods to another class would help
ensure that they stay kosher.
-- 
Jouni

John Hunter <jdh...@ac...> writes:
> Jouni> label: any string 
> Jouni> text: string
>
> a 'label' is a property of any matplotlib.artist.Artist (the base
> class for Line2D, Patch, Text, etc), and is used to attach a string to
> any object that renders into a figure (including the Figure itself).
> This is most used for auto-legending
Oh, of course. I was confused by the name "tick labels" for the text
that accompanies tick marks.
> matplotlib.text.Text.set_text, however, does set the to-be-rendered
> string for the Text instance.
It doesn't seem to work for tick labels. E.g.
 gca().get_xticklabels()[0].set_text('foo')
has no effect. This is quite understandable, since the text comes from
a Formatter object. It might be a neat hack to have set_text('foo')
automatically call set_xticklabels(['foo',...]).
-- 
Jouni

John,
At >4600 lines, axes.py is getting unwieldy, as is the Axes class that 
makes up the bulk of it. I propose to reorganize it and split it into 
at least two files.
The main organizational change would separate the functionality that is 
directly involved in manipulating the axes from the more specific 
plotting methods. This could be done, for example, by putting the 
former in an AxesBase class, and then letting Axes inherit that. At the 
very least it would be nice to rearrange the methods so that all the 
pure Axes manipulation methods are together at the beginning.
What do you think?
Eric

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:
 Jouni> Darren Dale <dd...@co...> writes:
 >>> > OK, I refactored TextWithDash, and my changes passed
 >>> backend_driver.py. > setp(axes().get_yticklabels()) gives a
 >>> comprehensive list as of svn 2206.
 >> I fixed the bug John pointed out, and unmasked the refactored
 >> version of TextWithDash in svn 2226.
 Jouni> Yes, 'size' is listed in the output now. However, now it
 Jouni> seems that there are too many things listed:
 Jouni> label: any string 
 Jouni> text: string
If I'm reading this right, this has nothing to do with Darren's recent
refactoring.
a 'label' is a property of any matplotlib.artist.Artist (the base
class for Line2D, Patch, Text, etc), and is used to attach a string to
any object that renders into a figure (including the Figure itself).
This is most used for auto-legending
 plot(x1, y1, 'go', label='label x')
 plot(x1, y1, 'rs', label='label y')
 legend()
and legend will "to the right thing"(TM)
In other cases, we might use the label in outputting group information
in SVG output for instance, where we have open and close tags
associated with polygons, etc..
So the label is not necessarily rendered into the figure, although it
might be as the legend example illustrates, but is useful to tag
objects with strings.
matplotlib.text.Text.set_text, however, does set the to-be-rendered
string for the Text instance. It is right and good that the text
instance has a separate label and text property, though I agree this
might be confusing on a cursory 'setp' or 'getp' introspection.
JDH