matplotlib-devel Mailing List for matplotlib (Page 2)

John,
I had some questions about this resize work.  Here is the code for resize 
from backend_gtk.py:

     def resize(self, w, h):
         'set the drawing area size in pixels'
         winw, winh = self.parent.parent.get_size()
         tmp, tmp, myw, myh = self.allocation
         padw = winw-myw
         padh = winh-myh
         self.parent.parent.resize(w+padw, h+padh)

I'm a little concerned about this implementation.  It looks like the widget 
is telling it's parent's parent to resize.  Doesn't this mean that the 
ability of the widget to be used as a modular component is reduced because 
this code requires a certain parent child relationship?

I think it's fairly important that a widget have only very minimum 
interactions with it's parent.   Is there some way this could be 
implemented that doesn't require the child widget to be calling methods on 
the parent?

If I understand the basic premise you've outlined below, you want a resize 
in the child (the drawing widget) to cause the parent window to 
resize.  Only the parent can figure out what it's size needs to be (since 
it knows about it's margins, toolbars, etc).  On the surface, it seems like 
there are two ways to handling this:
1) Tell the window to resize the canvas.  The window can use it's own 
layout classes, etc and correctly resize itself and the canvas.
2) Tell the canvas to resize and have this trigger a window resize.

I think the first option is much cleaner.  However, if that isn't possible, 
I suggest that we do something like this:

- Tell the canvas to resize.  It should resize itself and emit some type of 
'plotCanvasResize' signal (GUI callback).
- When the window is originally constructed, it would attach a method on 
the window to this signal so that we basically get the same behavior as 1) 
above.  Telling the canvas to resize emits the signal which calls the 
window method to do the real resizing.  The canvas widget never knows that 
it's part of the window at all.

Of course this assumes that we have access to signal/slot (in Qt terms) 
systems in the Python layer.  I'd also suggest that we stay away from 
calling it 'resize' since most GUI toolkits already have resize 
methods/attributes that mean very specific things.

Thoughts?
Ted

>  There is a new method in the figure canvas in CVS that I would like
>  the maintainers of the various GUI backends to implement
>
>  class FigureCanvasYourBackend
>
>      def resize(self, w, h):
>          """
>          set the canvas size in pixels
>          """
>          pass
>
>  This should set the canvas (not window) size and trigger a GUI resize
>  event so that the window is resized accordingly.  There is a reference
>  implementation in backend_gtk.py.  You should be able to lift the
>  logic for computing the new canvas size directly from that code.
>
>  Among other things, this will allow better control of the canvas size
>  from a script or shell.  Eg, the following works with GTKAgg in an
>  interactive session:
>
>      In [1]: fig = figure()
>      In [2]: fig.set_figsize_inches(3,4,forward=True)
>      In [3]: fig.canvas.resize(500,600)
>
>  Ie, you can set the canvas size either in pixels or inches depending
>  on which method you choose.
>
>  Also, I added a new connect signal 'resize_event' that triggers a
>  backend_bases.ResizeEvent on a canvas.resize.  You should call
>
>    self.resize_event()
>
>  from the part of your code that handles GUI configure events (see for
>  example the GTK and GTKAgg backends).  Note depending on your toolkit,
>  you may not want to call this from the FigureCanvas.resize method.
>  Eg, in GTK* calling "canvas.resize" triggers a call to
>  canvas.configure_event, which in turn sets the new figure size
>  properties and once all this is done, calls canvas.resize_event.
>
>  Here is some test code
>
>      from pylab import figure, connect, show
>      fig = figure()
>      def resize(event):
>          print 'resize canvas', event.width, event.height
>
>      connect('resize_event', resize)
>      show()
>
>  Checking in lib/matplotlib/backend_bases.py;
>  /cvsroot/matplotlib/matplotlib/lib/matplotlib/backend_bases.py,v  <-- 
> backend_bases.py
>  new revision: 1.69; previous revision: 1.68
>
>  Thanks!
>  JDH
>
>

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

On 10/7/05, Robert Kern <rk...@uc...> wrote:
>
> John Hunter wrote:
> >>>>>>"Paul" =3D=3D Paul Barrett <peb...@gm...> writes:
> >
> > Paul> I have data that has error bars and upper limits. (Actually
> > Paul> they are lower limits, since the Y axis is in stellar
> > Paul> magnitudes and is inverted.) My suggestion is use a negative
> > Paul> error value to indicate a limit in which case an arrow would
> > Paul> be drawn, instead of an error bar. This feature would only
> > Paul> apply to the case of asymmetric error bars and not to the
> > Paul> symmetric case. I can produce a patch if this suggestion is
> > Paul> agreeable.
> >
> > I certainly don't have a problem with this and would be happy to
> > include these extensions to the errorbar function. I wonder if the
> > arrow is the best indicator for a limit, though I can't think of a
> > better one at the moment. Also, does this handle limits in either
> > direction (up or down) as well as left to right?
>
> Arrows are often used to indicate error bars which end outside of the
> displayed area of the plot. I would also recommend against using
> negative error values to indicate limits instead of errors. It smells of
> FORTRAN. :-)


Yes, it does smell of FORTRAN. However, my motive for suggesting negative
error values is that it allows the user to specify the length of the limit
arrow and numeric arrays to be used for input. The other option would be to
use a string, e.g.'limit(2)', as a marker. This will complicate the
implementation, but that is less of a concern to me than usability. I think
that the ability to specify the length of the arrow is needed. This could b=
e
an optional parameter though. I'm open to suggestions.

Limits should probably be implemented by a separate
> object/function/whatever.
>

In astronomy, limit data is often associated with data having large error
bars, i.e. they go hand-in-hand. So, a separate function would essentially
duplicate the error bar functionality. I see no need for this duplicity.

-- Paul

On 10/7/05, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Paul" =3D=3D Paul Barrett <peb...@gm...> writes:
>
> Paul> I have data that has error bars and upper limits. (Actually
> Paul> they are lower limits, since the Y axis is in stellar
> Paul> magnitudes and is inverted.) My suggestion is use a negative
> Paul> error value to indicate a limit in which case an arrow would
> Paul> be drawn, instead of an error bar. This feature would only
> Paul> apply to the case of asymmetric error bars and not to the
> Paul> symmetric case. I can produce a patch if this suggestion is
> Paul> agreeable.
>
> I certainly don't have a problem with this and would be happy to
> include these extensions to the errorbar function. I wonder if the
> arrow is the best indicator for a limit, though I can't think of a
> better one at the moment. Also, does this handle limits in either
> direction (up or down) as well as left to right?
>

Yes, a negative value for the upper error bar will indicate an upper limit
and vice versa for the lower error bar value. The same goes for left and
right limits.

Note that this enhancement will only affect asymmetric error bars and not
symmetric ones, since the latter case doesn't make much sense to me.

-- Paul

>>>>> "Kilian" == Kilian Hagemann <hag...@eg...> writes:

    Kilian> Hmm, I must admit I knew nothing about figures when I
    Kilian> posted. But now that I've done some homework, I see that
    Kilian> using Figure.legend is suboptimal as well because it can
    Kilian> neither resize the axes accordingly nor place outside
    Kilian> legends for each subplot automatically.

Hey Killian,

OK, I am happy to include this because I think the auto-resizing
capability is useful (eg following the colorbar model).  Now that you
are aware of the figure legend, please take a look at your self.parent
handling because parent can be an Axes or a Figure.  You will want to
check for isaxes before calling 

  self.parent.get_position()

and associated functions.

Also, as a matter of style and efficiency, I prefer to avoid multiple
function calls in lines like

    figwidth = self.get_figure().get_figwidth()*float(self.get_figure().get_dpi())
    figheight = self.get_figure().get_figheight()*float(self.get_figure().get_dpi())

rather

 fig = self.get_figure()
 dpi = fig.get_dpi()
 figheight = fig.get_figheight()*dpi
 figwidth = fig.get_figwidth()*dpi


dpi is already a float....

But even more pithily <wink>

  w, h = fig.canvas.get_width_height()

Also, although these aren't written down anywhere (wiki entry needed
so feel free to make one!)  the matplotlib coding conventions are

  classes:  UpperCase
  functions and methods: underscore_separated
  attributes and variables : lower of lowerUpper

so vars like space_needed should be spaceneeded or spaceNeeded.  Ditto
for the fudge_* vars and new_aw and so on.

Finally, I think your patch against your own tree, because it contains
lines like

-      'upper outside right'  : 11,
+      'upper outside right'  : 11, # these only make sense with axes legends


Eg, it is removing things that do not exist in matplotlib CVS -- make
sure you apply diff against mpl CVS and not your own tree !

JDH

>>>>> "Kilian" == Kilian Hagemann <hag...@eg...> writes:

    Kilian> Dear developers, On Monday I sent an email to the
    Kilian> matplotlib-users list
    Kilian> (http://sourceforge.net/mailarchive/forum.php?thread_id=8391378&forum_id=33405)
    Kilian> asking if it was possible to have a 'centered' axis.

    Kilian> As I received no reply and couldn't find any other info, I
    Kilian> assume that this functionality is not present in
    Kilian> matplotlib-0.84. Am I right or is there a way?

Sorry.  I answered this question quite recently in another thread
http://sourceforge.net/mailarchive/message.php?msg_id=13146574 which
shows a hackish way that doesn't give you ticks

    Kilian> Cause if the lines of the x and y axis can only be plotted
    Kilian> on the lower/left edge of the axes/subplot I'd be keen to
    Kilian> enhance the code to make this flexible. Seems like I'd be
    Kilian> targeting axes.py and axis.py, but I'd also have to know
    Kilian> how this is done in Matlab to keep compatibility (I did
    Kilian> Matlab 6 years ago and don't remember anything).

This would be a very nice feature and one I and others have been
wanting for a long time.  axes.py and axis.py are the right modules to
look into.  I don't know how matlab does it; it is a good idea to look
into this for inspiration and API compatibility but we don't need to
follow their implementation slavishly if there is a better one.

I don't think it would be a lot of work to do this.  You will want to
make the edgecolor and facecolor of the axes patch the same as
indicated in the thread above, and the add a Line2D to the XAxis and
YAxis classes, and support placing them at an arbitrary location.  The
only tricky bit is that the axis classes work with some of the darker
matplotlib transformation magic, which is hard for most people to
understand because I do transformations in a nonstandard way.
Nonetheless, they are reasonably well documented in the class
documentation.

I think it would be useful to support multiple axis lines per axes (eg
two y scales).  Chaco makes the axis a line property which is fairly
different from the matplotlib approach but makes it easy to do things
like drag a line from one axes to another with the axis coming along
with it.  Not sure if this is the right approach or not.

Good luck!  Please keep us posted with implementation ideas and feel
free to ask a lot of questions.

JDH

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <peb...@gm...> writes:
> 
>     Paul> I have data that has error bars and upper limits. (Actually
>     Paul> they are lower limits, since the Y axis is in stellar
>     Paul> magnitudes and is inverted.) My suggestion is use a negative
>     Paul> error value to indicate a limit in which case an arrow would
>     Paul> be drawn, instead of an error bar. This feature would only
>     Paul> apply to the case of asymmetric error bars and not to the
>     Paul> symmetric case. I can produce a patch if this suggestion is
>     Paul> agreeable.
> 
> I certainly don't have a problem with this and would be happy to
> include these extensions to the errorbar function.  I wonder if the
> arrow is the best indicator for a limit, though I can't think of a
> better one at the moment.  Also, does this handle limits in either
> direction (up or down) as well as left to right?

Arrows are often used to indicate error bars which end outside of the
displayed area of the plot. I would also recommend against using
negative error values to indicate limits instead of errors. It smells of
FORTRAN.  :-)

Limits should probably be implemented by a separate
object/function/whatever.

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

>>>>> "Paul" == Paul Barrett <peb...@gm...> writes:

    Paul> I have data that has error bars and upper limits. (Actually
    Paul> they are lower limits, since the Y axis is in stellar
    Paul> magnitudes and is inverted.) My suggestion is use a negative
    Paul> error value to indicate a limit in which case an arrow would
    Paul> be drawn, instead of an error bar. This feature would only
    Paul> apply to the case of asymmetric error bars and not to the
    Paul> symmetric case. I can produce a patch if this suggestion is
    Paul> agreeable.

I certainly don't have a problem with this and would be happy to
include these extensions to the errorbar function.  I wonder if the
arrow is the best indicator for a limit, though I can't think of a
better one at the moment.  Also, does this handle limits in either
direction (up or down) as well as left to right?

JDH

Dear developers,

On Monday I sent an email to the matplotlib-users list 
(http://sourceforge.net/mailarchive/forum.php?thread_id=8391378&forum_id=33405)
asking if it was possible to have a 'centered' axis.

As I received no reply and couldn't find any other info, I assume that this 
functionality is not present in matplotlib-0.84. Am I right or is there a 
way?

Cause if the lines of the x and y axis can only be plotted on the lower/left 
edge of the axes/subplot I'd be keen to enhance the code to make this 
flexible. Seems like I'd be targeting axes.py and axis.py, but I'd also have 
to know how this is done in Matlab to keep compatibility (I did Matlab 6 
years ago and don't remember anything).

-- 
Kilian Hagemann

Climate Systems Analysis Group
University of Cape Town
Republic of South Africa
Tel(w): ++27 21 650 2748

On Thursday 06 October 2005 23:52, you pondered:
>
> Are you aware of Figure.legend, which is designed to do what you
> describe (place a legend outside the axes). 

Hmm, I must admit I knew nothing about figures when I posted. But now that 
I've done some homework, I see that using Figure.legend is suboptimal as well 
because it can neither resize the axes accordingly nor place outside legends 
for each subplot automatically.

> See also 
> examples/figlegend_demo.py.  I don't think your patch made it through
> (at least I couldn't read it) but if there are extra features you need
> (like auto-resizing the axes) I think these will be best placed in
> Figure.legend.

Somehow my patch got truncated. Here it is again. I still think that 
legends.py is the place to have the resizing code as in this way you can do 
it with arbitrary number of subplots & layouts. In figure.py I would imagine 
this to be difficult with arbitrary number of axes.

Oh, by the way there was a request sometime ago for an automated way to place 
legends outside:

http://sourceforge.net/mailarchive/message.php?msg_id=11106725

Have a look at the patch and tell me what you think.

-- 
Kilian Hagemann

Climate Systems Analysis Group
University of Cape Town
Republic of South Africa
Tel(w): ++27 21 650 2748

>>>>> "Kilian" == Kilian Hagemann <hag...@eg...> writes:

    Kilian> Oh, and please bear with me, this is the first time I've
    Kilian> contributed a meaningful patch to an open source project.

Are you aware of Figure.legend, which is designed to do what you
describe (place a legend outside the axes).  See also
examples/figlegend_demo.py.  I don't think your patch made it through
(at least I couldn't read it) but if there are extra features you need
(like auto-resizing the axes) I think these will be best placed in
Figure.legend.

  http://matplotlib.sourceforge.net/matplotlib.figure.html#Figure-legend

Thanks!
JDH

Hi there,

I recently discovered matplotlib after there were some things that good old 
gnuplot couldn't do, and quickly came to some of matplotlib's limitations. 
But since it's written in python which is my favorite language :-) I hacked 
together the attached patch.

It basically implements legend placement outside right of the axes. This means 
three new options for the loc parameter in Legend's constructor:  'upper 
outside right', 'center outside right' and 'lower outside right', 
corresponding to codes 11-13. I didn't bother to have legends left, below or 
above the plot.

One problem that I immediately came across was fitting the legend next to the 
subplot. I thus made the legend resize the axes by default so that it fits 
neatly next to it. This necessitates a small change in the drawing algorithm 
in the Axes class as the axes need to be resized before they're drawn, and 
the legend must be drawn *after* the axes. The whole thing works pretty well 
in what I've tested so far, but can be turned off by using resize_axes=False, 
a new keyword for Legend's constructor.

Further, the 'best' location now checks all possible inside locations and if 
it doesn't find a perfect spot puts it 'center outside right' instead of at 
the least problematic place.

Finally I cleaned up some redundant code in legend.py and two minor bugs, one 
related to error checking of the loc parameter, the other to near-perfect 
legend positioning in case it's frame uses a non-standard linewidth.

Bugs and caveats: Don't try to resize the axes when resize_axes is on. In my 
scripts this seems to make no difference, but in gtk's interactive resizing 
function this gives unexpected results.

Any chance of incorporating this enhancement in the next release?

Oh, and please bear with me, this is the first time I've contributed a 
meaningful patch to an open source project.

Regards,

-- 
Kilian Hagemann

Climate Systems Analysis Group
University of Cape Town
Republic of South Africa
Tel(w): ++27 21 650 2748

I have data that has error bars and upper limits. (Actually they are lower
limits, since the Y axis is in stellar magnitudes and is inverted.) My
suggestion is use a negative error value to indicate a limit in which case
an arrow would be drawn, instead of an error bar. This feature would only
apply to the case of asymmetric error bars and not to the symmetric case. I
can produce a patch if this suggestion is agreeable.

-- Paul

Hi John,

Attached is the Axes.xaxis_date(), yaxis_date() patch.

I implemented the suggestions you made, including the extra keyword args 
to plot_date().

I was happy to see the date_ticker_factory() function was so similar to 
what I'd implemented on my own.  Great minds think alike, I guess.

Cheers,

Michael

On Mon, 3 Oct 2005, John Hunter wrote:

>>>>>> "Michael" writes:
>
>    Michael> Hi John, I've been making spacecraft trajectory "Pork
>    Michael> Chop Plots", a contour plot of a z-value (such amount of
>    Michael> fuel required) over a range of Earth departure date
>    Michael> x-values and Mars arrival date y-values.
>
>    Michael> Since I needed dates on both x and y axes, it was useful
>    Michael> for me to factor out the date locator/formatter selection
>    Michael> code from plot_date() into two Axes methods: xaxis_date()
>    Michael> and yaxis_date().
>
>    Michael> The plot_date() implementation then becomes just a call
>    Michael> to plot() followed by a call to xaxis_date().
>
> I think this is a good idea.  A few suggestions
>
> matplotlib 0.84 / CVS already has the guts of plot_date factored out
> in date_ticker_factory
>
>  locator, formatter = date_ticker_factory(span, tz)
>
> which appears to be the same thing as your chooseDateFmt.  So you'll
> want to use that instead.  Note also that matplotlib naming
> conventions for functions and methods is lower case and underscore
> separated.
>
> I think it would be useful to add the following kwargs to plot_date to
> support your funcitonality
>
>
>    def plot_date(self, d, y, fmt='bo', tz=None,
>                  xdate=True, ydate=False, **kwargs):
>
>    Michael> My current implementation is below.  Is this
>    Michael> general-purpose enough for me to submit?  If so, I'll
>    Michael> make up some diff files and mail them in.
>
> Yep, with the changes above this would be great.
>
> Thanks!
> JDH
>

-- 
========================================================================
  Michael Brady                                      Phone: 818-354-4957
  Jet Propulsion Laboratory (M/S 301-140L)
  4800 Oak Grove Drive
  Pasadena, CA  91109
========================================================================

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> Should matplotlib have turned itself into a widget library
    Steve> / GUI toolkit?  I know that for a long time John resisted
    Steve> the temptation to add widgets to matplotlib and wanted
    Steve> matplotlib to focus on being a plotting library. I agree
    Steve> with this view and think the danger now is that matplotlib
    Steve> will become too big and bloated and harder to install (like
    Steve> the old SciPy?).

Hey Steve, 

If I'm not mistaken, the complexity of the core matplotlib build has
not changed in quite a while -- basically we've required zlib, png,
freetype and C++ since 0.5.  Yes, some backends require additional
complexity (eg GTKAgg, the new WXAgg blit functionality) but you can
simply turn these options off in setup.py if you don't need them; in
the next few weeks I'm going to try and replace _gtkagg with pure
python using python buffers.  All of the changes to support blitting,
widgets and so on have either been pure python or changes to existing
extension code (eg _backend_agg.cpp and _gtkagg.cpp).  Also, the size
of the widgets module, which seems to bother you, is miniscule

  > wc lib/matplotlib/widgets.py
  985  3004 32510 lib/matplotlib/widgets.py

I don't want mpl to become a widget library.  I did want to add some
support for controlling the subplot parameters, a very frequent gripe.
I could have say "dear backend maintainers, please add these sliders
and buttons to make this tool" and we would still be waiting.  

I don't think any of the backends other than GTK* which I added have
implemented the resize functionality I requested on Sept 14th.  That
doesn't really bother me too much, because I know people are busy with
other projects, but to the extent that I can get low level
functionality that lets the frontend do these things, I and others can
can roll out functionality that benefits almost all users much more
efficiently.  I implemented sliders and buttons because I needed them.
They are pure python, took me less than a day, do something useful,
work out of the box across backends, and make up a small fraction of
the total code size.  Looks like a win-win to me.

I implemented other widgets as an afterthought the same day as proof
of concept, with the thought that if someone wants to make a
*matplotlib tool* if they did it using the matplotlib widgets and
events it would immediately be available to everyone.  Most GUI work
in python cannot be shared because it is tk specific, wx specific and
so on, and I wanted to find a way around this problem.

    Steve> I would prefer to see a 'matplotlib-core' which is a
    Steve> minimal module that focuses purely on plotting
    Steve> graphs. Other optional modules (like 'matplotlib-toolkits',
    Steve> 'matplotlib-widgets', etc) could then extend
    Steve> 'matplotlib-core' by providing extra features.

I think the distinction between plotting and interacting with your
plot is not so clear.  Sure, some small fraction of mpl users just
generate static graphs, but the majority I would guess actually use
things like matplotlib Events regularly (ie every time they use the
pan/zoom tools).  Should these be addons, or part of the core?

I'm not opposed to this kind of packaging if it were done right (eg if
everyone had something roughly equivalent to debian's apt.  I think
the vast majority of users want something that "just works".  Nadia
has been working on pulling all of the non-matplotlib dependencies out
of the tree (CXX, Agg, png, zlib, pytz, dateutil) and revamping the
build system to grab a tarball off the internet if a configure system
doesn't detect them.  This would make matplotlib CVS and the src
distro much ligher, which I'm sure all the developers who regularly do
CVS checkouts will appreciate since the damned pytz directories take
forever.  This will definitely be a step in the right direction,
especially if we can get it to work across platforms.

As far as widgets are concerned, I don' think they can be placed in
an optional toolkit because the subplot tool requires them.  At under
1000 lines of pure python, I also don't see the motivation.  Contrast
this with basemap, which is over 10MB with lots of extension code.  Or
would you like to see the toolbar and all of it's functionality rolled
into an option addon?

JDH

John Hunter wrote:

>>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes:
>>>>>>            
>>>>>>
>
>    Jeff> Anyone know how the default axes rectangle is set?  The
>    Jeff> default width and height are apparently not the same
>
>    >>>> from pylab import * ax=axes() ax.get_position()
>    Jeff> [0.125, 0.099999999999999978, 0.77500000000000002,
>    Jeff> 0.80000000000000004]
>
>
>    Jeff> I'd like the last two numbers to be identical (say 0.8),
>    Jeff> that way I can be sure that a plot will have a certain
>    Jeff> aspect ratio if the figure dimensions have that aspect
>    Jeff> ratio.
>
>If no args are passed to axes, a subplot(111) is created.  If you want
>to control the rectangle, just pass in the l,b,w,h args
>
>  ax = axes([0.1, 0.1, 0.8, 0.8])
>
>If you want to see how the default subplots are created, see
>axes.Subplot and the subplot params
>
>    left  	: 0.125  # the left side of the subplots of the figure
>    right 	: 0.9    # the right side of the subplots of the figure
>    bottom 	: 0.1    # the bottom of the subplots of the figure
>    top 	: 0.9    # the top of the subplots of the figure
>    wspace 	: 0.2    # the amount of width reserved for blank space between subplots
>    hspace 	: 0.2    # the amount of height reserved for white space between subplots        
>
>JDH
>
>PS: thanks for the basemap notes -- I presented them at scipy and
>there appeared to be a fair amount of interest in it.
>  
>
John:  Thanks - I knew about setting the rect manually, but I didn't 
know the defaults were in subplot.params.  I want to override those 
defaults in basemap so that the width and height are both 0.8 (they are 
0.775 and 0.8 now).  That way the map will  have the right aspect ratio 
without the user having to set the axes rect manually.  I've set it up 
so that rcParams['subplot.params.left'] is set to 0.1 when basemap is 
imported (a warning is printed notifying the user that the defaults have 
been changed, and rcdefaults() can be used to get the old ones back).

Thanks a lot for presenting that material at SciPy - I've noticed an 
upswing in downloads since your talk.

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/CDC  R/CDC1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

>>>>> "Michael" == Michael Brady <mb...@jp...> writes:

    Michael> Hi John, I've been making spacecraft trajectory "Pork
    Michael> Chop Plots", a contour plot of a z-value (such amount of
    Michael> fuel required) over a range of Earth departure date
    Michael> x-values and Mars arrival date y-values.

    Michael> Since I needed dates on both x and y axes, it was useful
    Michael> for me to factor out the date locator/formatter selection
    Michael> code from plot_date() into two Axes methods: xaxis_date()
    Michael> and yaxis_date().

    Michael> The plot_date() implementation then becomes just a call
    Michael> to plot() followed by a call to xaxis_date().

I think this is a good idea.  A few suggestions

matplotlib 0.84 / CVS already has the guts of plot_date factored out
in date_ticker_factory

  locator, formatter = date_ticker_factory(span, tz)

which appears to be the same thing as your chooseDateFmt.  So you'll
want to use that instead.  Note also that matplotlib naming
conventions for functions and methods is lower case and underscore
separated.

I think it would be useful to add the following kwargs to plot_date to
support your funcitonality


    def plot_date(self, d, y, fmt='bo', tz=None, 
                  xdate=True, ydate=False, **kwargs):

    Michael> My current implementation is below.  Is this
    Michael> general-purpose enough for me to submit?  If so, I'll
    Michael> make up some diff files and mail them in.

Yep, with the changes above this would be great.

Thanks!
JDH

>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:

    Jeff> Anyone know how the default axes rectangle is set?  The
    Jeff> default width and height are apparently not the same

    >>>> from pylab import * ax=axes() ax.get_position()
    Jeff> [0.125, 0.099999999999999978, 0.77500000000000002,
    Jeff> 0.80000000000000004]


    Jeff> I'd like the last two numbers to be identical (say 0.8),
    Jeff> that way I can be sure that a plot will have a certain
    Jeff> aspect ratio if the figure dimensions have that aspect
    Jeff> ratio.

If no args are passed to axes, a subplot(111) is created.  If you want
to control the rectangle, just pass in the l,b,w,h args

  ax = axes([0.1, 0.1, 0.8, 0.8])

If you want to see how the default subplots are created, see
axes.Subplot and the subplot params

    left  	: 0.125  # the left side of the subplots of the figure
    right 	: 0.9    # the right side of the subplots of the figure
    bottom 	: 0.1    # the bottom of the subplots of the figure
    top 	: 0.9    # the top of the subplots of the figure
    wspace 	: 0.2    # the amount of width reserved for blank space between subplots
    hspace 	: 0.2    # the amount of height reserved for white space between subplots        

JDH

PS: thanks for the basemap notes -- I presented them at scipy and
there appeared to be a fair amount of interest in it.

Anyone know how the default axes rectangle is set?  The default width 
and height are apparently not the same

 >>> from pylab import *
 >>> ax=axes()
 >>> ax.get_position()
[0.125, 0.099999999999999978, 0.77500000000000002, 0.80000000000000004]


I'd like the last two numbers to be identical (say 0.8), that way I can 
be sure that a plot will have a certain aspect ratio if the figure 
dimensions have that aspect ratio.

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/CDC1        FAX   : (303)497-6449
325 Broadway                Web   : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Hi John,

I've been making spacecraft trajectory "Pork Chop Plots", a contour plot 
of a z-value (such amount of fuel required) over a range of Earth 
departure date x-values and Mars arrival date y-values.

Since I needed dates on both x and y axes, it was useful for me to factor 
out the date locator/formatter selection code from plot_date() into two 
Axes methods:  xaxis_date() and yaxis_date().

The plot_date() implementation then becomes just a call to plot() followed 
by a call to xaxis_date().

My current implementation is below.  Is this general-purpose enough for me 
to submit?  If so, I'll make up some diff files and mail them in.

Thanks,

Michael

#===========================================================================
def xaxis_date(self, tz=None):
   """Choose date ticks and labels for the x-axis.

   = INPUT VARIABLES
   - tz         The timezone to use in plotting the dates.
                Defaults to rc value.
   """

   span  = self.dataLim.intervalx().span()
   locator, formatter = self.chooseDateFmt( span, tz )
   self.xaxis.set_major_locator(locator)
   self.xaxis.set_major_formatter(formatter)

#===========================================================================
def yaxis_date(self, tz=None):
   """Choose date ticks and labels for the y-axis.

   = INPUT VARIABLES
   - tz         The timezone to use in plotting the dates.
                Defaults to rc value.
"""

   span  = self.dataLim.intervaly().span()
   locator, formatter = self.chooseDateFmt( span, tz )
   self.yaxis.set_major_locator(locator)
   self.yaxis.set_major_formatter(formatter)

#===========================================================================
def chooseDateFmt(self, span, tz=None):
   """Chooses an appropriate date formatter and tick locator for a span.

   = INPUT VARIABLES
   - span       The span of the plot data.
   - tz         The timezone to use in plotting the dates.
                Defaults to rc value.

   = RETURN VALUE
   - A tuple of ( locator, formatter ) for the input span.
   """

   # The code below was copied from Axes.plot_date().

   if span==0:
      span = SEC_PER_HOUR

   minutes = span*24*60
   hours  = span*24
   days   = span
   weeks  = span/7.
   months = span/31. # approx
   years  = span/365.

   numticks = 5
   if years>numticks:
       locator = YearLocator(int(years/numticks), tz=tz)  # define
       fmt = '%Y'
   elif months>numticks:
       locator = MonthLocator(tz=tz)
       fmt = '%b %Y'
   elif weeks>numticks:
       locator = WeekdayLocator(tz=tz)
       fmt = '%a, %b %d'
   elif days>numticks:
       locator = DayLocator(interval=math.ceil(days/numticks), tz=tz)
       fmt = '%b %d'
   elif hours>numticks:
       locator = HourLocator(interval=math.ceil(hours/numticks), tz=tz)
       fmt = '%H:%M\n%b %d'
   elif minutes>numticks:
       locator = MinuteLocator(interval=math.ceil(minutes/numticks), tz=tz)
       fmt = '%H:%M:%S'
   else:
       locator = MinuteLocator(tz=tz)
       fmt = '%H:%M:%S'

   formatter = DateFormatter(fmt, tz=tz)

   return locator, formatter


========================================================================
  Michael Brady                                      Phone: 818-354-4957
  Jet Propulsion Laboratory (M/S 301-140L)             Fax: 818-393-6388
  4800 Oak Grove Drive
  Pasadena, CA  91109                 E-mail: Mic...@jp...
========================================================================