matplotlib-users Mailing List for matplotlib

Hello,
my problem is described very quickly:
The package is installed. In the interpreter the 'import matplotlib' 
does not throw an error. On the other hand I tried to use matplotlib 
in a python script and here the very same command provokes the 
following error message:
Traceback (most recent call last):
 File "./account3.py", line 13, in <module>
 import matplotlib
ImportError: No module named matplotlib
I would be greatful for any help/explanaiton.
Cheers,
Felix
$ uname -aDarwin mac-screening-1 9.8.0 Darwin Kernel Version 9.8.0: 
Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228154~1/RELEASE_I386 i386
$ python
Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
$ python -c 'import matplotlib; print matplotlib.__version__, 
matplotlib.__file__'
0.99.0 /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ 
site-packages/matplotlib/__init__.pyc
The Package was downloaded from the link:
http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/matplotlib-0.99.1.1-py2.5-macosx10.5.dmg/download

On Mon, Sep 28, 2009 at 16:53, Jae-Joon Lee <lee...@gm...> wrote:
> I personally think that a box, whose height has a physical meaning (in
> data coordinate) while its width does not, is not a good
> representation of your data. A vertical line or something like
> errorbar seems to be more suitable to me.
I agree, and if you're a fan of Edward Tufte, then you definitely
agree. In his book, he takes the simple Tukey-style boxplot and turns
it into a 1-dimension object, in line with the type of data it's
representing. However, I still want to implement something that's a
bit more traditional, which is why I wanted to pick an arbitrary width
for the boxes that stay invariant regardless of the scale that I use.
> As Mike has explained, the transform trick (blended or not) won't
> work. The width and y-center will be always transformed with the same
> transform, which is not what you want. I think you need to create a
> custom patch class for this to work. One option seems to subclass the
> Rectangle class and overide the _update_patch_transform method. The
> patch transform is used to transform a unit rectangle to a rectangle
> in data coordinate (or whatever coordinate the patch uses), i.e., you
> need to calculate the coordinate of the box in the data coordinate(or
> whatever coordinate the patch uses).
Could you possibly explain exactly what is going on and how this
structurally differs from the approach that Mike posted?
In Mike's code, he uses BboxTransformTo using the box he created in
display coords. So this takes a unit square and spits out the box
that I specify when I instantiate the custom patch (using data coords
for x and y and axes coords for w). What is called to actually draw
the box (i.e., when I execute plt.draw())? Is that get_path()? So
basically, whenever MPL wants to draw a patch, does it always call
get_path() and then runs it through whatever is returned from
get_transform() to get the final shape in display coords?
So how does this relate to the strategy that you are advocating? Is
_update_patch_transform somehow a synonym for what I described in the
paragraph above? I don't know where that fits into the picture.
It may be useful to add something to the "Working With Tranformations"
section or the "Transformation Tutorial" about what is minimally
necessary to override for a custom patch. I have been playing around
with MPL for some time now (albeit I don't have much computer
visualization/graphics experience) and still have only a fuzzy idea of
what order things are called in and what the overall
strategy/structure of the system is like.
Uri
>
> -JJ
>
>> Uri
>>
>>>
>>> Mike
>>>
>>> Eric Firing wrote:
>>>>
>>>> Uri Laserson wrote:
>>>>
>>>>>
>>>>> Is it possible to specify a path object that will use different
>>>>> transforms for different vertices?
>>>>>
>>>>> This is again related to plotting a box whose height is specified by
>>>>> data coords, but whose width is a constant in axes coords regardless
>>>>> of scale (so linear and log x-scales would produce a box of the same
>>>>> width).
>>>>>
>>>>> Ideally, I would draw a path like this:
>>>>> 1. the center of the box would be located at x and bottom and top
>>>>> would be y1, y2, all in data coords
>>>>> 2. I would move to (x,y1) at the bottom-center of the box.
>>>>> 3. The x value would now need to be converted to Axes coords, possibly
>>>>> by applying transData + transAxes.inverted
>>>>> 4. I would want to draw a line to (x-0.1, y1) where x is now in axes
>>>>> coords and y is still in data coords. Then up, then right, then down,
>>>>> and then close the polygon.
>>>>>
>>>>> How do I implement this?
>>>>>
>>>>
>>>> I must be missing something, because I still don't see why you can't do
>>>> all this very simply by using a PolyCollection, with the vertices in axes
>>>> coordinates and the offset in data coordinates.
>>>>
>>>> Eric
>>>>
>>>>
>>>>>
>>>>> As I mentioned before, a blended transform would allow me to make the
>>>>> moves i am interested in. However, a change of scale would change the
>>>>> correspondence between data and axes coords, so the axes transform
>>>>> part of the blended axes would have to be recomputed everytime the
>>>>> scale changes based on where the (x,y1) point lands in the axes. Is
>>>>> this correct?
>>>>>
>>>>> Any suggestions are welcome...thanks!
>>>>>
>>>>> Uri
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>>>> is the only developer event you need to attend this year. Jumpstart your
>>>> developing skills, take BlackBerry mobile applications to market and stay
>>>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>>>> http://p.sf.net/sfu/devconf
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>
>>
>>
>> --
>> Uri Laserson
>> PhD Candidate, Biomedical Engineering
>> Harvard Medical School (Genetics)
>> Massachusetts Institute of Technology (Mathematics)
>> phone +1 917 742 8019
>> las...@mi...
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
-- 
Uri Laserson
PhD Candidate, Biomedical Engineering
Harvard Medical School (Genetics)
Massachusetts Institute of Technology (Mathematics)
phone +1 917 742 8019
las...@mi...

Hi Mike,
This is definitely on the right track. Thanks a lot for writing it
out. When I change the view limits, indeed the width stays constant
while the height gets rescaled. However, when I try to change to a
logarithmic axis, I get the following errors. Again, excuse my
ignorance, but I am not sure where exactly the offense is and how to
fix it.
In [57]: ax.set_xscale('log')
In [58]: plt.draw()
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (568, 0))
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (568, 0))
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (568, 0))
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
/Users/laserson/Desktop/<ipython console> in <module>()
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/pyplot.pyc
in draw()
 348 def draw():
 349 'redraw the current figure'
--> 350 get_current_fig_manager().canvas.draw()
 351
 352 @docstring.copy_dedent(Figure.savefig)
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.pyc
in draw(self)
 213
 214 def draw(self):
--> 215 FigureCanvasAgg.draw(self)
 216 tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
 217 self._master.update_idletasks()
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/backends/backend_agg.pyc
in draw(self)
 376
 377 self.renderer = self.get_renderer()
--> 378 self.figure.draw(self.renderer)
 379
 380 def get_renderer(self):
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/artist.pyc
in draw_wrapper(artist, renderer, *kl)
 53 def draw_wrapper(artist, renderer, *kl):
 54 before(artist, renderer)
---> 55 draw(artist, renderer, *kl)
 56 after(artist, renderer)
 57
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/figure.pyc
in draw(self, renderer)
 770
 771 # render the axes
--> 772 for a in self.axes: a.draw(renderer)
 773
 774 # render the figure text
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/artist.pyc
in draw_wrapper(artist, renderer, *kl)
 53 def draw_wrapper(artist, renderer, *kl):
 54 before(artist, renderer)
---> 55 draw(artist, renderer, *kl)
 56 after(artist, renderer)
 57
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/axes.pyc
in draw(self, renderer, inframe)
 1743
 1744 for zorder, i, a in dsu:
-> 1745 a.draw(renderer)
 1746
 1747 renderer.close_group('axes')
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/artist.pyc
in draw_wrapper(artist, renderer, *kl)
 53 def draw_wrapper(artist, renderer, *kl):
 54 before(artist, renderer)
---> 55 draw(artist, renderer, *kl)
 56 after(artist, renderer)
 57
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/patches.pyc
in draw(self, renderer)
 353
 354 path = self.get_path()
--> 355 transform = self.get_transform()
 356 tpath = transform.transform_path_non_affine(path)
 357 affine = transform.get_affine()
/Users/laserson/Desktop/testMyPatch.py in get_transform(self)
 22 box = [[self.x, self.y1],
 23 [self.x, self.y2]]
---> 24 box = self.axes.transData.transform(box)
 25
 26 # Get the width as a fraction of the axes width
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/transforms.pyc
in transform(self, points)
 1893 def transform(self, points):
 1894 return self._b.transform(
-> 1895 self._a.transform(points))
 1896 transform.__doc__ = Transform.transform.__doc__
 1897
/Library/Frameworks/Python.framework/Versions/4.3.0/lib/python2.5/site-packages/matplotlib/transforms.pyc
in transform(self, points)
 1721 x_points = x.transform(points)[:, 0:1]
 1722 else:
-> 1723 x_points = x.transform(points[:, 0])
 1724 x_points = x_points.reshape((len(x_points), 1))
 1725
TypeError: list indices must be integers
On Mon, Sep 28, 2009 at 16:56, Michael Droettboom <md...@st...> wrote:
> Is the attached sort of what you want? It defines a custom rectangle by (x,
> w, y1, y2) and overrides the get_transform of the patch to update itself at
> draw time.
>
> Mike
>
> Uri Laserson wrote:
>>
>> On Mon, Sep 28, 2009 at 16:03, Michael Droettboom <md...@st...> wrote:
>>
>>>
>>> If I understand correctly, the top and bottom of the box are in data
>>> coordinates, the x-center of the box is in data coordinates, only the
>>> width
>>> of the box is in axes coordinates. Is that correct? If so, a
>>>
>>
>> That's exactly correct.
>>
>>
>>>
>>> PolyCollection won't be able to do this (directly), since that would
>>> require
>>> both the width and height to be in axes coordinates.
>>>
>>
>> In principle, could you use a blended tranform for that? Eitherway, I
>> don't think it would work, because the patch objects would be drawn to
>> specific Axes coords. If the scale is changed (e.g, by switching to
>> log scale), then what would prompt the Axes coords to be recalculated?
>> I was thinking earlier that I could compose the transData and
>> transAxes.inverse transforms to recalculate where the new Axes coord
>> should be, but Mike thought this approach would fail (though I'm still
>> not exactly sure why, no doubt because of my own ignorance).
>>
>> Uri
>>
>>
>>>
>>> Mike
>>>
>>> Eric Firing wrote:
>>>
>>>>
>>>> Uri Laserson wrote:
>>>>
>>>>
>>>>>
>>>>> Is it possible to specify a path object that will use different
>>>>> transforms for different vertices?
>>>>>
>>>>> This is again related to plotting a box whose height is specified by
>>>>> data coords, but whose width is a constant in axes coords regardless
>>>>> of scale (so linear and log x-scales would produce a box of the same
>>>>> width).
>>>>>
>>>>> Ideally, I would draw a path like this:
>>>>> 1. the center of the box would be located at x and bottom and top
>>>>> would be y1, y2, all in data coords
>>>>> 2. I would move to (x,y1) at the bottom-center of the box.
>>>>> 3. The x value would now need to be converted to Axes coords, possibly
>>>>> by applying transData + transAxes.inverted
>>>>> 4. I would want to draw a line to (x-0.1, y1) where x is now in axes
>>>>> coords and y is still in data coords. Then up, then right, then down,
>>>>> and then close the polygon.
>>>>>
>>>>> How do I implement this?
>>>>>
>>>>>
>>>>
>>>> I must be missing something, because I still don't see why you can't do
>>>> all this very simply by using a PolyCollection, with the vertices in
>>>> axes
>>>> coordinates and the offset in data coordinates.
>>>>
>>>> Eric
>>>>
>>>>
>>>>
>>>>>
>>>>> As I mentioned before, a blended transform would allow me to make the
>>>>> moves i am interested in. However, a change of scale would change the
>>>>> correspondence between data and axes coords, so the axes transform
>>>>> part of the blended axes would have to be recomputed everytime the
>>>>> scale changes based on where the (x,y1) point lands in the axes. Is
>>>>> this correct?
>>>>>
>>>>> Any suggestions are welcome...thanks!
>>>>>
>>>>> Uri
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>>>> is the only developer event you need to attend this year. Jumpstart your
>>>> developing skills, take BlackBerry mobile applications to market and
>>>> stay
>>>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>>>> now&#33;
>>>> http://p.sf.net/sfu/devconf
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>>
>>
>>
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
> import numpy as np
> import matplotlib.pyplot as plt
> import matplotlib.patches as mpatches
> import matplotlib.transforms as mtransforms
> import matplotlib.path as mpath
>
> class MyBox(mpatches.Patch):
>
>  def __init__(self, x, w, y1, y2, **kwargs):
>   self.x = x
>   self.w = w
>   self.y1 = y1
>   self.y2 = y2
>   mpatches.Patch.__init__(self, **kwargs)
>
>  def get_path(self):
>   return mpath.Path.unit_rectangle()
>
>  def get_transform(self):
>
>   # Transform the data-relative values
>   box = [[self.x, self.y1],
>       [self.x, self.y2]]
>   box = self.axes.transData.transform(box)
>
>   # Get the width as a fraction of the axes width
>   w = self.w * self.axes.bbox.width / 2.0
>
>   # Add it to the data-transformed coordinates
>   box[0][0] -= w
>   box[1][0] += w
>
>   return mtransforms.BboxTransformTo(mtransforms.Bbox(box))
>
> fig = plt.figure()
> ax = fig.add_subplot(111)
> patch = MyBox(0, 0.1, 0.5, 1.5)
> ax.add_patch(patch)
> ax.set_xlim((-1, 1))
> ax.set_ylim((0, 2))
>
> plt.show()
>
>
-- 
Uri Laserson
PhD Candidate, Biomedical Engineering
Harvard Medical School (Genetics)
Massachusetts Institute of Technology (Mathematics)
phone +1 917 742 8019
las...@mi...

Hmm, I'm afraid that this only works if you use preview mode. I
haven't tested, but I guess it will fail without it. Check if
rcParams["text.latex.preview"]==True.
-JJ
On Mon, Sep 28, 2009 at 6:26 PM, Jae-Joon Lee <lee...@gm...> wrote:
> You need an empty mbox at the end of line (\mbox{}).
>
> text(xlim()[1],1.02,r'$r^2$~~~\mbox{}',horizontalalignment='right')
>
> If you did mean \; after ^, it requires {}.
>
> Again, these only works if you use real TeX for text rendering (ie
> usetex=True), not the mpl's mathtext mode.
>
> Regards,
>
> -JJ
>
>
> On Mon, Sep 28, 2009 at 5:48 PM, Christopher Barrington-Leigh
> <cpb...@gm...> wrote:
>>
>> All my attempts at using TeX spacing failed too. What do you have in mind?
>>
>> e.g.
>> text(xlim()[1],1.02,r'$r^\;2$~~~',horizontalalignment='right')
>>
>>
>> Jae-Joon Lee wrote:
>>>
>>> While I think you're not using usetex mode, you may use tex's own
>>> spacing command with usetex mode. Depending on your need, you may also
>>> use the annotate function with which you can provide a spacing in
>>> pixel coordinate (or other coordinate the annotate supports).
>>>
>>
>> --
>> View this message in context: http://www.nabble.com/trailing-space-in-text-string-stripped%2C-making-it-impossible-to-right-pad-my-text-tp25639703p25653573.html
>> Sent from the matplotlib - users mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>

You need an empty mbox at the end of line (\mbox{}).
text(xlim()[1],1.02,r'$r^2$~~~\mbox{}',horizontalalignment='right')
If you did mean \; after ^, it requires {}.
Again, these only works if you use real TeX for text rendering (ie
usetex=True), not the mpl's mathtext mode.
Regards,
-JJ
On Mon, Sep 28, 2009 at 5:48 PM, Christopher Barrington-Leigh
<cpb...@gm...> wrote:
>
> All my attempts at using TeX spacing failed too. What do you have in mind?
>
> e.g.
> text(xlim()[1],1.02,r'$r^\;2$~~~',horizontalalignment='right')
>
>
> Jae-Joon Lee wrote:
>>
>> While I think you're not using usetex mode, you may use tex's own
>> spacing command with usetex mode. Depending on your need, you may also
>> use the annotate function with which you can provide a spacing in
>> pixel coordinate (or other coordinate the annotate supports).
>>
>
> --
> View this message in context: http://www.nabble.com/trailing-space-in-text-string-stripped%2C-making-it-impossible-to-right-pad-my-text-tp25639703p25653573.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Greetings,
I would like to plot to make a figure with 3 subplots
of the form (221) to (223):
 - each subplot should show a bar3d plot of a matrix
 - each subplot should have it's own title
The problems:
 a) I don't see (nor did i find something) how i can
 use subplots combined with bar3d (from the mpl_toolkits.mplot3d)
 package.
 b) I don't manage to give the 3d bar plot a title. In the attached
 code you will see that a title is set, but it does not show
 up in the figure
Could someone please help me out with these problems?
Thanks,
q
---------------------
The code for the basic plot of the matrix:
from mpl_toolkits.mplot3d import Axes3D
import matplotlib.pyplot as plt
from matplotlib.ticker import FixedFormatter, LinearLocator, FixedLocator
from numpy import *
psi=1/sqrt(2)*array([1, 0, 0, 1])
rho=outer(psi,psi)
fig = plt.figure()
ax = Axes3D(fig)
elements = (len(rho) * len(rho))
xpos, ypos = meshgrid(array(range(len(rho)))+0.25, array(range(len(rho)))+0.25)
xpos = xpos.flatten()
ypos = ypos.flatten()
zpos = zeros(elements)
dx = 0.5 * ones_like(zpos)
dy = dx.copy()
dz = absolute(rho.flatten())
ax.set_title('absolute')
ax.bar3d(xpos, ypos, zpos, dx, dy, dz, color='#F8F800')
plt.show()

On Mon, Sep 28, 2009 at 4:54 PM, Jeff Whitaker <js...@fa...> wrote:
> Ryan May wrote:
>>
>> Jeff,
>>
>> Right now, for me, any Basemap example that uses colorbar() is broken
>> for me. I think there's a problem with how Basemap sets the current
>> 'image' so that a colorbar can be automatically generated for plots.
>> The code currently does:
>>
>>  plt.gci._current = ret
>>
>> I think the current image handling in matplotlib itself was reworked
>> (at least according to SVN logs, r7494), so that now instead there's a
>> setter function:
>>
>>  plt.sci(ret)
>>
>> I'd be happy fix these myself if you're too busy.
>>
>> Ryan
>>
>>
>
> Ryan: I'm off to Australia for a conference tomorrow, so if you could fix
> that I'd be grateful. I wonder if we shouldn't wrap the old
> plt.gci._current = ret in a try/except, and use the new way if an Attribute
> Error is raised. That way, it will still work with old versions of
> matplotlib.
Trying both sounds like a good idea, since I just noticed this change
is only in SVN trunk, and not in the 0.99.x series (which is probably
why no one noticed). However, no attribute error is raised when
setting the attribute, it's just never used. I'll see if I can come
up with something similar that will work.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

Ryan May wrote:
> Jeff,
>
> Right now, for me, any Basemap example that uses colorbar() is broken
> for me. I think there's a problem with how Basemap sets the current
> 'image' so that a colorbar can be automatically generated for plots.
> The code currently does:
>
> plt.gci._current = ret
>
> I think the current image handling in matplotlib itself was reworked
> (at least according to SVN logs, r7494), so that now instead there's a
> setter function:
>
> plt.sci(ret)
>
> I'd be happy fix these myself if you're too busy.
>
> Ryan
>
> 
Ryan: I'm off to Australia for a conference tomorrow, so if you could 
fix that I'd be grateful. I wonder if we shouldn't wrap the old 
plt.gci._current = ret in a try/except, and use the new way if an 
Attribute Error is raised. That way, it will still work with old 
versions of matplotlib.
Thanks for catching this.
-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

Jeff,
Right now, for me, any Basemap example that uses colorbar() is broken
for me. I think there's a problem with how Basemap sets the current
'image' so that a colorbar can be automatically generated for plots.
The code currently does:
 plt.gci._current = ret
I think the current image handling in matplotlib itself was reworked
(at least according to SVN logs, r7494), so that now instead there's a
setter function:
 plt.sci(ret)
I'd be happy fix these myself if you're too busy.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

All my attempts at using TeX spacing failed too. What do you have in mind?
e.g.
text(xlim()[1],1.02,r'$r^\;2$~~~',horizontalalignment='right') 
Jae-Joon Lee wrote:
> 
> While I think you're not using usetex mode, you may use tex's own
> spacing command with usetex mode. Depending on your need, you may also
> use the annotate function with which you can provide a spacing in
> pixel coordinate (or other coordinate the annotate supports).
> 
-- 
View this message in context: http://www.nabble.com/trailing-space-in-text-string-stripped%2C-making-it-impossible-to-right-pad-my-text-tp25639703p25653573.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Thanks. Unfortunately this gives me the same results: no good. Something is
stripping whatever filler is there on the right.
text(xlim()[1],1.01,'string'.ljust(10,' '),horizontalalignment='right')
John [H2O] wrote:
> 
> 
> 
> Christopher Barrington-Leigh wrote:
>> 
>> Hello. My problem is as follows:
>> (ipython --pylab)
>> 
>> from pylab import *
>> pp=plot([0,0],[1,1])
>> text(xlim()[0],1,' Need padding ',horizontalalignment='left')
>> text(xlim()[1],1,' Need padding ',horizontalalignment='right')
>> 
>> 
>> The second case does not do what I want, which is to pad the text on the
>> right. Text strings are stripped on the right, but no on the left. How
>> can I elegantly create a character of space?
>> 
>> Thanks!
>> c
>> 
> 
> Untested, but I think you could do this with just python builtin types:
> 
> from pylab import *
> pp=plot([0,0],[1,1])
> text(xlim()[0],1,'string'.ljust(10,' '))
> text(xlim()[1],1,'string'.rjust(10,' '))
> 
> See the documention:
> http://docs.python.org/library/stdtypes.html
> 
> str.ljust(width[, fillchar])¶
> 
> Return the string left justified in a string of length width. Padding is
> done using the specified fillchar (default is a space). The original
> string is returned if width is less than len(s).
> 
> Changed in version 2.4: Support for the fillchar argument.
> 
> 
> 
-- 
View this message in context: http://www.nabble.com/trailing-space-in-text-string-stripped%2C-making-it-impossible-to-right-pad-my-text-tp25639703p25653331.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Thanks. Unfortunately this gives me the same results: no good. Something is
stripping whatever filler is there on the right.
text(xlim()[1],1.01,'string'.ljust(10,' '),horizontalalignment='right')
John [H2O] wrote:
> 
> Untested, but I think you could do this with just python builtin types:
> 
> from pylab import *
> pp=plot([0,0],[1,1])
> text(xlim()[0],1,'string'.ljust(10,' '))
> text(xlim()[1],1,'string'.rjust(10,' '))
> 
> See the documention:
> http://docs.python.org/library/stdtypes.html
> 
> str.ljust(width[, fillchar])¶
> 
> Return the string left justified in a string of length width. Padding is
> done using the specified fillchar (default is a space). The original
> string is returned if width is less than len(s).
> 
> Changed in version 2.4: Support for the fillchar argument.
> 
> 
> 
-- 
View this message in context: http://www.nabble.com/trailing-space-in-text-string-stripped%2C-making-it-impossible-to-right-pad-my-text-tp25639703p25653325.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

I can confirm this with latest svn. I take a quick look at the code,
but couldn't figure where the stripping happens and I hope other
experts to step in.
While I think you're not using usetex mode, you may use tex's own
spacing command with usetex mode. Depending on your need, you may also
use the annotate function with which you can provide a spacing in
pixel coordinate (or other coordinate the annotate supports).
Regards,
-JJ
On Sun, Sep 27, 2009 at 9:57 PM, Christopher Barrington-Leigh
<cpb...@gm...> wrote:
>
> Hello. My problem is as follows:
> (ipython --pylab)
>
> from pylab import *
> pp=plot([0,0],[1,1])
> text(xlim()[0],1,'  Need padding  ',horizontalalignment='left')
> text(xlim()[1],1,'  Need padding  ',horizontalalignment='right')
>
>
> The second case does not do what I want, which is to pad the text on the
> right. Text strings are stripped on the right, but no on the left. How can I
> elegantly create a character of space?
>
> Thanks!
> c
> --
> View this message in context: http://www.nabble.com/trailing-space-in-text-string-stripped%2C-making-it-impossible-to-right-pad-my-text-tp25639703p25639703.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Ralph Kube-2 wrote:
> 
> 
> Is there an 
> easy way out?
> 
> 
Well, you could just script it and create .png files.... I do it all the
time.
-- 
View this message in context: http://www.nabble.com/Update-a-contour-plot-tp25648878p25653140.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Christopher Barrington-Leigh wrote:
> 
> Hello. My problem is as follows:
> (ipython --pylab)
> 
> from pylab import *
> pp=plot([0,0],[1,1])
> text(xlim()[0],1,' Need padding ',horizontalalignment='left')
> text(xlim()[1],1,' Need padding ',horizontalalignment='right')
> 
> 
> The second case does not do what I want, which is to pad the text on the
> right. Text strings are stripped on the right, but no on the left. How can
> I elegantly create a character of space?
> 
> Thanks!
> c
> 
Untested, but I think you could do this with just python builtin types:
from pylab import *
pp=plot([0,0],[1,1])
text(xlim()[0],1,'string'.ljust(10,' '))
text(xlim()[1],1,'string'.rjust(10,' '))
See the documention:
http://docs.python.org/library/stdtypes.html
str.ljust(width[, fillchar])¶
Return the string left justified in a string of length width. Padding is
done using the specified fillchar (default is a space). The original string
is returned if width is less than len(s).
Changed in version 2.4: Support for the fillchar argument.
-- 
View this message in context: http://www.nabble.com/trailing-space-in-text-string-stripped%2C-making-it-impossible-to-right-pad-my-text-tp25639703p25653102.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Is the attached sort of what you want? It defines a custom rectangle by 
(x, w, y1, y2) and overrides the get_transform of the patch to update 
itself at draw time.
Mike
Uri Laserson wrote:
> On Mon, Sep 28, 2009 at 16:03, Michael Droettboom <md...@st...> wrote:
> 
>> If I understand correctly, the top and bottom of the box are in data
>> coordinates, the x-center of the box is in data coordinates, only the width
>> of the box is in axes coordinates. Is that correct? If so, a
>> 
>
> That's exactly correct.
>
> 
>> PolyCollection won't be able to do this (directly), since that would require
>> both the width and height to be in axes coordinates.
>> 
>
> In principle, could you use a blended tranform for that? Eitherway, I
> don't think it would work, because the patch objects would be drawn to
> specific Axes coords. If the scale is changed (e.g, by switching to
> log scale), then what would prompt the Axes coords to be recalculated?
> I was thinking earlier that I could compose the transData and
> transAxes.inverse transforms to recalculate where the new Axes coord
> should be, but Mike thought this approach would fail (though I'm still
> not exactly sure why, no doubt because of my own ignorance).
>
> Uri
>
> 
>> Mike
>>
>> Eric Firing wrote:
>> 
>>> Uri Laserson wrote:
>>>
>>> 
>>>> Is it possible to specify a path object that will use different
>>>> transforms for different vertices?
>>>>
>>>> This is again related to plotting a box whose height is specified by
>>>> data coords, but whose width is a constant in axes coords regardless
>>>> of scale (so linear and log x-scales would produce a box of the same
>>>> width).
>>>>
>>>> Ideally, I would draw a path like this:
>>>> 1. the center of the box would be located at x and bottom and top
>>>> would be y1, y2, all in data coords
>>>> 2. I would move to (x,y1) at the bottom-center of the box.
>>>> 3. The x value would now need to be converted to Axes coords, possibly
>>>> by applying transData + transAxes.inverted
>>>> 4. I would want to draw a line to (x-0.1, y1) where x is now in axes
>>>> coords and y is still in data coords. Then up, then right, then down,
>>>> and then close the polygon.
>>>>
>>>> How do I implement this?
>>>>
>>>> 
>>> I must be missing something, because I still don't see why you can't do
>>> all this very simply by using a PolyCollection, with the vertices in axes
>>> coordinates and the offset in data coordinates.
>>>
>>> Eric
>>>
>>>
>>> 
>>>> As I mentioned before, a blended transform would allow me to make the
>>>> moves i am interested in. However, a change of scale would change the
>>>> correspondence between data and axes coords, so the axes transform
>>>> part of the blended axes would have to be recomputed everytime the
>>>> scale changes based on where the (x,y1) point lands in the axes. Is
>>>> this correct?
>>>>
>>>> Any suggestions are welcome...thanks!
>>>>
>>>> Uri
>>>>
>>>>
>>>>
>>>> 
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>>> http://p.sf.net/sfu/devconf
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>> 
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> 
>
>
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Sep 28, 2009 at 4:15 PM, Uri Laserson <las...@mi...> wrote:
> On Mon, Sep 28, 2009 at 16:03, Michael Droettboom <md...@st...> wrote:
>> If I understand correctly, the top and bottom of the box are in data
>> coordinates, the x-center of the box is in data coordinates, only the width
>> of the box is in axes coordinates. Is that correct? If so, a
>
> That's exactly correct.
>
I personally think that a box, whose height has a physical meaning (in
data coordinate) while its width does not, is not a good
representation of your data. A vertical line or something like
errorbar seems to be more suitable to me.
>> PolyCollection won't be able to do this (directly), since that would require
>> both the width and height to be in axes coordinates.
>
> In principle, could you use a blended tranform for that? Eitherway, I
> don't think it would work, because the patch objects would be drawn to
> specific Axes coords. If the scale is changed (e.g, by switching to
> log scale), then what would prompt the Axes coords to be recalculated?
> I was thinking earlier that I could compose the transData and
> transAxes.inverse transforms to recalculate where the new Axes coord
> should be, but Mike thought this approach would fail (though I'm still
> not exactly sure why, no doubt because of my own ignorance).
>
As Mike has explained, the transform trick (blended or not) won't
work. The width and y-center will be always transformed with the same
transform, which is not what you want. I think you need to create a
custom patch class for this to work. One option seems to subclass the
Rectangle class and overide the _update_patch_transform method. The
patch transform is used to transform a unit rectangle to a rectangle
in data coordinate (or whatever coordinate the patch uses), i.e., you
need to calculate the coordinate of the box in the data coordinate(or
whatever coordinate the patch uses).
-JJ
> Uri
>
>>
>> Mike
>>
>> Eric Firing wrote:
>>>
>>> Uri Laserson wrote:
>>>
>>>>
>>>> Is it possible to specify a path object that will use different
>>>> transforms for different vertices?
>>>>
>>>> This is again related to plotting a box whose height is specified by
>>>> data coords, but whose width is a constant in axes coords regardless
>>>> of scale (so linear and log x-scales would produce a box of the same
>>>> width).
>>>>
>>>> Ideally, I would draw a path like this:
>>>> 1. the center of the box would be located at x and bottom and top
>>>> would be y1, y2, all in data coords
>>>> 2. I would move to (x,y1) at the bottom-center of the box.
>>>> 3. The x value would now need to be converted to Axes coords, possibly
>>>> by applying transData + transAxes.inverted
>>>> 4. I would want to draw a line to (x-0.1, y1) where x is now in axes
>>>> coords and y is still in data coords. Then up, then right, then down,
>>>> and then close the polygon.
>>>>
>>>> How do I implement this?
>>>>
>>>
>>> I must be missing something, because I still don't see why you can't do
>>> all this very simply by using a PolyCollection, with the vertices in axes
>>> coordinates and the offset in data coordinates.
>>>
>>> Eric
>>>
>>>
>>>>
>>>> As I mentioned before, a blended transform would allow me to make the
>>>> moves i am interested in. However, a change of scale would change the
>>>> correspondence between data and axes coords, so the axes transform
>>>> part of the blended axes would have to be recomputed everytime the
>>>> scale changes based on where the (x,y1) point lands in the axes. Is
>>>> this correct?
>>>>
>>>> Any suggestions are welcome...thanks!
>>>>
>>>> Uri
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>>> http://p.sf.net/sfu/devconf
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>
>
>
> --
> Uri Laserson
> PhD Candidate, Biomedical Engineering
> Harvard Medical School (Genetics)
> Massachusetts Institute of Technology (Mathematics)
> phone +1 917 742 8019
> las...@mi...
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Mon, Sep 28, 2009 at 16:03, Michael Droettboom <md...@st...> wrote:
> If I understand correctly, the top and bottom of the box are in data
> coordinates, the x-center of the box is in data coordinates, only the width
> of the box is in axes coordinates. Is that correct? If so, a
That's exactly correct.
> PolyCollection won't be able to do this (directly), since that would require
> both the width and height to be in axes coordinates.
In principle, could you use a blended tranform for that? Eitherway, I
don't think it would work, because the patch objects would be drawn to
specific Axes coords. If the scale is changed (e.g, by switching to
log scale), then what would prompt the Axes coords to be recalculated?
 I was thinking earlier that I could compose the transData and
transAxes.inverse transforms to recalculate where the new Axes coord
should be, but Mike thought this approach would fail (though I'm still
not exactly sure why, no doubt because of my own ignorance).
Uri
>
> Mike
>
> Eric Firing wrote:
>>
>> Uri Laserson wrote:
>>
>>>
>>> Is it possible to specify a path object that will use different
>>> transforms for different vertices?
>>>
>>> This is again related to plotting a box whose height is specified by
>>> data coords, but whose width is a constant in axes coords regardless
>>> of scale (so linear and log x-scales would produce a box of the same
>>> width).
>>>
>>> Ideally, I would draw a path like this:
>>> 1. the center of the box would be located at x and bottom and top
>>> would be y1, y2, all in data coords
>>> 2. I would move to (x,y1) at the bottom-center of the box.
>>> 3. The x value would now need to be converted to Axes coords, possibly
>>> by applying transData + transAxes.inverted
>>> 4. I would want to draw a line to (x-0.1, y1) where x is now in axes
>>> coords and y is still in data coords. Then up, then right, then down,
>>> and then close the polygon.
>>>
>>> How do I implement this?
>>>
>>
>> I must be missing something, because I still don't see why you can't do
>> all this very simply by using a PolyCollection, with the vertices in axes
>> coordinates and the offset in data coordinates.
>>
>> Eric
>>
>>
>>>
>>> As I mentioned before, a blended transform would allow me to make the
>>> moves i am interested in. However, a change of scale would change the
>>> correspondence between data and axes coords, so the axes transform
>>> part of the blended axes would have to be recomputed everytime the
>>> scale changes based on where the (x,y1) point lands in the axes. Is
>>> this correct?
>>>
>>> Any suggestions are welcome...thanks!
>>>
>>> Uri
>>>
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
Uri Laserson
PhD Candidate, Biomedical Engineering
Harvard Medical School (Genetics)
Massachusetts Institute of Technology (Mathematics)
phone +1 917 742 8019
las...@mi...

If I understand correctly, the top and bottom of the box are in data 
coordinates, the x-center of the box is in data coordinates, only the 
width of the box is in axes coordinates. Is that correct? If so, a 
PolyCollection won't be able to do this (directly), since that would 
require both the width and height to be in axes coordinates.
Mike
Eric Firing wrote:
> Uri Laserson wrote:
> 
>> Is it possible to specify a path object that will use different
>> transforms for different vertices?
>>
>> This is again related to plotting a box whose height is specified by
>> data coords, but whose width is a constant in axes coords regardless
>> of scale (so linear and log x-scales would produce a box of the same
>> width).
>>
>> Ideally, I would draw a path like this:
>> 1. the center of the box would be located at x and bottom and top
>> would be y1, y2, all in data coords
>> 2. I would move to (x,y1) at the bottom-center of the box.
>> 3. The x value would now need to be converted to Axes coords, possibly
>> by applying transData + transAxes.inverted
>> 4. I would want to draw a line to (x-0.1, y1) where x is now in axes
>> coords and y is still in data coords. Then up, then right, then down,
>> and then close the polygon.
>>
>> How do I implement this?
>> 
>
> I must be missing something, because I still don't see why you can't do 
> all this very simply by using a PolyCollection, with the vertices in 
> axes coordinates and the offset in data coordinates.
>
> Eric
>
> 
>> As I mentioned before, a blended transform would allow me to make the
>> moves i am interested in. However, a change of scale would change the
>> correspondence between data and axes coords, so the axes transform
>> part of the blended axes would have to be recomputed everytime the
>> scale changes based on where the (x,y1) point lands in the axes. Is
>> this correct?
>>
>> Any suggestions are welcome...thanks!
>>
>> Uri
>>
>>
>> 
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Matthias Michler wrote:
> Hi Ralph,
> 
> I don't think there exists a function like the line-'set_data'-method for 
> collections, which are generated by 'contour'. This particular method of 
> lines only changes the data but leave anything else unchanged.
> I attached an easy approach of updating a contour plot (simply deleting old 
> collections), but I'm not sure that this is the best solution.
I don't think you area gaining anything at all by manually deleting the 
collections. Better to just clear the axes, or clear the figure, and 
make a fresh plot.
Eric
> 
> Kind regards,
> Matthias
> 
> On Monday 28 September 2009 13:52:42 Ralph Kube wrote:
>> Hi,
>> is there a way to update a contour plot? I need to display a series of
>> contour plots from a directory with data files and want to view them
>> consecutively, preferrably without building a gui for it. Is there an
>> easy way out?
>>
>> Cheers, Ralph
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Uri Laserson wrote:
> Is it possible to specify a path object that will use different
> transforms for different vertices?
> 
> This is again related to plotting a box whose height is specified by
> data coords, but whose width is a constant in axes coords regardless
> of scale (so linear and log x-scales would produce a box of the same
> width).
> 
> Ideally, I would draw a path like this:
> 1. the center of the box would be located at x and bottom and top
> would be y1, y2, all in data coords
> 2. I would move to (x,y1) at the bottom-center of the box.
> 3. The x value would now need to be converted to Axes coords, possibly
> by applying transData + transAxes.inverted
> 4. I would want to draw a line to (x-0.1, y1) where x is now in axes
> coords and y is still in data coords. Then up, then right, then down,
> and then close the polygon.
> 
> How do I implement this?
I must be missing something, because I still don't see why you can't do 
all this very simply by using a PolyCollection, with the vertices in 
axes coordinates and the offset in data coordinates.
Eric
> 
> As I mentioned before, a blended transform would allow me to make the
> moves i am interested in. However, a change of scale would change the
> correspondence between data and axes coords, so the axes transform
> part of the blended axes would have to be recomputed everytime the
> scale changes based on where the (x,y1) point lands in the axes. Is
> this correct?
> 
> Any suggestions are welcome...thanks!
> 
> Uri
> 
> 

I don't think the transformations framework is going to be of much help 
for automating this. You seem to be suggesting an x-axis where the 
center is in data coords and the width is in axes coords. Once you've 
added the two together, it will be impossible to separate them.
I think the path of least resistance will be for you to create a new 
artist class and override the draw method, such that you can do all the 
necessary calculations based on the current values of the axes and data 
transforms on every draw.
There's an example of creating a custom artist in 
api/line_with_text.py... Then it's just writing a draw method to do 
what you need to do -- you should be able to get at the axes 
transformations through self.axes.transAxes and self.axes.transData. 
I'm a bit busy today to really work that through, but hopefully that's 
enough to get you started.
Mike
Uri Laserson wrote:
> Is it possible to specify a path object that will use different
> transforms for different vertices?
>
> This is again related to plotting a box whose height is specified by
> data coords, but whose width is a constant in axes coords regardless
> of scale (so linear and log x-scales would produce a box of the same
> width).
>
> Ideally, I would draw a path like this:
> 1. the center of the box would be located at x and bottom and top
> would be y1, y2, all in data coords
> 2. I would move to (x,y1) at the bottom-center of the box.
> 3. The x value would now need to be converted to Axes coords, possibly
> by applying transData + transAxes.inverted
> 4. I would want to draw a line to (x-0.1, y1) where x is now in axes
> coords and y is still in data coords. Then up, then right, then down,
> and then close the polygon.
>
> How do I implement this?
>
> As I mentioned before, a blended transform would allow me to make the
> moves i am interested in. However, a change of scale would change the
> correspondence between data and axes coords, so the axes transform
> part of the blended axes would have to be recomputed everytime the
> scale changes based on where the (x,y1) point lands in the axes. Is
> this correct?
>
> Any suggestions are welcome...thanks!
>
> Uri
>
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm trying to 'automate' a few components within basemap. I have a pretty
complicated, and assuredly poorly written, set of functions that allow me to
'dynamically' plot a grid of data (lon,lat).
Here is one section where I try to deal with transforming the data based on
the projection. 'data' is a grid, often of size 720x360 or 720x180,
representing full globe or hemisphere at 0.5 degree resolution. 'outlon0',
outlat0', and 'd*out' are the llcrnr coordinates and step. 'transform' is an
option, that is set to True by default:
1680 ## set up transformations for the data array 
1681 if m.projection not in ['cyl','merc','mill']:
1682 lats = np.arange( outlat0, ( outlat0 + ( numygrid*dyout ) ),
dyout )[:-1]
1683 lons = np.arange( outlon0, ( outlon0 + ( numxgrid*dxout ) ),
dxout )[:-1]
1684 data = data[:-1,:-1]
1685 else:
1686 lats = np.arange( outlat0, ( outlat0 + ( numygrid*dyout ) ),
dyout )
1687 lons = np.arange( outlon0, ( outlon0 + ( numxgrid*dxout ) ),
dxout )
1688 
1689 ## transform to nx x ny regularly spaced native projection grid
1690 if transform:
1691 dx = 2.*np.pi*m.rmajor/len(lons)
1692 nx = int((m.xmax-m.xmin)/dx)+1; ny = int((m.ymax-m.ymin)/dx)+1
1693 if nx is 1:
1694 topodat = data
1695 else:
1696 topodat = m.transform_scalar(data,lons,lats,nx,ny)
1697 else:
1698 topodat = data
The problem is, when I use the approach with a 'cyl' grid, then subsequently
try to draw the lsmask, I get a failure. Is this approach incorrect? I had
to use the if nx is 1 statement because it was crashing with zero division
error in some cases.
Thanks.
-- 
View this message in context: http://www.nabble.com/basemap%2C-transform_scalar-question-tp25649437p25649437.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

There is
On Sun, Sep 27, 2009 at 8:49 PM, Gökhan Sever <gok...@gm...> wrote:
>
>
> On Sun, Sep 27, 2009 at 7:44 PM, Jae-Joon Lee <lee...@gm...>wrote:
>
>> On Sun, Sep 27, 2009 at 4:18 PM, Gökhan Sever <gok...@gm...>
>> wrote:
>> > When I run this as it is, and zoom once the top x-axis ticklabels
>> disappear:
>> > http://img2.imageshack.us/img2/5493/zoom1.png
>> >
>> > After commenting these three lines:
>> >
>> > #locator = MinuteLocator(interval=1)
>> > #locator = SecondLocator(interval=30)
>> > #par2.xaxis.set_major_locator(locator)
>> >
>> > and running I get somewhat nice view after zooms:
>> > http://img340.imageshack.us/img340/6632/zoom2.png
>> >
>> > with a minute discrepancy; resulting with shifts on the top x-labels.
>> >
>> > Any last thoughts?
>> >
>>
>> I believe that this is due to wrong tick locations. As you easily
>> guess, the default tick locators are not suitable for datetime ticks
>> and this is why we have separate locators. Please take a look at
>> documentations.
>>
>> http://matplotlib.sourceforge.net/api/dates_api.html
>>
>> If you want to have locator that works for several zoom levels, you
>> may try AutoDateLocator.
>>
>>
>> from matplotlib.dates import DateFormatter, MinuteLocator,
>> SecondLocator, AutoDateLocator, AutoDateFormatter
>> locator = AutoDateLocator()
>> par2.xaxis.set_major_locator(locator)
>> formatter=AutoDateFormatter(locator)
>> par2.xaxis.set_major_formatter(formatter)
>>
>> par2.axis["top"].major_ticklabels.set(rotation=30,
>> ha="left",
>> va="bottom")
>>
>>
>> While the AutoLocator seems to give too may ticks in my opinion, I
>> think this is as far as I can help.
>>
>> Regards,
>>
>> -JJ
>>
>
> Yep, thanks. That gives so many ticks indeed. Would be nicer to see labels
> in every other tick.
>
> This said,
>
> locator = SecondLocator(interval=20)
> par2.xaxis.set_major_locator(locator)
> par2.xaxis.set_major_formatter(DateFormatter('%H:%M:%S'))
>
> satisfies my initial thoughts. With some pan and zoom I can achieve what I
> want.
>
> Attaching the final modified file. I think this is a good demonstrative
> example. It is up to you further put the script into the axes_grid examples.
>
> Thanks again for your efforts.
>
>
>
There is still issues with this approach. First and foremost it is very slow
when the arrays plotted are big (in my case ~8000 points.)
AutoDateLocator() works fast, however on some zoomings the top axis is
filled with labels. This needs to be addressed.
Could anyone help me to see the flow of the AutoDateLocator() class'
updates? It only behaves weird on some certain zooms, put how is this
updated on the screen is a mystery to me so far. I have Eclipse + PyDev, but
don't know where should I set the breakpoints to analyse this behaviour?
Thanks.
>
>
>
>>
>>
>> > On Sun, Sep 27, 2009 at 2:12 PM, Jae-Joon Lee <lee...@gm...>
>> wrote:
>> >>
>> >> Here it is.
>> >>
>> >> -JJ
>> >>
>> >> On Sun, Sep 27, 2009 at 3:09 PM, Gökhan Sever <gok...@gm...>
>> >> wrote:
>> >> > JJ,
>> >> >
>> >> > Could you please re-attach the code? Apparently, it has been
>> forgotten
>> >> > on
>> >> > your reply.
>> >> >
>> >> > Thanks.
>> >> >
>> >> > On Sun, Sep 27, 2009 at 1:50 PM, Jae-Joon Lee <lee...@gm...>
>> >> > wrote:
>> >> >>
>> >> >> Here is the modified version of your code that works for me.
>> >> >>
>> >> >> 1) If you change trans_aux, you also need to plot your data in an
>> >> >> appropriate coordinate. Your original code did not work because you
>> >> >> scaled the xaxis of the second axes (par) but you were still
>> plotting
>> >> >> the original data, i.e., "time" need to be scaled if you want to
>> plot
>> >> >> it on "par". The code below takes slightly different approach.
>> >> >>
>> >> >> 2) I fount that I was wrong with the factor of 3600. It needs to be
>> >> >> 86400, i.e., a day in seconds. Also, The unit must be larger than 1.
>> >> >> Again, please take a look how datetime unit works.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> -JJ
>> >> >>
>> >> >>
>> >> >> import numpy as np
>> >> >> import matplotlib.pyplot as plt
>> >> >> import matplotlib.transforms as mtransforms
>> >> >> from mpl_toolkits.axes_grid.parasite_axes import SubplotHost
>> >> >>
>> >> >>
>> >> >> # Prepare some random data and time for seconds-from-midnight (sfm)
>> >> >> representation
>> >> >> ydata1 = np.random.random(100) * 1000
>> >> >> ydata2 = np.ones(100) / 2.
>> >> >> time = np.arange(3550, 3650)
>> >> >>
>> >> >>
>> >> >> fig = plt.figure()
>> >> >> host = SubplotHost(fig, 111)
>> >> >> fig.add_subplot(host)
>> >> >>
>> >> >> # This is the heart of the example. We have to scale the axes
>> >> >> correctly.
>> >> >> aux_trans = mtransforms.Affine2D().translate(0., 0.).scale(3600,
>> >> >> ydata1.max())
>> >> >> par = host.twin(aux_trans)
>> >> >>
>> >> >> host.set_xlabel("Time [sfm]")
>> >> >> host.set_ylabel("Random Data 1")
>> >> >> par.set_ylabel("Random Data 2")
>> >> >> par.axis["right"].label.set_visible(True)
>> >> >>
>> >> >> p1, = host.plot(time, ydata1)
>> >> >> p2, = par.plot(time, ydata2)
>> >> >>
>> >> >> host.axis["left"].label.set_color(p1.get_color())
>> >> >> par.axis["right"].label.set_color(p2.get_color())
>> >> >>
>> >> >> host.axis["bottom"].label.set_size(16)
>> >> >> host.axis["left"].label.set_size(16)
>> >> >> par.axis["right"].label.set_size(16)
>> >> >>
>> >> >> # Move the title little upwards so it won't overlap with the
>> ticklabels
>> >> >> title = plt.title("Double time: SFM and HH:MM:SS", fontsize=18)
>> >> >> title.set_position((0.5, 1.05))
>> >> >>
>> >> >> plt.show()
>> >> >>
>> >> >>
>> >> >> On Sun, Sep 27, 2009 at 12:32 PM, Gökhan Sever <
>> gok...@gm...>
>> >> >> wrote:
>> >> >> > Hello,
>> >> >> >
>> >> >> > As was suggested by Jae-Joon, I have simplified the code for
>> easier
>> >> >> > investigation and run. The aim of the script is to have time
>> >> >> > represented
>> >> >> > on
>> >> >> > both bottom and top x-axes, on the bottom in seconds-from-midnight
>> >> >> > (SFM),
>> >> >> > and the top should show as HH:MM:SS, while there is two different
>> >> >> > data
>> >> >> > source being used for y-axes. The code could be seen here or from
>> >> >> >
>> http://code.google.com/p/ccnworks/source/browse/trunk/double_time.py
>> >> >> >
>> >> >> > Currently something wrong with the scaling, since the right y-axis
>> >> >> > data
>> >> >> > is
>> >> >> > missing on the plotting area. Also, sfm hasn't been converted to
>> >> >> > HH:MM:SS.
>> >> >> > adding this:
>> par.xaxis.set_major_formatter(DateFormatter('%H:%M:%S'))
>> >> >> > doesn't remedy the situation as of yet.
>> >> >> >
>> >> >> > All comments are welcome.
>> >> >> >
>> >> >> > ### BEGIN CODE ###
>> >> >> > #!/usr/bin/env python
>> >> >> >
>> >> >> > """
>> >> >> >
>> >> >> > Double time representation. Bottom x-axis shows time in
>> >> >> > seconds-from-midnight
>> >> >> > (sfm) fashion, whereas the top x-axis uses HH:MM:SS
>> representation.
>> >> >> >
>> >> >> > Initially written by Gokhan Sever with helps from Jae-Joon Lee.
>> >> >> >
>> >> >> > Written: 2009年09月27日
>> >> >> >
>> >> >> > """
>> >> >> >
>> >> >> > import numpy as np
>> >> >> > import matplotlib.pyplot as plt
>> >> >> > import matplotlib.transforms as mtransforms
>> >> >> > from mpl_toolkits.axes_grid.parasite_axes import SubplotHost
>> >> >> >
>> >> >> >
>> >> >> > # Prepare some random data and time for seconds-from-midnight
>> (sfm)
>> >> >> > representation
>> >> >> > ydata1 = np.random.random(100) * 1000
>> >> >> > ydata2 = np.ones(100) / 2.
>> >> >> > time = np.arange(3550, 3650)
>> >> >> >
>> >> >> >
>> >> >> > fig = plt.figure()
>> >> >> > host = SubplotHost(fig, 111)
>> >> >> > fig.add_subplot(host)
>> >> >> >
>> >> >> > # This is the heart of the example. We have to scale the axes
>> >> >> > correctly.
>> >> >> > aux_trans = mtransforms.Affine2D().translate(0., 0.).scale(3600,
>> >> >> > ydata1.max())
>> >> >> > par = host.twin(aux_trans)
>> >> >> >
>> >> >> > host.set_xlabel("Time [sfm]")
>> >> >> > host.set_ylabel("Random Data 1")
>> >> >> > par.set_ylabel("Random Data 2")
>> >> >> > par.axis["right"].label.set_visible(True)
>> >> >> >
>> >> >> > p1, = host.plot(time, ydata1)
>> >> >> > p2, = par.plot(time, ydata2)
>> >> >> >
>> >> >> > host.axis["left"].label.set_color(p1.get_color())
>> >> >> > par.axis["right"].label.set_color(p2.get_color())
>> >> >> >
>> >> >> > host.axis["bottom"].label.set_size(16)
>> >> >> > host.axis["left"].label.set_size(16)
>> >> >> > par.axis["right"].label.set_size(16)
>> >> >> >
>> >> >> > # Move the title little upwards so it won't overlap with the
>> >> >> > ticklabels
>> >> >> > title = plt.title("Double time: SFM and HH:MM:SS", fontsize=18)
>> >> >> > title.set_position((0.5, 1.05))
>> >> >> >
>> >> >> > plt.show()
>> >> >> > ### END CODE ###
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Gökhan
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> ------------------------------------------------------------------------------
>> >> >> > Come build with us! The BlackBerry&reg; Developer Conference in
>> SF,
>> >> >> > CA
>> >> >> > is the only developer event you need to attend this year.
>> Jumpstart
>> >> >> > your
>> >> >> > developing skills, take BlackBerry mobile applications to market
>> and
>> >> >> > stay
>> >> >> > ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> >> >> > now&#33;
>> >> >> > http://p.sf.net/sfu/devconf
>> >> >> > _______________________________________________
>> >> >> > Matplotlib-users mailing list
>> >> >> > Mat...@li...
>> >> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Gökhan
>> >> >
>> >
>> >
>> >
>> > --
>> > Gökhan
>> >
>>
>
>
>
> --
> Gökhan
>
-- 
Gökhan

Well, I've been starting working on a pyglet backend but it is 
currently painfully slow mainly because I do not know enough of the 
matplotlib internal machinery to really benefit from it. In the case 
of glumpy, the use of texture object for representing 2d arrays is a 
real speed boost since interpolation/colormap/heightmap is made on the 
GPU.
Concerning matplotlib examples, the use of glumpy should be actually 
two lines of code:
from pylab import *
from glumpy import imshow, show
but I did not package it this way yet (that is easy however).
I guess the main question is whether people are interested in glumpy 
to have a quick & dirty "debug" tool on top of matplotlib or whether 
they prefer a full fledged and fast pyglet/OpenGL backend (which is 
really harder).
Nicolas
On 28 Sep, 2009, at 18:05 , Gökhan Sever wrote:
>
>
> On Mon, Sep 28, 2009 at 9:06 AM, Nicolas Rougier <Nic...@lo... 
> > wrote:
>
> Hi all,
>
> glumpy is a fast OpenGL visualization tool for numpy arrays coded on
> top of pyglet (http://www.pyglet.org/). The package contains many
> demos showing basic usage as well as integration with matplotlib. As a
> reference, the animation script available from matplotlib distribution
> runs at around 500 fps using glumpy instead of 30 fps on my machine.
>
> Package/screenshots/explanations at: http://www.loria.fr/~rougier/coding/glumpy.html
> (it does not require installation so you can run demos from within the
> glumpy directory).
>
>
> Nicolas
> _______________________________________________
> NumPy-Discussion mailing list
> Num...@sc...
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
> Hi Nicolas,
>
> This is technically called OpenGL backend, isn't it? It is nice that 
> integrates with matplotlib, however 300 hundred lines of code indeed 
> a lot of lines for an ordinary user. Do you think this could be 
> further integrated into matplotlib with a wrapper to simplify its 
> usage?
>
>
> -- 
> Gökhan
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart 
> your
> developing skills, take BlackBerry mobile applications to market and 
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register 
> now&#33;
> http://p.sf.net/sfu/devconf_______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users