Re: [matplotlib-devel] patch for adding manual label location selection to clabel
Hi, I am still getting crashes using the WX backend with the latest SVN. For example: In [1]: figure() Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 1092, in _onSize self.draw() File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 892, in draw self.figure.draw(self.renderer) File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line 724, in draw if self.frameon: self.patch.draw(renderer) File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 257, in draw gc = renderer.new_gc() File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 366, in new_gc self.gc = GraphicsContextWx(self.bitmap, self) File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", line 463, in __init__ gfx_ctx = wx.GraphicsContext.Create(dc) : 'module' object has no attribute 'GraphicsContext' It appears that this GraphicsContext either isn't in my version of wxPython or isn't initialized properly. Updating to wxPython 2.8 fixed the problem, but I think that breaks other things on my system (like system tools on Ubuntu that I need to use). For now I will just use 2.8, but I may have to revert. Is supporting wx 2.6 a goal? Cheers, David On Thu, 2008-07-24 at 11:55 -0400, Paul Kienzle wrote: > On Thu, Jul 24, 2008 at 05:14:42PM +0200, David Kaplan wrote: > > Hi, > > > > No, it doesn't appear to work with or without my changes. Also, it > > looks to me like the following code is now misplaced in backend_wx.py: > > > > # Event binding code changed after version 2.5 > > if wx.VERSION_STRING >= '2.5': > > def bind(actor,event,action,**kw): > > actor.Bind(event,action,**kw) > > else: > > def bind(actor,event,action,id=None): > > if id is not None: > > event(actor, id, action) > > else: > > event(actor,action) > > > > It now appears after some functions not in the class. Is this OK? > > This code is not part of any class. Anyway, I moved it to the top > of the file. > > > Also, I noticed that this defines bind, while elsewhere in the class > > self.Bind is used. Is this correct? If so, should these other > > references perhaps take advantage of your abstraction? > > I've committed a change so that all functions now use > > bind(self, wx.EVT, callback, id=id) > > rather than > > if wx.VERSION_STRING >= '2.5': > self.Bind(wx.EVT,callback,id=id) > else: > wx.EVT(self, id, callback) > > I'm not set up to test against wx < 2.5, though given its age > and the small user base of matplotlib wx, I'm not sure that > it is relevant anymore. > > > - Paul > -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] doc warnings
Hi, On Thu, 2008-07-24 at 13:08 -0700, [EMAIL PROTECTED] wrote: > WARNING: > /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py:docstring > of matplotlib.axes.Axes.acorr:36: (ERROR/3) Unexpected indentation. > WARNING: :0: (ERROR/3) Unexpected indentation. > WARNING: > /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py:docstring > of > matplotlib.backend_bases.FigureCanvasBase.start_event_loop_default:15: > (WARNING/2) Literal block expected; none found. > I looked at my doc strings and as far as I can tell, they are identical in format to other functions around them. What does this error mean? Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] ParseFatalException: Expected end of math '$'
Hi all,
Is there a way to use
title(r'$ M= I_3 K=\left[\begin{array}{rrr} 2\,k & -k & 0
\\ -k & 2\,k+p & -(k+p) \\ 0 & -(k+p) &
k+p\end{array}\right]$')
It currently fails with
Exception in Tkinter callback
Traceback (most recent call last):
File
"/data/home/nwagner/local/lib/python2.5/lib-tk/Tkinter.py",
line 1403, in __call__
return self.func(*args)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
line 202, in resize
self.show()
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_tkagg.py",
line 205, in draw
FigureCanvasAgg.draw(self)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
line 261, in draw
self.figure.draw(self.renderer)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/figure.py",
line 759, in draw
for a in self.axes: a.draw(renderer)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/axes.py",
line 1514, in draw
a.draw(renderer)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/text.py",
line 297, in draw
bbox, info = self._get_layout(renderer)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/text.py",
line 197, in _get_layout
line, self._fontproperties,
ismath=self.is_math_text(line))
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py",
line 135, in get_text_width_height_descent
self.mathtext_parser.parse(s, self.dpi, prop)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mathtext.py",
line 2735, in parse
box = self._parser.parse(s, font_output, fontsize,
dpi)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/mathtext.py",
line 2208, in parse
self._expression.parseString(s)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 1048, in parseString
loc, tokens = self._parse( instring, 0 )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 981, in _parseCache
value = self._parseNoCache( instring, loc, doActions,
callPreParse )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 924, in _parseNoCache
loc,tokens = self.parseImpl( instring, preloc,
doActions )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 2559, in parseImpl
return self.expr._parse( instring, loc, doActions,
callPreParse=False )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 981, in _parseCache
value = self._parseNoCache( instring, loc, doActions,
callPreParse )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 924, in _parseNoCache
loc,tokens = self.parseImpl( instring, preloc,
doActions )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 2307, in parseImpl
loc, exprtokens = e._parse( instring, loc, doActions
)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 981, in _parseCache
value = self._parseNoCache( instring, loc, doActions,
callPreParse )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 924, in _parseNoCache
loc,tokens = self.parseImpl( instring, preloc,
doActions )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 2672, in parseImpl
loc, tokens = self.expr._parse( instring, loc,
doActions, callPreParse=False )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 981, in _parseCache
value = self._parseNoCache( instring, loc, doActions,
callPreParse )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 924, in _parseNoCache
loc,tokens = self.parseImpl( instring, preloc,
doActions )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 2307, in parseImpl
loc, exprtokens = e._parse( instring, loc, doActions
)
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 981, in _parseCache
value = self._parseNoCache( instring, loc, doActions,
callPreParse )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 924, in _parseNoCache
loc,tokens = self.parseImpl( instring, preloc,
doActions )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 2416, in parseImpl
ret = e._parse( instring, loc, doActions )
File
"/data/home/nwagner/local/lib/python2.5/site-packages/matplotlib/pyparsing.py",
line 981, in _parseCache
value = self._parseNoC
[matplotlib-devel] differences between twinx and twiny
Hi, I just noticed a bug in twinx/twiny in axes.py. twinx has: ax2 = self.figure.add_axes(self.get_position(True), # sharex=self, frameon=False) while twiny has: ax2 = self.figure.add_axes(self.get_position(True), sharey=self, frameon=False) Therefore twiny will share the y axis, while twinx will not share the x axis. I am not sure what the "desired" behavior is, but one has to be wrong. As the principle use for this is making plots of two curves sharing one axis, but different in the other, I imagine that the twiny behavior is the desired one. If not, then the following doesn't look quite right: from numpy import * from matplotlib.pylab import * x = linspace(0,pi,20) y = sin(x) x2 = x + 0.1 * randn(*x.shape) y2 = 10 + y + 0.1 * randn(*y.shape) a1 = gca() plot(x,y) a2 = twinx() plot(x2,y2, 'o') The pylab_examples/two_scales.py only works because the two curves have identical x values. However, forcing them to share has the undesirable consequence that both x-axes must have the same labels and formatting, producing overlayed labels that are slightly noticeable. I have committed to SVN the change making twinx work like twiny. As an aside, this would not be necessary if there was an easy after the fact way of sharing and unsharing axes (i.e., ax.set_shared_x_axes(ax2)). Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Really minor changes
On Thu, Jul 24, 2008 at 6:12 PM, Tony Yu <[EMAIL PROTECTED]> wrote: > I noticed a couple of really minor typos as shown below: Thanks Tony, committed to 5873 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] auto-rotating text and plotyy
Hi, Attached are two patch sets for you to review and comment on. I am not intending for these to go in this release. One is the beginning of a patch set that lets you choose whether text rotation angle is with respect to screen or axes coordinates. The idea is that you might want text that is properly rotated with respect to some object in a plot (e.g., contours), as opposed to being at some particular angle with respect to screen coordinates. Along the way I added a method to transforms.py that transforms angles at a location. The method included is generic and not at all optimized for simple linear transforms, but it works fairly well. This transform might be useful for other functions (e.g., quiver?). This patch basically works. For example, try the following: plot(arange(5)) th = text(3,3,'abcd',rotation=45,rotationscreen=False) th2 = text(2,2,'ABCD',rotation=45) and then try changing the size of your plot window. 'abcd' doesn't rotate with respect to the line as the window changes size, but 'ABCD' does. There are still some imperfections - the text seems to move above or below the line - I am not sure why this is. Also, I have no idea whether I should be using unitless (self._x,_y) or unitful coordinates (self.convert_(x|y)units) in the transformations. Perhaps someone can enlighten me. It doesn't really matter until one tries non-linear transformations (aka basemap). I also haven't tried to integrate this into TextWithDash. I imagine it can be done, but I wasn't sure it was worth the effort since TextWithDash is mostly used for axes ticks I believe. I am thinking of just forcing rotationscreen to True for this class. Comments? Once these issues are worked out, I would integrate this into contour.py so that windows can be resized without affecting label rotation. The second patch is to pyplot.py to create a plotyy function. This is like a matlab function of the same name that puts two curves with different y ranges on the same x axis. It basically wraps the two_scales.py demo functionality with a bit of extra stuff. I had to use a real hack to change the colors of the y axes. Perhaps someone can think of a better way or perhaps this sub-function should be moved out of plotyy so it can be reused. Also, I couldn't find a way to color the actual y-axis - i.e. the vertical line that is the y-axis. Is there an easy way to do this? Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** Index: lib/matplotlib/text.py === --- lib/matplotlib/text.py (revision 5867) +++ lib/matplotlib/text.py (working copy) @@ -62,6 +62,7 @@ name or fontname string eg, ['Sans' | 'Courier' | 'Helvetica' ...] position (x,y) rotation [ angle in degrees 'vertical' | 'horizontal' +rotationscreen [ True | False ] size or fontsize [ size in points | relative size eg 'smaller', 'x-large' ] style or fontstyle [ 'normal' | 'italic' | 'oblique'] text string @@ -93,6 +94,7 @@ multialignment=None, fontproperties=None, # defaults to FontProperties() rotation=None, + rotationscreen=True, linespacing=None, **kwargs ): @@ -118,6 +120,7 @@ self._horizontalalignment = horizontalalignment self._multialignment = multialignment self._rotation = rotation +self._rotationscreen = rotationscreen self._fontproperties = fontproperties self._bbox = None self._renderer = None @@ -159,6 +162,11 @@ 'return the text angle as float' return get_rotation(self._rotation) # string_or_number -> number +def get_rotationscreen(self): +'''return whether rotation is with respect to screen (True) or +plot coordinate system''' +return self._rotationscreen + def update_from(self, other): 'Copy properties from other to self' Artist.update_from(self, other) @@ -168,6 +176,7 @@ self._horizontalalignment = other._horizontalalignment self._fontproperties = other._fontproperties.copy() self._rotation = other._rotation +self._rotationscreen = other._rotationscreen self._picker = other._picker self._linespacing = other._linespacing @@ -207,8 +216,18 @@ height = ymax-ymin xmax = xmin + width +# Get proper rotation angle +angle = self.get_rotation() +if not self.get_rotationscreen(): +
Re: [matplotlib-devel] doc warnings
On Fri, Jul 25, 2008 at 2:48 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > Hi, > > On Thu, 2008-07-24 at 13:08 -0700, > [EMAIL PROTECTED] wrote: >> WARNING: >> /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/axes.py:docstring >> of matplotlib.axes.Axes.acorr:36: (ERROR/3) Unexpected indentation. >> WARNING: :0: (ERROR/3) Unexpected indentation. >> WARNING: >> /home/jdhunter/dev/lib64/python2.5/site-packages/matplotlib/backend_bases.py:docstring >> of >> matplotlib.backend_bases.FigureCanvasBase.start_event_loop_default:15: >> (WARNING/2) Literal block expected; none found. >> > > I looked at my doc strings and as far as I can tell, they are identical > in format to other functions around them. What does this error mean? The problem is after the double colon in the following block:: This function provides default event loop functionality based on time.sleep that is meant to be used until event loop functions for each of the GUI backends can be written. As such, it throws a deprecated warning. Call signature:: start_event_loop_default(self,timeout=0) you need to indent relative to the line containing the double colon, eg:: Call signature:: start_event_loop_default(self,timeout=0) This call blocks until a callback function triggers stop_event_loop() or *timeout* is reached. If *timeout* is <=0, never timeout. I went ahead and committed this change. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] preparing for 0.98.3 and 0.91.5
Hi John, On Thu, Jul 24, 2008 at 21:17, John Hunter <[EMAIL PROTECTED]> wrote: > I'd like to try and get 98.3 and 91.5 out tomorrow or Saturday -- if > the weekday doesn't work for you Charlie we might do a source release > on Friday or Saturday (for Sandro/debian) and you can get the build As usual, thanks for the huge support to Debian! > Sandro, here is a release candidate tarball for you to test with: > http://matplotlib.sourceforge.net/tmp/matplotlib-0.98.3rc1.tar.gz Thanks! i've just downlaoded: is 55M tarball the real intended size? it seems a little too big... ;) $ du * -hs | grep "[0-9]M" 2.8Magg24 146Mdoc 97M examples 108Mlib And there is a file I can't extract: tar: matplotlib-0.98.3rc1/lib/matplotlib/delaunay/table.csv?s=^VIX: Cannot open: No such file or directory Some cleanup missing? ;) Cheers, Sandro -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] differences between twinx and twiny
On Fri, Jul 25, 2008 at 5:23 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > I have committed to SVN the change making twinx work like twiny. As an > aside, this would not be necessary if there was an easy after the fact > way of sharing and unsharing axes (i.e., ax.set_shared_x_axes(ax2)). Yes, the sharex attr should be set on twinx -- perhaps someone commented this out while debugging and forgot to restore it. I have been known to make this mistake on more than one occasion, so thanks for catching it. As for the duplicated ticklabels, I think we should make the ticklabels invisible for ax2 for tick in ax2.xaxis.get_major_ticks() + ax2.get_minor_ticks(): tick.set_visible(False) Are there any potential problems with this that you can see? Obviously we would want to document and mention it in the CHANGELOG, because it might affect some code that is using the twin axes to configure tick labels, but it should be an easy fix for those users to simply use the original axes and it will get it right in most cases (no duplicate labels or ticks). I agree that being able to set the sharex and sharey after the fact would be useful. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] preparing for 0.98.3 and 0.91.5
On Fri, Jul 25, 2008 at 10:42 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote: > Thanks! i've just downlaoded: is 55M tarball the real intended size? > it seems a little too big... ;) Argg, I forgot to svn clean before I did the sdist. Please try again. http://matplotlib.sourceforge.net/tmp/matplotlib-0.98.3rc1.tar.gz The new file is under 6M JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] doc warnings
On Fri, Jul 25, 2008 at 10:09 AM, John Hunter <[EMAIL PROTECTED]> wrote: > The problem is after the double colon in the following block:: David, I cleaned up a few more of these warnings. I notice on most of the functions you added to cbook, you added call signature lines, in many cases where they are not needed. I want to try and clarify where they are needed. If your function uses *args or **kwargs that pass through, you want to give the user some idea what those are. This is most important in pylab, which pass the args and kwargs through to the equivalent Axes method. Since the pylab docstring just reads *args, **kwargs, we use the Axes method of the same name to show the call signature. In general, you do not need to add these, especially if your function declaration explicitly lists the args and keyword args, so I have removed most of these. Also, I would rather not put the geometry functions in cbook, eg distances_along_curve and path_length and friends. Perhaps we should have some sort of geometry module where all these things live (there are some in mlab as well) but barring that I would rather have math/geometry stuff in mlab and general purpose helpers in cbook. Let's move all those before the release so we don't have to worry about API breakage later. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] auto-rotating text and plotyy
David Kaplan wrote: > The second patch is to pyplot.py to create a plotyy function. This is > like a matlab function of the same name that puts two curves with > different y ranges on the same x axis. It basically wraps the > two_scales.py demo functionality with a bit of extra stuff. I had to > use a real hack to change the colors of the y axes. Perhaps someone can > think of a better way or perhaps this sub-function should be moved out > of plotyy so it can be reused. Also, I couldn't find a way to color the > actual y-axis - i.e. the vertical line that is the y-axis. Is there an > easy way to do this? Do you have an example of how to use this (or at least what the results look like)? I'm having trouble seeing how this differs from twinx. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] contains() tests broken
Hi,
In my attempt to get scroll wheel zooming working for this release I added
support for the scroll wheel to TkAgg, and added support for draw_idle to
the wx backend.
I'm attaching the wheel zoom demonstration code. This is standalone code
which is not yet ready to go into backend_bases. It only supports linear
and log axes. Using transform magic would be better here. Also, colormap
zooming is hacked (I don't know how to determine if the axes contain a
colorbar, and what the corresponding mappable is, so I put a list of
colorbars in the figure).
In the process of developing this code I noticed that a lot of the contains
tests are broken by the new transforms. Try attaching onHilite to the
motion notify event on any canvas --- objects should turn light blue as you
hover over them.
E.g.,
from pylab import plot, gcf, show
plot([1,2,3],[1,5,2])
cvs = gcf().canvas
cvs.mpl_connect('motion_notify_event',cvs.onHilite)
show()
I can fixes the axis hit test. I'm not sure how many other problems there
are, but I'm pretty sure I won't get to them all before next Tuesday.
- Paul
import math
import matplotlib
#matplotlib.use('WxAgg')
#matplotlib.use('TkAgg')
#matplotlib.use('GtkAgg')
import pylab
import matplotlib.colors as colors
def _rescale(lo,hi,step,pt=None,bal=None,scale='linear'):
"""
Rescale (lo,hi) by step, returning the new (lo,hi)
The scaling is centered on pt, with positive values of step
driving lo/hi away from pt and negative values pulling them in.
If bal is given instead of point, it is already in [0,1] coordinates.
This is a helper function for step-based zooming.
"""
# Convert values into the correct scale for a linear transformation
# TODO: use proper scale transformers
if scale=='log':
lo,hi = math.log10(lo),math.log10(hi)
if pt is not None: pt = math.log10(pt)
# Compute delta from axis range * %, or 1-% if percent is negative
if step > 0:
delta = float(hi-lo)*step/100
else:
delta = float(hi-lo)*step/(100-step)
# Add scale factor proportionally to the lo and hi values, preserving the
# point under the mouse
if bal is None:
bal = float(pt-lo)/(hi-lo)
lo = lo - bal*delta
hi = hi + (1-bal)*delta
# Convert transformed values back to the original scale
if scale=='log':
lo,hi = math.pow(10.,lo),math.pow(10.,hi)
return (lo,hi)
def onWheel(event):
"""
Process mouse wheel as zoom events
"""
ax = event.inaxes
try:
step = event.step
except:
if event.button == 'up':
step = 1
else:
step = -1
print "zoom",step
# Ick! Can't tell if the axes contains a colorbar.
if hasattr(event.canvas,'_colorbars') and ax in event.canvas._colorbars:
mappable = event.canvas._colorbars[ax].mappable
# rescale colormap: the axes are already scaled to 0..1,
# so use bal instead of pt for centering
lo,hi = mappable.get_clim()
if isinstance(mappable.norm,colors.LogNorm):
vscale = 'log'
else:
vscale = 'linear'
lo,hi = _rescale(lo,hi,step,bal=event.ydata,scale=vscale)
mappable.set_clim(lo,hi)
elif ax != None:
# Event occurred inside a plotting area
lo,hi = ax.get_xlim()
lo,hi = _rescale(lo,hi,step,pt=event.xdata,scale=ax.get_xscale())
ax.set_xlim((lo,hi))
lo,hi = ax.get_ylim()
lo,hi = _rescale(lo,hi,step,pt=event.ydata,scale=ax.get_yscale())
ax.set_ylim((lo,hi))
else:
# Check if zoom happens in the axes
xdata,ydata = None,None
x,y = event.x,event.y
for ax in event.canvas.figure.get_axes():
if ax.xaxis.contains(event):
xdata,_ = ax.transAxes.inverted().transform_point((x,y))
#print "xaxis",x,"->",xdata
if ax.yaxis.contains(event):
_,ydata = ax.transAxes.inverted().transform_point((x,y))
#print "yaxis",y,"->",ydata
if xdata is not None:
lo,hi = ax.get_xlim()
lo,hi = _rescale(lo,hi,step,bal=xdata,scale=ax.get_xscale())
ax.set_xlim((lo,hi))
if ydata is not None:
lo,hi = ax.get_ylim()
lo,hi = _rescale(lo,hi,step,bal=ydata,scale=ax.get_yscale())
ax.set_ylim((lo,hi))
event.canvas.draw_idle()
def colorbar():
cb = pylab.colorbar()
canvas = pylab.gcf().canvas
if not hasattr(canvas,'_colorbars'):
canvas._colorbars = {}
canvas._colorbars[cb.ax] = cb
pylab.gcf().canvas.mpl_connect('scroll_event',onWheel)
pylab.subplot(211)
pylab.imshow([[1,2,3],[2,1,3]])
colorbar()
pylab.subplot(212)
pylab.loglog([10,100,1000],[100,10,1000])
pylab.show()
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based a
Re: [matplotlib-devel] preparing for 0.98.3 and 0.91.5
On Fri, Jul 25, 2008 at 18:37, John Hunter <[EMAIL PROTECTED]> wrote: > On Fri, Jul 25, 2008 at 10:42 AM, Sandro Tosi <[EMAIL PROTECTED]> wrote: > >> Thanks! i've just downlaoded: is 55M tarball the real intended size? >> it seems a little too big... ;) > > Argg, I forgot to svn clean before I did the sdist. Please try again. > > http://matplotlib.sourceforge.net/tmp/matplotlib-0.98.3rc1.tar.gz > > The new file is under 6M Yeah, much better :) I've updated the package in our trunk and it's building fine. Playing with the generated doc I got an error on "matplotlib.colorbar": " System Message: ERROR/3 (/home/morph/deb/build-area/matplotlib-0.98.3rc1/doc/api/colorbar_api.rst, line 9) Error in "automodule" directive: unknown option: "show-inheritance". .. automodule:: matplotlib.colorbar :members: :undoc-members: :show-inheritance: " Err, I got it for ever API documentation page: is there something wrong on my side? I build doc this way: ( cd doc ; MATPLOTLIBDATA=../lib/matplotlib/mpl-data/ \ PYTHONPATH=../build/lib.$(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)-$(shell dpkg-architecture -qDEB_BUILD_GNU_CPU)-$(DEFPY) ./make.py ) dpkg-architecture calls are needed to identify the directory for the mpl lib code, and all the relative paths are because we build in a chroot, so only minimal packages installation are available. Thanks, Sandro -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs Full Patch
Eric Firing wrote: > John Hunter wrote: >> On Thu, Jul 24, 2008 at 10:00 PM, Ryan May <[EMAIL PROTECTED]> wrote: >> >>> What else is confusing is how that relates to DPI. When I change the >>> figure's dpi, using set_dpi, (and redraw), I get physically *bigger* >>> barbs. >>> To me, if I'm actually specifying pixels, there's no way that they >>> should >>> get bigger when I change the DPI. > > Ryan, I think you are giving the length in points (sort of, because of > the bizarre size kwarg), not pixels. So you are right--the barbs are > not 7 pixels long. The translation from points to pixels for the Agg > backend depends on the dpi, as John says below. Now I know what you were saying, I was too braindead to understand last night. I am drawing in points (or whatever scatter uses for size), because I modeled my code off of scatter. Scatter also uses an Identity Transform() for it's Collection objects (which is where I got the idea). Not coincidentally, it shows a similar issue. While it's not as bad as my barbs issue (for reasons unknown to me), you can change the size of the scatter object relative to the size of the canvas just by changing the dpi passed to savefig. Again, it takes passing in dpi=72 to get a figure to match what's on screen, even though 72 is supposedly what's hard coded. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] improved scroll wheel zooming
Hi,
I commited a fixto the axis contains methods, and now have working scroll
wheel zooming code. I still need to use transforms properly before it can
go into matplotlib, so for now I provide it only for demonstration
purposes.
- Paul
import math
import matplotlib
#matplotlib.use('WxAgg')
#matplotlib.use('TkAgg')
#matplotlib.use('GtkAgg')
import pylab
import matplotlib.colors as colors
def _rescale(lo,hi,step,pt=None,bal=None,scale='linear'):
"""
Rescale (lo,hi) by step, returning the new (lo,hi)
The scaling is centered on pt, with positive values of step
driving lo/hi away from pt and negative values pulling them in.
If bal is given instead of point, it is already in [0,1] coordinates.
This is a helper function for step-based zooming.
"""
# Convert values into the correct scale for a linear transformation
# TODO: use proper scale transformers
if scale=='log':
lo,hi = math.log10(lo),math.log10(hi)
if pt is not None: pt = math.log10(pt)
# Compute delta from axis range * %, or 1-% if percent is negative
if step > 0:
delta = float(hi-lo)*step/100
else:
delta = float(hi-lo)*step/(100-step)
# Add scale factor proportionally to the lo and hi values, preserving the
# point under the mouse
if bal is None:
bal = float(pt-lo)/(hi-lo)
lo = lo - bal*delta
hi = hi + (1-bal)*delta
# Convert transformed values back to the original scale
if scale=='log':
lo,hi = math.pow(10.,lo),math.pow(10.,hi)
return (lo,hi)
def onWheel(event):
"""
Process mouse wheel as zoom events
"""
ax = event.inaxes
# Older versions of matplotlib do not have event.step defined
try:
step = event.step
except:
if event.button == 'up':
step = 1
else:
step = -1
# Find colorbars attached to the canvas.
# FIXME Better way to tell if axes contains colorbar?
colorbars = getattr(event.canvas,'_colorbars',{})
# If in plot, use the xdata, ydata as the center point
# If not in plot, check if we are in a plot axis
if ax == None:
# Event not on plot: check if it happened in an axis
xdata,ydata = None,None
x,y = event.x,event.y
axes = event.canvas.figure.get_axes()
for ax in axes:
inx,_ = ax.xaxis.contains(event)
if inx:
xdata,_ = ax.transData.inverted().transform_point((x,y))
break
iny,_ = ax.yaxis.contains(event)
if iny:
_,ydata = ax.transData.inverted().transform_point((x,y))
break
else:
ax = None
else:
xdata,ydata = event.xdata,event.ydata
if ax in colorbars:
# Colorbar scrolling requires remapping the limits
# Note that xdata,ydata are in 0,1, and so are implicitly the
# balance point in the range of the data vlo,vhi
if colorbars[ax].orientation is 'vertical':
bal = ydata
else:
bal = xdata
# The scroll event may not have occurred in the right direction
if bal is not None:
mappable = colorbars[ax].mappable
if isinstance(mappable.norm,colors.LogNorm):
vscale = 'log'
else:
vscale = 'linear'
vlo,vhi = mappable.get_clim()
vlo,vhi = _rescale(vlo,vhi,step,bal=bal,scale=vscale)
mappable.set_clim(vlo,vhi)
event.canvas.draw_idle()
else:
# Axis scrolling requires remapping the axis limits
if xdata is not None:
lo,hi = ax.get_xlim()
lo,hi = _rescale(lo,hi,step,pt=xdata,scale=ax.get_xscale())
ax.set_xlim((lo,hi))
if ydata is not None:
lo,hi = ax.get_ylim()
lo,hi = _rescale(lo,hi,step,pt=ydata,scale=ax.get_yscale())
ax.set_ylim((lo,hi))
if xdata is not None or ydata is not None:
event.canvas.draw_idle()
def colorbar(*args,**kw):
cb = pylab.colorbar(*args,**kw)
canvas = pylab.gcf().canvas
if not hasattr(canvas,'_colorbars'):
canvas._colorbars = {}
canvas._colorbars[cb.ax] = cb
pylab.gcf().canvas.mpl_connect('scroll_event',onWheel)
pylab.subplot(211)
pylab.imshow([[1,2,3],[2,1,3]])
colorbar(orientation='horizontal')
pylab.subplot(212)
pylab.loglog([10,100,1000],[100,10,1000])
pylab.show()
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/l
Re: [matplotlib-devel] Wind Barbs Full Patch
John Hunter wrote:
> On Thu, Jul 24, 2008 at 10:00 PM, Ryan May <[EMAIL PROTECTED]> wrote:
>
>> What else is confusing is how that relates to DPI. When I change the
>> figure's dpi, using set_dpi, (and redraw), I get physically *bigger* barbs.
>> To me, if I'm actually specifying pixels, there's no way that they should
>> get bigger when I change the DPI.
>
> When you increase the dpi, the canvas gets bigger (inches*dpi equals
> canvas size in pixels). If you are drawing in pixels, and not
> scaling, the barbs should look smaller, since they are a smaller
> proportion of the canvas size. So if this explanation is right, the
> barbs will look smaller with larger dpi.
>
>> Then I also can't figure out what the PS backend is doing. If PS is
>> hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any effect?
>
> ps should be unaffected, but dpi dependent backends will. By setting
> the dpi to be 72, it should make the *other* backend look like the ps
> backend and the ps backend should be unaffected.
Ok, I think I found our problem, at line 859 of backend_ps.py (inside
_print_ps()):
self.figure.set_dpi(72) # Override the dpi kwarg
dpi = kwargs.get("dpi", 72)
The problem here is that while it sets the figure dpi here to 72, it's
using the dpi that's passed in down the chain. Since I don't give it a
dpi explicity, it grabs the default dpi from my matplotlibrc, which has
it set to 300 dpi. So 300 is getting passed down into the chain and I
believe the drawing commands are using 300 dpi. If I change the second
line above to dpi = 72, I get the proper results.
So what's the proper fix in this case, or is this it? It'd probably be
good to get this in for a release.
There were a couple other things I noticed:
1) The canvas.print_figure() method goes to the trouble of saving the
facecolor and edgecolor before resetting them to what's passed in for
purposes of writing out the image. Then later,
backend_ps._print_figure() does the same thing a few calls down the
stack. Is one of these redundant, or is there a reason for the duplication?
2) backend_ps._print_figure() uses the md5 module to create a temporary
filename. This module is deprecated in python 2.5 and removed (I
believe) in 3.0, replaced by hashlib. Is there any opposition to
changing the direct use of md5.md5() to using a try...except to import
md5() from it's proper place?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs Full Patch
On Fri, Jul 25, 2008 at 5:47 PM, Ryan May <[EMAIL PROTECTED]> wrote:
> Ok, I think I found our problem, at line 859 of backend_ps.py (inside
> _print_ps()):
>
>self.figure.set_dpi(72) # Override the dpi kwarg
>dpi = kwargs.get("dpi", 72)
>
> The problem here is that while it sets the figure dpi here to 72, it's using
> the dpi that's passed in down the chain. Since I don't give it a dpi
> explicity, it grabs the default dpi from my matplotlibrc, which has it set
> to 300 dpi. So 300 is getting passed down into the chain and I believe the
> drawing commands are using 300 dpi. If I change the second line above to
> dpi = 72, I get the proper results.
Yes, we definitely need to get this fixed before any release, but we
need to be careful here. I had forgotten that Nicholas Young had
submitted a patch to make the ps backend respect higher resolutions
for embedded images
http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg00353.html
so we cannot simply revert this to 72. I also see the problem you
pointed out in the collections module too. While I don't have a quick
fix at hand, at least we are starting to converge onto where the
problems lie. Note that in the collections module the
IdentityTransform is bit of a red herring in the set_transforms
method, since the collection maintains a list of transforms in
_transforms that incorporates a dpi a draw time so I don't thing the
standard artist transform property is used.
> 2) backend_ps._print_figure() uses the md5 module to create a temporary
> filename. This module is deprecated in python 2.5 and removed (I believe)
> in 3.0, replaced by hashlib. Is there any opposition to changing the direct
> use of md5.md5() to using a try...except to import md5() from it's proper
> place?
I wasn't aware of the deprecation so I don't have any strong opinion,
except that it wold be better if you can find a non-deprecated
equivalent which is python 2.4 and 2.5 compatible.
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] improved scroll wheel zooming
On Fri, Jul 25, 2008 at 5:32 PM, Paul Kienzle <[EMAIL PROTECTED]> wrote: > Hi, > > I commited a fixto the axis contains methods, and now have working scroll > wheel zooming code. I still need to use transforms properly before it can > go into matplotlib, so for now I provide it only for demonstration > purposes. I haven't tested this yet, but on a quick read through I notice. try: step = event.step except: if event.button == 'up': step = 1 else: step = -1 Just a reminder that blanket try/except clauses are forbidden in mpl, so you can either do "except AttributeError" or use "if not hasattr(event, 'step')" JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs Full Patch
Ryan May wrote:
> John Hunter wrote:
>> On Thu, Jul 24, 2008 at 10:00 PM, Ryan May <[EMAIL PROTECTED]> wrote:
>>
>>> What else is confusing is how that relates to DPI. When I change the
>>> figure's dpi, using set_dpi, (and redraw), I get physically *bigger*
>>> barbs.
>>> To me, if I'm actually specifying pixels, there's no way that they
>>> should
>>> get bigger when I change the DPI.
>>
>> When you increase the dpi, the canvas gets bigger (inches*dpi equals
>> canvas size in pixels). If you are drawing in pixels, and not
>> scaling, the barbs should look smaller, since they are a smaller
>> proportion of the canvas size. So if this explanation is right, the
>> barbs will look smaller with larger dpi.
>>
>>> Then I also can't figure out what the PS backend is doing. If PS is
>>> hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any
>>> effect?
>>
>> ps should be unaffected, but dpi dependent backends will. By setting
>> the dpi to be 72, it should make the *other* backend look like the ps
>> backend and the ps backend should be unaffected.
>
> Ok, I think I found our problem, at line 859 of backend_ps.py (inside
> _print_ps()):
>
> self.figure.set_dpi(72) # Override the dpi kwarg
> dpi = kwargs.get("dpi", 72)
>
> The problem here is that while it sets the figure dpi here to 72, it's
> using the dpi that's passed in down the chain. Since I don't give it a
> dpi explicity, it grabs the default dpi from my matplotlibrc, which has
> it set to 300 dpi. So 300 is getting passed down into the chain and I
> believe the drawing commands are using 300 dpi. If I change the second
> line above to dpi = 72, I get the proper results.
>
> So what's the proper fix in this case, or is this it? It'd probably be
> good to get this in for a release.
This is the kind of thing I would want to look at and test *very*
carefully, or know that someone like John or Mike has done so--which
perhaps one of them can do quickly. I have looked at this dpi business
with puzzlement before; I don't have it all straight in my head; and I
would need a chunk of time to review it, which I might get in the next
day or so, but can't guarantee.
It would be nice to not only fix the bug, if such there is, but also
clarify the whole mess for all backends, maybe with some additional
variable names. I think that for pixel backends, there is a single dpi
per rendered figure, so the situation is simple; but for vector backends
(ps, pdf, svg), there are fundamentally two: one that is used for
translating dots to inches as measures of length, and another that sets
the dpi (hence resolution, not size) for raster images that are
contained within the figure. (I don't know where the cairo backend
sits, since it can render either raster or vector file types.)
Another aspect of the problem is that at least for use with vector
backends, specifying lengths in dots is unnatural; and it seems to me
like something to be avoided when possible even for raster backends. I
would argue that pad variables should be in physical or relative units,
where relative could mean relative to the figure size, or to a font em,
for example. Specifying lengths in dots is just asking for trouble
except when the plot is not intended to be scaled; when making a small
png for the web, precise control via lengths in dots may be helpful.
Eric
>
> There were a couple other things I noticed:
>
> 1) The canvas.print_figure() method goes to the trouble of saving the
> facecolor and edgecolor before resetting them to what's passed in for
> purposes of writing out the image. Then later,
> backend_ps._print_figure() does the same thing a few calls down the
> stack. Is one of these redundant, or is there a reason for the
> duplication?
>
> 2) backend_ps._print_figure() uses the md5 module to create a temporary
> filename. This module is deprecated in python 2.5 and removed (I
> believe) in 3.0, replaced by hashlib. Is there any opposition to
> changing the direct use of md5.md5() to using a try...except to import
> md5() from it's proper place?
>
> Ryan
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs Full Patch
John Hunter wrote:
> On Fri, Jul 25, 2008 at 5:47 PM, Ryan May <[EMAIL PROTECTED]> wrote:
>
>> Ok, I think I found our problem, at line 859 of backend_ps.py (inside
>> _print_ps()):
>>
>>self.figure.set_dpi(72) # Override the dpi kwarg
>>dpi = kwargs.get("dpi", 72)
>>
>> The problem here is that while it sets the figure dpi here to 72, it's using
>> the dpi that's passed in down the chain. Since I don't give it a dpi
>> explicity, it grabs the default dpi from my matplotlibrc, which has it set
>> to 300 dpi. So 300 is getting passed down into the chain and I believe the
>> drawing commands are using 300 dpi. If I change the second line above to
>> dpi = 72, I get the proper results.
>
> Yes, we definitely need to get this fixed before any release, but we
> need to be careful here. I had forgotten that Nicholas Young had
> submitted a patch to make the ps backend respect higher resolutions
> for embedded images
>
>
> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg00353.html
>
> so we cannot simply revert this to 72. I also see the problem you
> pointed out in the collections module too. While I don't have a quick
> fix at hand, at least we are starting to converge onto where the
> problems lie. Note that in the collections module the
> IdentityTransform is bit of a red herring in the set_transforms
> method, since the collection maintains a list of transforms in
> _transforms that incorporates a dpi a draw time so I don't thing the
> standard artist transform property is used.
I was alluding to this in my earlier rants about scatter and
PolyCollection. The mechanism of the list of transforms is fine, but
the kwarg name and API are bad, and additional comments are needed. I
was going to hold off until after the release, but maybe I should go
ahead and try to improve this, in a 100% backwards-compatible way, as
soon as I can get to it.
>
>> 2) backend_ps._print_figure() uses the md5 module to create a temporary
>> filename. This module is deprecated in python 2.5 and removed (I believe)
>> in 3.0, replaced by hashlib. Is there any opposition to changing the direct
>> use of md5.md5() to using a try...except to import md5() from it's proper
>> place?
>
> I wasn't aware of the deprecation so I don't have any strong opinion,
> except that it wold be better if you can find a non-deprecated
> equivalent which is python 2.4 and 2.5 compatible.
If it is a temporary file, why not use one of the functions in the
tempfile module? I have not looked at the code to see whether one of
them would be appropriate, but it seems odd to have to use some other
module.
Eric
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib:[5881] trunk/matplotlib/lib/matplotlib/quiver.py
[EMAIL PROTECTED] wrote: > Revision: 5881 > http://matplotlib.svn.sourceforge.net/matplotlib/?rev=5881&view=rev > Author: jdh2358 > Date: 2008-07-25 23:54:37 + (Fri, 25 Jul 2008) > > Log Message: > --- > added set_figure method for quiverkey > > Modified Paths: > -- > trunk/matplotlib/lib/matplotlib/quiver.py > > Modified: trunk/matplotlib/lib/matplotlib/quiver.py > === > --- trunk/matplotlib/lib/matplotlib/quiver.py 2008-07-25 23:52:46 UTC (rev > 5880) > +++ trunk/matplotlib/lib/matplotlib/quiver.py 2008-07-25 23:54:37 UTC (rev > 5881) > @@ -296,7 +296,7 @@ > quiverkey_doc = _quiverkey_doc > > def set_figure(self, fig): > -Artist.set_figure(self, fig) > +martist.Artist.set_figure(self, fig) > self.text.set_figure(fig) > > class Quiver(collections.PolyCollection): This looks incomplete--shouldn't the QuiverKey initializer be using this function to set the figure from Q.ax.figure, and then should be using self.figure to get the transform? I don't want to jump in if you are in the middle of working with it, though. I don't know what your motivation for adding this function was. Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs Full Patch
On Fri, Jul 25, 2008 at 6:42 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > This is the kind of thing I would want to look at and test *very* carefully, > or know that someone like John or Mike has done so--which perhaps one of > them can do quickly. I have looked at this dpi business with puzzlement > before; I don't have it all straight in my head; and I would need a chunk of > time to review it, which I might get in the next day or so, but can't > guarantee. I just committed a fix here -- I renamed the renderer dpi instance to imagedpi to avoid confusion, and modified the various places in the artist code (collections, text) which were using renderer.dpi (they now use figure.dpi). Right now the only backend that was using the image magnification was backend ps. > Another aspect of the problem is that at least for use with vector backends, > specifying lengths in dots is unnatural; and it seems to me like something > to be avoided when possible even for raster backends. I would argue that > pad variables should be in physical or relative units, where relative could > mean relative to the figure size, or to a font em, for example. Specifying > lengths in dots is just asking for trouble except when the plot is not > intended to be scaled; when making a small png for the web, precise control > via lengths in dots may be helpful. Yes, certainly points or some other physical dimension is the right way to specify pads. Where in the code are dots/pixels used? JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs Full Patch
John Hunter wrote:
> On Fri, Jul 25, 2008 at 5:47 PM, Ryan May <[EMAIL PROTECTED]> wrote:
>
>> Ok, I think I found our problem, at line 859 of backend_ps.py (inside
>> _print_ps()):
>>
>>self.figure.set_dpi(72) # Override the dpi kwarg
>>dpi = kwargs.get("dpi", 72)
>>
>> The problem here is that while it sets the figure dpi here to 72, it's using
>> the dpi that's passed in down the chain. Since I don't give it a dpi
>> explicity, it grabs the default dpi from my matplotlibrc, which has it set
>> to 300 dpi. So 300 is getting passed down into the chain and I believe the
>> drawing commands are using 300 dpi. If I change the second line above to
>> dpi = 72, I get the proper results.
>
> Yes, we definitely need to get this fixed before any release, but we
> need to be careful here. I had forgotten that Nicholas Young had
> submitted a patch to make the ps backend respect higher resolutions
> for embedded images
>
>
> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg00353.html
>
> so we cannot simply revert this to 72. I also see the problem you
> pointed out in the collections module too. While I don't have a quick
> fix at hand, at least we are starting to converge onto where the
> problems lie. Note that in the collections module the
> IdentityTransform is bit of a red herring in the set_transforms
> method, since the collection maintains a list of transforms in
> _transforms that incorporates a dpi a draw time so I don't thing the
> standard artist transform property is used.
Yeah, I figured it was more complex thatn that. While the
IdentityTransform() might be a bit of a red herring, the fact remains
that changing the dpi still changes the size of the of the marker
relative to the canvas in a scatter plot saved with backend_ps, which
doesn't occur with the image backends (at least I tested for png).
>> 2) backend_ps._print_figure() uses the md5 module to create a temporary
>> filename. This module is deprecated in python 2.5 and removed (I believe)
>> in 3.0, replaced by hashlib. Is there any opposition to changing the direct
>> use of md5.md5() to using a try...except to import md5() from it's proper
>> place?
>
> I wasn't aware of the deprecation so I don't have any strong opinion,
> except that it wold be better if you can find a non-deprecated
> equivalent which is python 2.4 and 2.5 compatible.
Therein lies the problem, 2.5 deprecated md5 in favor of hashlib, which
was added in 2.5. So the options are:
1)Do nothing now. Go back and fix the problem when we get around to
supporting 3.x. md5 has officially been removed from SVN for python
3.0.
2)Move completely over to hashlib, drop support for <2.5
3)try to import md5() from hashlib, if that fails fall back to importing
md5() from the md5 module.
Option 2 is not really an option, so never mind it. Option 1 is the
status quo, and it just means we need to keep it in mind as one of the
issues that will have to be handled later when we move to 3.x. I just
read that in 2.6, md5 will issue a DeprecationWarning. That probably
kicks us to option 3.
Option 3 isn't too bad. Both the md5 objects from hashlib and from the
md5 module support the same API. Hashlib lacks a module level function
new() which md5 has, but this is just an alternative to using a class
constructor, so code that uses new() (backend_svg) is easily moved over
to code that works for both.
I'll volunteer to do the ports, which will mostly consist of:
try:
from hashlib import md5
except ImportError:
from md5 import md5
Thoughts?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib:[5881] trunk/matplotlib/lib/matplotlib/quiver.py
On Fri, Jul 25, 2008 at 7:02 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > This looks incomplete--shouldn't the QuiverKey initializer be using this > function to set the figure from Q.ax.figure, and then should be using > self.figure to get the transform? > > I don't want to jump in if you are in the middle of working with it, though. > I don't know what your motivation for adding this function was. All artists which contain other artists (eg QuiverKey contains a Text instance) should override set_figure to pass the figure on to the childen (we should have an ArtistContainer base class to facilitate stuff like this). When we later call ax.add_artist(quiverkey), the ax instance will call quiverkey.set_figure so the figure will get passed down to the Text. I needed to get the figure instance set on the text instance because the Text prop key method was using the renderer dpi instance in the cache key, and renderer.dpi no longer exists. Now I am not nearly as familiar with QuiverKey as you are, but this was just a simple fix to make sure the quiverkey text instance gets its figure set. If it appears to you that something is still missing, please clarify. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs Full Patch
On Fri, Jul 25, 2008 at 7:11 PM, Ryan May <[EMAIL PROTECTED]> wrote: > try: >from hashlib import md5 > except ImportError: >from md5 import md5 Looks good to me -- thanks for the offer to fix this. In general, we only actively want to be supporting 2 python versions at a time, but if there is an easy way to extend support to a broader range, there is no reason not to. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs Full Patch
John Hunter wrote: > On Fri, Jul 25, 2008 at 6:42 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > >> This is the kind of thing I would want to look at and test *very* carefully, >> or know that someone like John or Mike has done so--which perhaps one of >> them can do quickly. I have looked at this dpi business with puzzlement >> before; I don't have it all straight in my head; and I would need a chunk of >> time to review it, which I might get in the next day or so, but can't >> guarantee. > > I just committed a fix here -- I renamed the renderer dpi instance to > imagedpi to avoid confusion, and modified the various places in the > artist code (collections, text) which were using renderer.dpi (they > now use figure.dpi). Right now the only backend that was using the > image magnification was backend ps. It fixes the problems that barb_demo.py was having saving to EPS files here. No noticable changes to the png files or displayed figure (as one would expect). Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs Full Patch
John Hunter wrote: > On Fri, Jul 25, 2008 at 6:42 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > >> This is the kind of thing I would want to look at and test *very* carefully, >> or know that someone like John or Mike has done so--which perhaps one of >> them can do quickly. I have looked at this dpi business with puzzlement >> before; I don't have it all straight in my head; and I would need a chunk of >> time to review it, which I might get in the next day or so, but can't >> guarantee. > > I just committed a fix here -- I renamed the renderer dpi instance to > imagedpi to avoid confusion, and modified the various places in the > artist code (collections, text) which were using renderer.dpi (they > now use figure.dpi). Right now the only backend that was using the > image magnification was backend ps. Good, thank you. > >> Another aspect of the problem is that at least for use with vector backends, >> specifying lengths in dots is unnatural; and it seems to me like something >> to be avoided when possible even for raster backends. I would argue that >> pad variables should be in physical or relative units, where relative could >> mean relative to the figure size, or to a font em, for example. Specifying >> lengths in dots is just asking for trouble except when the plot is not >> intended to be scaled; when making a small png for the web, precise control >> via lengths in dots may be helpful. > > Yes, certainly points or some other physical dimension is the right > way to specify pads. Where in the code are dots/pixels used? Sorry, I was misremembering; it looks like such cases were purged a long time ago. Eric > > JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] contains methods
Hi, I fixed some of the contains() methods so at least the simple cases work. Degenerate rectangles cause problems in axes_demo: >>> import matplotlib.patches >>> r = matplotlib.patches.Rectangle((0,0),1,0) >>> r.get_transform().inverted() Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py", line 1338, in inverted self._inverted = Affine2D(inv(mtx)) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.1.0-py2.5-macosx-10.3-fat.egg/numpy/linalg/linalg.py", line 332, in inv return wrap(solve(a, identity(a.shape[0], dtype=a.dtype))) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.1.0-py2.5-macosx-10.3-fat.egg/numpy/linalg/linalg.py", line 235, in solve raise LinAlgError, 'Singular matrix' numpy.linalg.linalg.LinAlgError: Singular matrix I've only gone through the a*.py samples, but there are a few other glitches such as not detecting axhline/axvline, not handling rotated text properly, and not doing very well on polar plots. These will have to wait for another release. - Paul - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SF.net SVN: matplotlib:[5881] trunk/matplotlib/lib/matplotlib/quiver.py
John Hunter wrote: > On Fri, Jul 25, 2008 at 7:02 PM, Eric Firing <[EMAIL PROTECTED]> wrote: > >> This looks incomplete--shouldn't the QuiverKey initializer be using this >> function to set the figure from Q.ax.figure, and then should be using >> self.figure to get the transform? >> >> I don't want to jump in if you are in the middle of working with it, though. >> I don't know what your motivation for adding this function was. > > All artists which contain other artists (eg QuiverKey contains a Text > instance) should override set_figure to pass the figure on to the > childen (we should have an ArtistContainer base class to facilitate > stuff like this). When we later call ax.add_artist(quiverkey), the ax > instance will call quiverkey.set_figure so the figure will get passed > down to the Text. I needed to get the figure instance set on the text > instance because the Text prop key method was using the renderer dpi > instance in the cache key, and renderer.dpi no longer exists. Now I > am not nearly as familiar with QuiverKey as you are, but this was just > a simple fix to make sure the quiverkey text instance gets its figure > set. If it appears to you that something is still missing, please > clarify. Thanks for the explanation. The change I had in mind would not hurt, but it would not help, either, so we'll leave it out. Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
