matplotlib-users Mailing List for matplotlib

On 3/7/11 2:25 PM, Juan A. Saenz wrote:
> Jeff, thanks for your reply.
>
> One situation where one might require masked nearest neighbor 
> interpolation is when, on a given fixed grid, interpolating velocities 
> on cell corners (B-grid) to faces (C-grid). Cells will be defined as 
> either land or ocean cells, masked or un-masked respectively. The 
> masked or un-masked character of cells does not change. Interpolating 
> velocities from corners adjacent to masked cells, to cell centers on 
> un-masked cells will require the behavior in question. Imagine two 
> adjacent cells, one masked and the other not. The velocities on the 
> cell corners that lie on the coast (adjacent to a masked and an 
> un-masked cell) are masked. A desireable behavior of the interpolator 
> would be to produce an un-masked cell centered velocity on the 
> un-masked cell that uses values from adjacent un-masked velocity values.
>
> Thanks,
> Juan
>
Juan: I can see why you want it in this case, but I think in general 
users would expect a masked value if the nearest neighbor is masked. In 
addition, I don't see how to implement it easily. How far are you 
willing to go to find a nearest neighbor that is not masked?
In short, for your use case you'll have to implement your own custom 
solution. Of course, if you can show me a simple modification to the 
Basemap interp function that does what you want, and can be enabled with 
a kwarg, I'll reconsider.
-Jeff
>
> On 8/03/11 12:23 AM, Jeff Whitaker wrote:
>> On 3/7/11 5:50 AM, Jeff Whitaker wrote:
>>> On 3/6/11 8:58 PM, Juan A. Saenz wrote:
>>>> Hi,
>>>>
>>>> I use Basemap and netCDF4-python on a regular basis, and find them
>>>> very useful tools. Thank you for developing them!
>>>>
>>>> I noticed that when using basemap.interp for nearest neighbor
>>>> (order=0) the interpolation is not masked, and nearest neighbor masked
>>>> values will be used in the interpolation. I was wondering if you could
>>>> suggest a way to do nearest neighbor interpolation where masked are
>>>> supported, i.e. nearest neighbor values that are not masked.
>>>>
>>>> Thanks for your help,
>>>> Juan
>>>>
>>> Juan: I agree that this would be desirable behavior. Unfortunately,
>>> it's not obvious to me how to do it. I'll think about it and get back
>>> to you. (cc'ing matplotlib-users list).
>>>
>>> -Jeff
>>>
>>
>> Juan: On second thought, I'm not sure this is desirable behavior. I 
>> would guess that most of the time, if a nearest neighbor is masked, 
>> the user would expect the interpolation routine to return a masked 
>> value. I would be interested to hear what others think.
>>
>> -Jeff
>>
>
>
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On 03/07/2011 11:51 AM, Mark Bakker wrote:
> Hello List,
>
> My values on the vertical axis are large, but the range is small:
>
> plot([3004,3005,3006])
>
> By default this plots 0,1,2 as tickmarks along the vertical axis, and
> then at the top of the vertical axis is prints "+3.005e3".
>
> I prefer to simply get 3004,3005,3006 at the tickmarks.
>
> Any (easy) way I can change the default formatting?
If you are using a recent mpl, try following your plot command with
ticklabel_format(useOffset=False)
Eric
>
> Sorry for the easy question,
>
> Mark
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Scientific Software Developer
NOAA Emergency Response Division
Help us develop our next-generation oil spill transport model.
Background:
The Emergency Response Division (ERD) of NOAA's Office of Response and 
Restoration (OR&R) provides scientific expertise to support the response 
to oil and chemical spills in the coastal environment. We played a major 
role in the recent Deepwater Horizon oil spill in the Gulf of Mexico. 
In order to fulfill our mission, we develop many of the software tools 
and models required to support a response to hazardous material spills. 
 In the wake of the Deepwater horizon incident, we are embarking on a 
program to develop our next-generation oil spill transport model, taking 
into account lessons learned from years of response and this major incident.
General Characteristics:
The incumbent of this position will provide software development 
services to support the mission of the Emergency Response Division of 
NOAA's Office of Response and Restoration. As part of his/her efforts, 
independent evaluation and application of development techniques, 
algorithms, software architecture, and programming patterns will be 
required. The incumbent will work with the staff of ERD to provide 
analysis on user needs and software, GUI, and library design. He/she 
will be expect to work primarily on site at NOAA's facility in Seattle.
Knowledge:
The incumbent must be able to apply modern concepts of software 
engineering and design to the development of computational code, desktop 
applications, web applications, and libraries. The incumbent will need 
to be able to design, write, refactor, and implement code for a complex 
desktop and/or web application and computational library. The incumbent 
will work with a multi-disciplinary team including scientists, users, 
and other developers, utilizing software development practices such as 
usability design, version control, bug and issue tracking, and unit 
testing. Good communication skills and the knowledge of working as part 
of a team are required.
Direction received:
The incumbent will participate on various research and development 
teams. While endpoints will be identified through Division management 
and some direct supervision will be provided, the incumbent will be 
responsible for progressively being able to take input from team 
meetings and design objectives and propose strategies for reaching 
endpoints.
Typical duties and responsibilities:
The incumbent will work with the oil and chemical spill modeling team to 
improve and develop new tools and models used in fate and transport 
forecasting. Different components of the project will be written in 
C++, Python, and Javascript.
Education requirement, minimum:
Bachelor's degree in a technical discipline.
Experience requirement, minimum:
One to five years experience in development of complex software systems 
in one or more full-featured programming languages (C, C++, Java, 
Python, Ruby, Fortran, etc.)
The team requires experience in the following languages/disciplines. 
Each incumbent will need experience in some subset:
 * Computational/Scientific programming
 * Numerical Analysis/Methods
 * Parallel processing
 * Desktop GUI
 * Web services
 * Web clients: HTML/CSS/Javascript
 * Python
 * wxPython
 * OpenGL
 * C/C++
 * Python--C/C++ integration
 * Software development team leadership
While the incumbent will work on-site at NOAA, directly with the NOAA 
team, this is a contract position with General Dynamics Information 
Technology:
http://www.gdit.com/default.aspx
For more information and to apply, use the GDIT web site:
https://secure.resumeware.net/gdns_rw/gdns_web/job_detail.cfm?key=59436&show_cart=0&referredId=20
if that long url doesn't work, try:
http://www.resumeware.net/gdns_rw/gdns_web/job_search.cfm
and search for job ID: 179178
NOTE: This is a potion being hired by GDIT to work with NOAA, so any 
questions about salary, benefits, etc, etc should go to GDIT. However, 
feel free to send me questions about our organization, working 
conditions, more detail about the nature of the projects etc.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Mon, Mar 7, 2011 at 3:51 PM, Mark Bakker <ma...@gm...> wrote:
> Hello List,
>
> My values on the vertical axis are large, but the range is small:
>
> plot([3004,3005,3006])
>
> By default this plots 0,1,2 as tickmarks along the vertical axis, and then
> at the top of the vertical axis is prints "+3.005e3".
>
> I prefer to simply get 3004,3005,3006 at the tickmarks.
>
> Any (easy) way I can change the default formatting?
>
> Sorry for the easy question,
>
> Mark
>
>
Here is an example of what you are looking for. There are other formatters
as well, but this is pretty straight-forward to modify to your needs.
http://matplotlib.sourceforge.net/examples/pylab_examples/custom_ticker1.html?highlight=tick%20formatter
I hope this helps!
Ben Root

Hello List,
My values on the vertical axis are large, but the range is small:
plot([3004,3005,3006])
By default this plots 0,1,2 as tickmarks along the vertical axis, and then
at the top of the vertical axis is prints "+3.005e3".
I prefer to simply get 3004,3005,3006 at the tickmarks.
Any (easy) way I can change the default formatting?
Sorry for the easy question,
Mark

2011年3月7日 Andrea Crotti <and...@gm...>:
> [...]
> t = matplotlib.text.Text(0, 0, "very long string")
> t.get_bbox_patch()
>
> to get the size and then do the rest.
>
> but this still returns None, probably because at this point there's
> probably something still missing, right?
>
> And when I get the resulting size, how do I make my axes big enough
> anyway?
As Ben explained you need to draw first. So the usual path is:
1. Draw
2. Figure out the size of potentially problematic things (labels,
titles...) and the space you need.
3. Adjust subplots or whatever needs adjustment to fit.
4. Draw again.
Sort of weird but it works and I think it's widely used.
Goyo

Jeff, thanks for your reply.
One situation where one might require masked nearest neighbor 
interpolation is when, on a given fixed grid, interpolating velocities 
on cell corners (B-grid) to faces (C-grid). Cells will be defined as 
either land or ocean cells, masked or un-masked respectively. The masked 
or un-masked character of cells does not change. Interpolating 
velocities from corners adjacent to masked cells, to cell centers on 
un-masked cells will require the behavior in question. Imagine two 
adjacent cells, one masked and the other not. The velocities on the cell 
corners that lie on the coast (adjacent to a masked and an un-masked 
cell) are masked. A desireable behavior of the interpolator would be to 
produce an un-masked cell centered velocity on the un-masked cell that 
uses values from adjacent un-masked velocity values.
Thanks,
Juan
On 8/03/11 12:23 AM, Jeff Whitaker wrote:
> On 3/7/11 5:50 AM, Jeff Whitaker wrote:
>> On 3/6/11 8:58 PM, Juan A. Saenz wrote:
>>> Hi,
>>>
>>> I use Basemap and netCDF4-python on a regular basis, and find them
>>> very useful tools. Thank you for developing them!
>>>
>>> I noticed that when using basemap.interp for nearest neighbor
>>> (order=0) the interpolation is not masked, and nearest neighbor masked
>>> values will be used in the interpolation. I was wondering if you could
>>> suggest a way to do nearest neighbor interpolation where masked are
>>> supported, i.e. nearest neighbor values that are not masked.
>>>
>>> Thanks for your help,
>>> Juan
>>>
>> Juan: I agree that this would be desirable behavior. Unfortunately,
>> it's not obvious to me how to do it. I'll think about it and get back
>> to you. (cc'ing matplotlib-users list).
>>
>> -Jeff
>>
>
> Juan: On second thought, I'm not sure this is desirable behavior. I 
> would guess that most of the time, if a nearest neighbor is masked, 
> the user would expect the interpolation routine to return a masked 
> value. I would be interested to hear what others think.
>
> -Jeff
>
-- 
Juan A. Saenz
Postdoctoral Fellow
Geophysical Fluid Dynamics
Research School of Earth Sciences
Australian National University
Building 61
Mills Road
Canberra, ACT 0200
AUSTRALIA
Office: +61 2 6125 9968
Admin: +61 2 6125 5502
Fax: +61 2 6257 2737

On Mon, Mar 7, 2011 at 2:09 PM, M.Rule <mru...@gm...> wrote:
> I want to plot as if rendering a 3D object. Usually this would involve
> specifying vertices and facets. Its not obvious to me how to send this to
> functions like plot_wireframe. I have looked at the documentation and the
> tutorials, and am still not getting it.
>
> Maybe start with something very simple : how would I plot a cube ?
> verts =
> [[1,1,1],[1,1,-1],[1,-1,-1],[1,-1,1],[-1,1,1],[-1,1,-1],[-1,-1,-1],[-1,-1,1]]
> faces = [[0,1,2,3],[4,5,6,7],[0,4,5,1],[0,4,7,3],[1,5,6,2],[2,6,7,3]]
>
>
The wireframe and surface functions are a little un-intuitive to deal with.
Based on your description of your problem and your example, it might be
better to create a collection of 3d polygon objects. Consider this example:
http://matplotlib.sourceforge.net/examples/mplot3d/polys3d_demo.html
I hope this helps you.
Ben Root

I want to plot as if rendering a 3D object. Usually this would involve
specifying vertices and facets. Its not obvious to me how to send this to
functions like plot_wireframe. I have looked at the documentation and the
tutorials, and am still not getting it.
Maybe start with something very simple : how would I plot a cube ?
verts =
[[1,1,1],[1,1,-1],[1,-1,-1],[1,-1,1],[-1,1,1],[-1,1,-1],[-1,-1,-1],[-1,-1,1]]
faces = [[0,1,2,3],[4,5,6,7],[0,4,5,1],[0,4,7,3],[1,5,6,2],[2,6,7,3]]

On Mon, Mar 7, 2011 at 12:42 PM, Brendan Barnwell <bre...@br...>wrote:
> On 2011年03月07日 08:59, Benjamin Root wrote:
> > On Mon, Mar 7, 2011 at 10:33 AM, Yuri D'Elia<wa...@th...> wrote:
> >> I was reading this at the time:
> >>
> >> http://matplotlib.sourceforge.net/faq/usage_faq.html
> >>
> >> I inferred pyplot was just a matlab-like interface on top of
> matplotlib,
> >> and figured using directly the matplotlib was acceptable.
> >>
> >
> > Yeah, I am guessing that page is a little out-dated and could be better
> > worded. However, the page does say that the preferred style is the
> pyplot
> > interface. Also notice that it is extremely rare for any of the
> > documentation to directly create the matplotlib objects without the
> pyplot
> > or pylab interface.
>
> I think this documentation should definitely be updated, then.
> I've
> been using matplotlib a lot the last few months and was totally
> unaware that pyplot was "required". Good thing I read this message! :-)
>
> > The interface should create the figure objects, the figure objects should
> > create the axes objects, the axes objects should create the axis objects,
> > and so on and so forth.
>
> That makes perfect sense, but is not at all what's implied by the
> text on the page linked above.
>
> Best wishes,
> --
> Brendan Barnwell
> "Do not follow where the path may lead. Go, instead, where there is
> no path, and leave a trail."
> --author unknown
>
>
Tell me what you think about this wording. Don't worry about the links on
the page:
https://github.com/WeatherGod/matplotlib/blob/62a02cce1ef98ff2360049ef31074bd9e82670d3/doc/faq/usage_faq.rst
I greatly appreciate any further comments you have. Your perspective is
invaluable for improving our docs for users like you.
Ben Root

On 2011年03月07日 08:59, Benjamin Root wrote:
> On Mon, Mar 7, 2011 at 10:33 AM, Yuri D'Elia<wa...@th...> wrote:
>> I was reading this at the time:
>>
>> http://matplotlib.sourceforge.net/faq/usage_faq.html
>>
>> I inferred pyplot was just a matlab-like interface on top of matplotlib,
>> and figured using directly the matplotlib was acceptable.
>>
>
> Yeah, I am guessing that page is a little out-dated and could be better
> worded. However, the page does say that the preferred style is the pyplot
> interface. Also notice that it is extremely rare for any of the
> documentation to directly create the matplotlib objects without the pyplot
> or pylab interface.
	I think this documentation should definitely be updated, then. I've 
been using matplotlib a lot the last few months and was totally 
unaware that pyplot was "required". Good thing I read this message! :-)
> The interface should create the figure objects, the figure objects should
> create the axes objects, the axes objects should create the axis objects,
> and so on and so forth.
	That makes perfect sense, but is not at all what's implied by the 
text on the page linked above.
Best wishes,
-- 
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is 
no path, and leave a trail."
 --author unknown

On Mon, Mar 7, 2011 at 8:22 PM, Yuri D'Elia <wa...@us...> wrote:
> With matplotlib, I have to do the following:
>
> legend(bbox_to_anchor=(1, 1 + ?), loc=2)
>
> but how do I calculate the vertical location?
Maybe you want to try something like
leg = legend([l1], ["Test"], borderaxespad=0,
 bbox_to_anchor=(1.02, 1), loc=2)
?
-JJ

On Tue, Mar 8, 2011 at 2:20 AM, Benjamin Root <ben...@ou...> wrote:
> And this appears to be a bug. Looks like the call signature for the legend
> object's get_window_extent() doesn't match the call signature for all other
> artists.
>
Yes. It is a bug.
Meanwhile, you may use
bbox_extra_artists=[leg.legendPatch]
as a workaround.
Regards,
-JJ

On Mon, Mar 7, 2011 at 11:09 AM, Yuri D'Elia <wa...@us...> wrote:
> On Tue, 8 Mar 2011 02:03:54 +0900
> Jae-Joon Lee <lee...@gm...> wrote:
>
> > On Mon, Mar 7, 2011 at 7:36 PM, Yuri D'Elia <wa...@us...> wrote:
> > In fact, supporting the "bbox_inches" is a real hack.
> > As I mentioned in my previous email, matplotlib artists can have
> > spline paths. And artists can also be clipped by an arbitrary spline
> > path. And, generally speaking, finding out the exact bounding box of
> > an artist is difficult (but I must confess that I'm not an expert on
> > this field and any correction or advise will be appreciated). I
> > believe the AGG library, that matplotlib is based on, can provide an
> > approximate bounding box for spline paths, but I'm not sure if it will
> > work when clipping is involved (at least, the *get_window_extent*
> > does not properly work when clipping is involved).
>
> I see. But can't you simply skip spline paths from the calculation?
> This would remove the need for bbox_extra_artists for 99% of the cases.
>
> > I'll consider to support all artists in a "tight" bbox mode if
> > *get_window_extent* gives back exact bounding box (accounting the
> > clipping) for "all" artists. Otherwise, I'm not inclined to do this.
>
> I don't know if you read this already, but: all artists should at least
> work with bbox_extra_artists, right?
>
> While placing the legend outside the plot I tried the following:
>
> egend = plot.legend()
> pic.savefig(..., bbox_extra_artists=[legend])
>
> but it fails:
>
> Traceback (most recent call last):
> File "./plot.py", line 108, in <module>
> fig.savefig(sys.argv[1], bbox_inches='tight', bbox_extra_artists=xa)
> File "/usr/lib/pymodules/python2.6/matplotlib/figure.py", line 1084, in
> savefig
> self.canvas.print_figure(*args, **kwargs)
> File "/usr/lib/pymodules/python2.6/matplotlib/backend_bases.py", line
> 1894, in print_figure
> in kwargs.pop("bbox_extra_artists", [])]
> TypeError: get_window_extent() takes exactly 1 argument (2 given)
>
>
And this appears to be a bug. Looks like the call signature for the legend
object's get_window_extent() doesn't match the call signature for all other
artists.
I will write up a patch for this.
Ben Root

On Tue, 8 Mar 2011 02:03:54 +0900
Jae-Joon Lee <lee...@gm...> wrote:
> On Mon, Mar 7, 2011 at 7:36 PM, Yuri D'Elia <wa...@us...> wrote:
> In fact, supporting the "bbox_inches" is a real hack.
> As I mentioned in my previous email, matplotlib artists can have
> spline paths. And artists can also be clipped by an arbitrary spline
> path. And, generally speaking, finding out the exact bounding box of
> an artist is difficult (but I must confess that I'm not an expert on
> this field and any correction or advise will be appreciated). I
> believe the AGG library, that matplotlib is based on, can provide an
> approximate bounding box for spline paths, but I'm not sure if it will
> work when clipping is involved (at least, the *get_window_extent*
> does not properly work when clipping is involved).
I see. But can't you simply skip spline paths from the calculation?
This would remove the need for bbox_extra_artists for 99% of the cases.
> I'll consider to support all artists in a "tight" bbox mode if
> *get_window_extent* gives back exact bounding box (accounting the
> clipping) for "all" artists. Otherwise, I'm not inclined to do this.
I don't know if you read this already, but: all artists should at least work with bbox_extra_artists, right?
While placing the legend outside the plot I tried the following:
egend = plot.legend()
pic.savefig(..., bbox_extra_artists=[legend])
but it fails:
Traceback (most recent call last):
 File "./plot.py", line 108, in <module>
 fig.savefig(sys.argv[1], bbox_inches='tight', bbox_extra_artists=xa)
 File "/usr/lib/pymodules/python2.6/matplotlib/figure.py", line 1084, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "/usr/lib/pymodules/python2.6/matplotlib/backend_bases.py", line 1894, in print_figure
 in kwargs.pop("bbox_extra_artists", [])]
TypeError: get_window_extent() takes exactly 1 argument (2 given)

On Mon, Mar 7, 2011 at 7:36 PM, Yuri D'Elia <wa...@us...> wrote:
> I consider bbox_extra_artists some kind of a hack (IMHO, all artists should be considered with a 'tight' box), but coming from gnuplot/asymptote maybe my point of view is biased.
> What would be the point of a 'tight' box that excludes parts of the plot? I would specify the coordinates myself if I needed clipping.
>
In fact, supporting the "bbox_inches" is a real hack.
As I mentioned in my previous email, matplotlib artists can have
spline paths. And artists can also be clipped by an arbitrary spline
path. And, generally speaking, finding out the exact bounding box of
an artist is difficult (but I must confess that I'm not an expert on
this field and any correction or advise will be appreciated). I
believe the AGG library, that matplotlib is based on, can provide an
approximate bounding box for spline paths, but I'm not sure if it will
work when clipping is involved (at least, the *get_window_extent*
does not properly work when clipping is involved).
I'll consider to support all artists in a "tight" bbox mode if
*get_window_extent* gives back exact bounding box (accounting the
clipping) for "all" artists. Otherwise, I'm not inclined to do this.
Regards,
-JJ

On Mon, Mar 7, 2011 at 10:33 AM, Yuri D'Elia <wa...@th...> wrote:
> On Mon, 7 Mar 2011 09:25:23 -0600
> Benjamin Root <ben...@ou...> wrote:
>
> > The problem is that you are creating your figure wrong. Try this:
> >
> > import matplotlib as mpl
> > mpl.use("Agg")
> > import matplotlib.pyplot as plt
> >
> > fig = plt.figure(figsize=(20, 20))
> > ax = fig.add_subplot(111)
> > ax.set_title("Subtitle")
> > ax.plot([1, 2, 3], [3, 2, 1])
> > st = fig.suptitle("Horray!", fontsize=20)
> > fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st])
> >
> > Notice that I am using the pyplot interface. Matplotlib was intended to
> be
> > used through either this pyplot interface or the pylab interface (which I
> do
> > not personally recommend if you want full control over your plots). If
> you
> > don't use either interfaces, then don't be surprised when things do not
> work
> > properly. In particular, creating the figure object by directly calling
> the
> > Figure constructor bypasses important steps that involves attaching the
> > appropriate backend to the figure object.
>
> I was reading this at the time:
>
> http://matplotlib.sourceforge.net/faq/usage_faq.html
>
> I inferred pyplot was just a matlab-like interface on top of matplotlib,
> and figured using directly the matplotlib was acceptable.
>
Yeah, I am guessing that page is a little out-dated and could be better
worded. However, the page does say that the preferred style is the pyplot
interface. Also notice that it is extremely rare for any of the
documentation to directly create the matplotlib objects without the pyplot
or pylab interface.
The pointof the statement "MATLAB-like" is that most of the plotting
functions available in MATLAB are also available in matplotlib. In
addition, the phrase "more MATLAB-like" is meant to state that various
mathematical functions are made available as well. This was designed to
make transitions from MATLAB to matplotlib easier for the user. Ultimately,
we desire that the user transitions completely over to the pyplot interface.
Note that this has nothing to do with interactivity or proceedural. If
anything, pylab was more intended for interactivity because its syntax is
more concise, but you lose a lot of control.
> Reading the documentation of the single objects of matplotlib was enough to
> get me started. I see pyplot as having more shortcuts for common operations,
> but I was unsure how far can I could go by using pyplot only.
>
>
Think of it this way. Matplotlib depends a lot upon hierarchical design.
The pyplot (or pylab) interfaces sit on top of that heirarchy and represents
the matplotlib environment. This environment creates figures. These
figures can many components, the most important of which are one or more
axes objects. Each axes object has two or more axis objects and are
responsible for plotting themselves. While there are some convenience
functions through pyplot for doing some things like setting an axis label,
it is not required to use pyplot for that. You can (and often should) use
the axes object's method for doing so.
The point is that you can use the matplotlib objects for a lot of things,
and it is great that you are embracing the object oriented nature of
matplotlib. However, your problem was caused by-passing the hierarchy:
The interface should create the figure objects, the figure objects should
create the axes objects, the axes objects should create the axis objects,
and so on and so forth.
I hope that makes it clearer for you, and I hope you continue to use
matplotlib and find it useful!
Ben Root

On Mon, 7 Mar 2011 09:25:23 -0600
Benjamin Root <ben...@ou...> wrote:
> The problem is that you are creating your figure wrong. Try this:
> 
> import matplotlib as mpl
> mpl.use("Agg")
> import matplotlib.pyplot as plt
> 
> fig = plt.figure(figsize=(20, 20))
> ax = fig.add_subplot(111)
> ax.set_title("Subtitle")
> ax.plot([1, 2, 3], [3, 2, 1])
> st = fig.suptitle("Horray!", fontsize=20)
> fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st])
> 
> Notice that I am using the pyplot interface. Matplotlib was intended to be
> used through either this pyplot interface or the pylab interface (which I do
> not personally recommend if you want full control over your plots). If you
> don't use either interfaces, then don't be surprised when things do not work
> properly. In particular, creating the figure object by directly calling the
> Figure constructor bypasses important steps that involves attaching the
> appropriate backend to the figure object.
I was reading this at the time:
http://matplotlib.sourceforge.net/faq/usage_faq.html
I inferred pyplot was just a matlab-like interface on top of matplotlib, and figured using directly the matplotlib was acceptable.
Reading the documentation of the single objects of matplotlib was enough to get me started. I see pyplot as having more shortcuts for common operations, but I was unsure how far can I could go by using pyplot only.
Generally, I didn't have any trouble. The includes are a bit verbose, but that's it.
> Also notice that I name the object coming from add_subplot() "ax" instead of
> "plot". This is for clarity and to avoid confusion with the command
> "plot". This is also the generally accepted coding convention in
> matplotlib.
Indeed, thanks for the remark.
Thanks again for your comments.

Thankyou for the reply, ill test that in a minute, and let you know the
result.
Benjamin Root-2 wrote:
> 
> On Mon, Mar 7, 2011 at 10:01 AM, Muffles <dan...@gm...> wrote:
> 
> Can you include a screenshot of what you see?
> 
> 
Here it is:
http://old.nabble.com/file/p31089197/hov.png 
Thank you
-- 
View this message in context: http://old.nabble.com/Many-basic-questions-i-cant-find-solution-tp31088840p31089197.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Mon, Mar 7, 2011 at 10:01 AM, Muffles <dan...@gm...> wrote:
>
> Hello, i am not a user of matplotlib, i just have to do something in it.
> I managed to get the plot i wanted, but i have been going around for hours
> trying to do some fine tuning and cant get around it. The matplotlib seems
> way too extense for me to find the solutions without studying it avidly,
> and
> i just dont have the time...
> But trust me, i've looked everywhere and tried everything...
>
> What i need to do is:
> - Change the axes labeling (if its like 1 2 3 4 5 6 change it to A B C D
> for example)
>
You want set_xticklabels() (or set_yticklabels()):
http://matplotlib.sourceforge.net/api/axes_api.html?highlight=set_xticklabels#matplotlib.axes.Axes.set_xticklabels
Note that will not change the number of ticks already established for the
axis. For that, you can use set_xticks(), which accepts a list of values
where to set the tick marks (you should probably use set_xticklabels() after
set_xticks()). Note that you will need to have access to the axes object.
For example:
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.gca() # <--- the axes object I was talking about...
ax.scatter([], [])
ax.set_xticks([0.2, 0.4, 0.6, 0.8])
ax.set_xticklabels(['A', 'B', 'C', 'D'])
plt.show()
> - Resize the window, not the plot (I have the figsize=(6,10) and thats
> fine
> for the plot, but the colorbar just gets cut in half, cant fit in the
> window)
>
>
Can you include a screenshot of what you see?
Ben Root

On Mon, 7 Mar 2011 09:08:29 -0600
Benjamin Root <ben...@ou...> wrote:
> Matplotlib is designed to give you maximum control over the figure elements
> while still maintaining sensible defaults. This is helpful in some cases,
> and not so helpful in others. In your case of placing a legend outside an
> axes, calculating the location can be a bit of a trial-and-error, but if the
> number of elements in your legend is going to be fixed, once you find a good
> value, you can just leave it that way in your script.
The problem with trial-and-error is that I can clearly see a difference of the sub-pixel rendering of the legend's frame when a lot of subplots are present - hinting at a slight-but-nonzero difference between the axis and the legend.
This bothers me at a sub-conscious level.. :)
> Automatic determination of legend size is difficult because the size of the
> text objects are not known until draw time. However, it is possible to
> query your legend object for its bbox and then reposition your legend object
> accordingly (but only after the initial draw). This is tricky, but do-able.
I wonder how gnuplot implements its automatic layout, since manual placement is never necessary, even in multiplot outputs (for those who are not familiar with gnuplot: multiplot implements simple grid layouts with fully automatic positioning of the subplots).
> By the way, another possible command you might want is called "figlegend",
> which is a legend that is attached to the figure object rather than the axes
> object. It is plotted outside the axes, and has to be given all the objects
> to list, but it might be what you want. See this example:
Thanks, I will look into it.

Hello, i am not a user of matplotlib, i just have to do something in it.
I managed to get the plot i wanted, but i have been going around for hours
trying to do some fine tuning and cant get around it. The matplotlib seems
way too extense for me to find the solutions without studying it avidly, and
i just dont have the time...
But trust me, i've looked everywhere and tried everything...
What i need to do is:
 - Change the axes labeling (if its like 1 2 3 4 5 6 change it to A B C D
for example)
 - Resize the window, not the plot (I have the figsize=(6,10) and thats fine
for the plot, but the colorbar just gets cut in half, cant fit in the
window)
 
Thankyou in advance
-- 
View this message in context: http://old.nabble.com/Many-basic-questions-i-cant-find-solution-tp31088840p31088840.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Mon, Mar 7, 2011 at 1:29 AM, Eric Firing <ef...@ha...> wrote:
> On 03/06/2011 09:14 PM, Thomas Lecocq wrote:
> > Dear,
> >
> > Please also note that '+' and 'x' are "lines", hence if you want them
> > coloured, you'll need to set edgecolor="g" rather than just color='g' ...
>
> Exactly, but in the scatter context one shouldn't have to do this. I
> consider it a bug, so I will shortly commit a fix. Markers that have no
> face showing, only edge, should still behave as expected when a "c"
> kwarg is supplied. I think this is what one would expect based on the
> docstring.
>
> Eric
>
>
I always did wonder what the difference was between 'c' and 'color'. We
should definitely make this clearer in the docs. Obviously, the 'c'
argument should always work because the user shouldn't have to know the
difference. Those who do know the difference can continue using the
appropriate kwargs for advanced control.
Ben Root

On Mon, Mar 7, 2011 at 4:36 AM, Yuri D'Elia <wa...@us...> wrote:
> On Fri, 4 Mar 2011 14:57:34 -0600
> Benjamin Root <ben...@ou...> wrote:
>
> > Which version of matplotlib are you using? This example works for me
> using
> > the latest matplotlib from source. Also, why the awkward usage and
>
> Yes, with matplotlib 1.0 bbox_extra_artists now works.
>
> I consider bbox_extra_artists some kind of a hack (IMHO, all artists should
> be considered with a 'tight' box), but coming from gnuplot/asymptote maybe
> my point of view is biased.
> What would be the point of a 'tight' box that excludes parts of the plot? I
> would specify the coordinates myself if I needed clipping.
>
> > imports? If you want to force the Agg backend to be used, you could just
> > do:
> >
> > import matplotlib
> > matplotlib.use("Agg")
> >
> > before any other matplotlib imports.
>
> Thanks for the suggestion, that looks promising, but doesn't work:
>
> ----
> import matplotlib as mpl
> mpl.use("Agg")
> import matplotlib.figure
> fig = mpl.figure.Figure()
> fig.set_size_inches((20,20))
> plot = fig.add_subplot(111)
> plot.set_title("Subtitle")
> plot.plot([1,2,3], [3,2,1])
> st = fig.suptitle("Horray!", fontsize=20)
> fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st])
> ----
>
>
The problem is that you are creating your figure wrong. Try this:
import matplotlib as mpl
mpl.use("Agg")
import matplotlib.pyplot as plt
fig = plt.figure(figsize=(20, 20))
ax = fig.add_subplot(111)
ax.set_title("Subtitle")
ax.plot([1, 2, 3], [3, 2, 1])
st = fig.suptitle("Horray!", fontsize=20)
fig.savefig("out.png", bbox_inches='tight', bbox_extra_artists=[st])
Notice that I am using the pyplot interface. Matplotlib was intended to be
used through either this pyplot interface or the pylab interface (which I do
not personally recommend if you want full control over your plots). If you
don't use either interfaces, then don't be surprised when things do not work
properly. In particular, creating the figure object by directly calling the
Figure constructor bypasses important steps that involves attaching the
appropriate backend to the figure object.
Also notice that I name the object coming from add_subplot() "ax" instead of
"plot". This is for clarity and to avoid confusion with the command
"plot". This is also the generally accepted coding convention in
matplotlib.
>
> I find the documentation a bit scattered around this subject.
> I'm not using the pyplot interface, so I guess that .use("Agg") doesn't do
> anything for me?
> I also have no reason to use the pyplot interface, why should I? I have no
> matlab background, and I mostly use matplotlib procedurally (ie not
> interactively).
>
The only accepted ways to use matplotlib are through either the pyplot or
the pylab interfaces. This is why they are called interfaces. It does not
matter if you are using matplotlib interactively or procedurally. I
personally use the pyplot interface in all of my scripts, as I rarely ever
do interactive plotting. The pylab interface is more geared towards
interactive plotting. These interfaces are designed to make your life
easier.
Think of it this way. The developers can make many changes to matplotlib
internals from one release to the next, but we do our best to make the
interface as stable as possible. If you write code that do not utilize the
pylab or pyplot interfaces, then your scripts will likely break at the next
release.
Trust me, a lot of your problems will be solved by picking an interface (I
recommend pyplot) and sticking with it.
I hope this is helpful,
Ben Root

On Mon, Mar 7, 2011 at 5:22 AM, Yuri D'Elia <wa...@us...> wrote:
> Hi everyone. I'm a newbye to matplotlib, so excuse my naive questions. I
> have a large experience with gnuplot and asymptote, and I only recently
> started to experiment with matplotlib.
>
> Some background: I'm trying to use matplotlib mostly for complex plots with
> a lot of data. Gnuplot is usually fine, but I ended up too often producing
> huge batch scripts consisting of overlarge plot[] command sequences and
> pre-processed input files. Asymptote is awesome, but reading data is a mayor
> pita. As a result, I mostly use gnuplot interactively, and asymptote when I
> need to plot functions. Both packages are generally excellent, they have
> good support of multiple plots and usually never require manual placement of
> figure elements.
>
> So far my experience with matplotlib is that a lot of manual placement seem
> to be required when coming down to multiple plots and legends.
>
> I have a large figure, consisting of several dense plots.
>
> I'm trying to plot the legend outside of the plots, but I find it
> bothersome how difficult it is to place the legend outside the plot.
>
> With gnuplot, it's as simple as:
>
> > set key outside top right
>
> This also works perfectly fine with 'multiplot' (gnuplot automatic multiple
> plot layout).
> With matplotlib, I have to do the following:
>
> legend(bbox_to_anchor=(1, 1 + ?), loc=2)
>
> but how do I calculate the vertical location? Do I have to go at random to
> align the legend to the plot axis? It also breaks wonderfully with multiple
> plots, since plot(xyz) seems to consider only the axis and nothing more.
>
> Can't we just have:
>
> legend(loc=2, outside=true)
>
> please? The vast majority of plots I do are too dense to have a legend
> inside the plot.
>
> Also, related to my previous message (savefig bbox_inches='tight' does not
> consider suptitle), the legend is not considered when constructing a 'tight'
> boundary box.
> It seems to me that the legend is another obvious element that should be
> taken into account without resorting to bbox_extra_artists.
>
> Thanks again.
>
>
>
Matplotlib is designed to give you maximum control over the figure elements
while still maintaining sensible defaults. This is helpful in some cases,
and not so helpful in others. In your case of placing a legend outside an
axes, calculating the location can be a bit of a trial-and-error, but if the
number of elements in your legend is going to be fixed, once you find a good
value, you can just leave it that way in your script.
Automatic determination of legend size is difficult because the size of the
text objects are not known until draw time. However, it is possible to
query your legend object for its bbox and then reposition your legend object
accordingly (but only after the initial draw). This is tricky, but do-able.
By the way, another possible command you might want is called "figlegend",
which is a legend that is attached to the figure object rather than the axes
object. It is plotted outside the axes, and has to be given all the objects
to list, but it might be what you want. See this example:
http://matplotlib.sourceforge.net/examples/pylab_examples/figlegend_demo.html
I hope that is helpful,
Ben Root