Re: [matplotlib-devel] spy: ignore zero values in sparse matrix
Hi Eric,
Sorry for the late reply.
On Sep 27, 2008, at 8:56 PM, Eric Firing wrote:
> Actually, I think the most logical thing would be to let the default
> None give the old behavior, and require precision=0 to get the new
> behavior. What do you think? Is it OK if I make this change? It
> is more consistent with the old behavior.
I'm ambivalent about this change. On one hand, I think it makes a lot
more sense to have None give the old behavior and precision=0 to
ignore zero values in the sparse array (then precision would be
consistent for finite values and for zero).
On the other hand, I think ignoring zero values should be the default
behavior for sparse arrays (although, I definitely agree there should
be the option to plot all assigned values).
Would it be possible to make the change you suggest and also change
the default precision value to 0? (see diff below) This change would
also allow you to remove a lot of the special handling for
precision=None, since precision=0 gives the same result (I didn't go
this far in the diff below).
> I also changed the behavior so that if a sparse array is input, with
> no marker specifications, it simply makes a default marker plot
> instead of raising an exception.
Excellent idea. That behavior is much more user-friendly.
Thanks,
-Tony
PS. Any comments on the small changes to the examples. Both changes
are necessary for those examples to work on my computer (the shebang
line throws an error when I run the code from my text editor).
Index: matplotlib/lib/matplotlib/axes.py
===
--- matplotlib/lib/matplotlib/axes.py (revision 6141)
+++ matplotlib/lib/matplotlib/axes.py (working copy)
@@ -6648,7 +6648,7 @@
return Pxx, freqs, bins, im
-def spy(self, Z, precision=None, marker=None, markersize=None,
+def spy(self, Z, precision=0., marker=None, markersize=None,
aspect='equal', **kwargs):
"""
call signature::
@@ -6731,14 +6731,11 @@
else:
if hasattr(Z, 'tocoo'):
c = Z.tocoo()
-if precision == 0:
+if precision is None:
y = c.row
x = c.col
else:
-if precision is None:
-nonzero = c.data != 0.
-else:
-nonzero = np.absolute(c.data) > precision
+nonzero = np.absolute(c.data) > precision
y = c.row[nonzero]
x = c.col[nonzero]
else:
Index: matplotlib/examples/pylab_examples/masked_demo.py
===
--- matplotlib/examples/pylab_examples/masked_demo.py (revision 6141)
+++ matplotlib/examples/pylab_examples/masked_demo.py (working copy)
@@ -1,4 +1,4 @@
-#!/bin/env python
+#!/usr/bin/env python
'''
Plot lines with points masked out.
Index: matplotlib/examples/misc/rec_groupby_demo.py
===
--- matplotlib/examples/misc/rec_groupby_demo.py(revision 6141)
+++ matplotlib/examples/misc/rec_groupby_demo.py(working copy)
@@ -2,7 +2,7 @@
import matplotlib.mlab as mlab
-r = mlab.csv2rec('data/aapl.csv')
+r = mlab.csv2rec('../data/aapl.csv')
r.sort()
def daily_return(prices):
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] spy: ignore zero values in sparse matrix
On Sep 26, 2008, at 5:01 PM, Eric Firing wrote:
> Also, if an image cannot be resolved by the output device, info is
> lost--one might not see anything at a location where there actually
> is a value--whereas with markers, a marker will always show up, and
> the only problem is that one can't necessarily distinguish a single
> point from a cluster.
>
> The real problem with all-zero values is that plot can't handle
> "plot([],[])". One can work around this by putting in bogus values
> to plot a single point, saving the line, and then setting the line
> data to empty; or, better, by not using the high-level plot command,
> but by generating the Line2D object and adding it to the axes. The
> Line2D initializer is happy with empty x and y sequences. I think if
> you use this approach it will kill two bugs (failure on all-zeros
> with sparse and full arrays) with one very simple stone.
>
> Eric
Thanks for the tip Eric. Below is a patch for spy that implements
Eric's suggestion. This patch seems to work for a couple simple tests
on my end: sparse and dense arrays with non-zero and all-zero values.
A couple of notes:
* the call to `add_artist` isn't needed to show the correct plot, but
it may be helpful for debugging.
* the docstring for `spy` suggests that a Line2D instance is returned,
but `spy` currently returns a list with a Line2D instance. I set all-
zero arrays to return a list also, for consistency.
-Tony
Index: matplotlib/lib/matplotlib/axes.py
===
--- matplotlib/lib/matplotlib/axes.py (revision 6123)
+++ matplotlib/lib/matplotlib/axes.py (working copy)
@@ -6723,9 +6723,9 @@
else:
if hasattr(Z, 'tocoo'):
c = Z.tocoo()
-y = c.row
-x = c.col
-z = c.data
+nonzero = c.data != 0.
+y = c.row[nonzero]
+x = c.col[nonzero]
else:
Z = np.asarray(Z)
if precision is None: mask = Z!=0.
@@ -6733,8 +6733,12 @@
y,x,z = mlab.get_xyz_where(mask, mask)
if marker is None: marker = 's'
if markersize is None: markersize = 10
-lines = self.plot(x, y, linestyle='None',
- marker=marker, markersize=markersize,
**kwargs)
+if len(x) == 0:
+lines = [mlines.Line2D([], [])]
+self.add_artist(lines[0])
+else:
+lines = self.plot(x, y, linestyle='None',
+ marker=marker, markersize=markersize,
**kwargs)
nr, nc = Z.shape
self.set_xlim(xmin=-0.5, xmax=nc-0.5)
self.set_ylim(ymin=nr-0.5, ymax=-0.5)
Index: matplotlib/examples/pylab_examples/masked_demo.py
===
--- matplotlib/examples/pylab_examples/masked_demo.py (revision 6123)
+++ matplotlib/examples/pylab_examples/masked_demo.py (working copy)
@@ -1,4 +1,4 @@
-#!/bin/env python
+#!/usr/bin/env python
'''
Plot lines with points masked out.
Index: matplotlib/examples/misc/rec_groupby_demo.py
===
--- matplotlib/examples/misc/rec_groupby_demo.py(revision 6123)
+++ matplotlib/examples/misc/rec_groupby_demo.py(working copy)
@@ -2,7 +2,7 @@
import matplotlib.mlab as mlab
-r = mlab.csv2rec('data/aapl.csv')
+r = mlab.csv2rec('../data/aapl.csv')
r.sort()
def daily_return(prices):
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] minor fix to animation example
I noticed that one of the animation examples is missing some import statements. Also, the diff below includes a small change to the shebang line of another example. Cheers, -Tony anim_imports.diff Description: Binary data - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] minor fix to animation example
On Oct 17, 2008, at 7:29 AM, John Hunter wrote: > Hey Tony, > > Thanks for the patch, applied to svn r6232. For future patches, could > you send a "svn diff" from the matplotlib directory containing > setup.py. That way I don't have to think too hard about the patch > level, what kind of patch it is etc Doh, I think you mentioned this to me before. Sorry about that. > Thanks again, > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] colormap clipping for large numbers (small vmax - vmin)
I was using pcolor with very large numbers and a small vrange (vmax - vmin), and ran into a float to integer conversion problem. Large numbers get converted to *negative* integers by astype (see numpy thread) in colors.Colormap.__call__.I'm not sure if this is even worth fixing since almost no one would run into this problem (unless you were doing something stupid, like trying to use pcolor as a 2D zero finder :). For the error to occur, you have to set vmin/vmax values (otherwise, the data is properly normalized before converting to integers), and your data has to greatly exceed these limits.Cheers,-Tony#!/usr/bin/env python
from __future__ import with_statement
import numpy as np
import cookbook as cb
vmin = 0.45
vmax = 0.55
N = 1000
with cb.stopwatch():
xa = np.random.sample((N, N))
np.putmask(xa, xa > vmax, vmax)
np.putmask(xa, xa < vmin, vmin)
with cb.stopwatch():
xa = np.random.sample((N, N))
np.clip(xa, vmin, vmax, out=xa)Example of the problem:#~import matplotlib.pyplot as pltimport numpy as npcmap = plt.cm.graycmap.set_over('r', 1.0)cmap.set_under('g', 1.0)cmap.set_bad('b', 1.0)eps = 1E-8A = np.arange(100).reshape(10, 10)plt.pcolor(A, vmin=50, vmax=50+eps, cmap=cmap)# the plot should be about half red and half green (plus a black square)# without patch, some of the red squares are filled greenplt.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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Selecting WX2.8 causes problems on wx 2.8.4
I'm running into the following error with the wx backend
> >>> import wx
> >>> import matplotlib.backends.backend_wxagg
> Traceback (most recent call last):
> File "", line 1, in
> File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
> matplotlib/backends/backend_wxagg.py", line 23, in
> import backend_wx# already uses wxversion.ensureMinimal('2.8')
> File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
> matplotlib/backends/backend_wx.py", line 120, in
> except wxversion.AlreadyImportedError:
> AttributeError: 'module' object has no attribute
> 'AlreadyImportedError'
This problem seems to be related to additions made here:
http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html
The problem is that my version of wxversion raises 'VersionError'
instead of 'AlreadyImportedError'.
I'm running wxPython 2.8.4.0 while people in the above thread seem to
be using at least 2.8.7.1. Do I need to upgrade, or is this a bug?
Thanks,
-Tony
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Updating Circle.radius has no effect (+minor example fix)
I'm animating a Circle patch with a varying center and radius, and I noticed that changing the ``radius`` attribute has no effect on the patch. Currently, ``radius`` is only used to instantiate an Ellipse object, but updating radius has no effect (i.e. redrawing the patch doesn't use the new radius). I've included a patch to add this feature. Also included in the patch is a small fix to one of the UI examples (sorry for included a completely unrelated patch but the fix seemed to small for a separate email). BTW, I'm using a property idiom from: http://code.activestate.com/recipes/205183/ . I thought that this approach was better than polluting the namespace with getters and setters, especially since this would differ from the way the Ellipse class uses ``width`` and ``height`` attributes. Cheers, -Tony === --- lib/matplotlib/patches.py (revision 7128) +++ lib/matplotlib/patches.py (working copy) @@ -1131,6 +1131,14 @@ self.radius = radius Ellipse.__init__(self, xy, radius*2, radius*2, **kwargs) __init__.__doc__ = cbook.dedent(__init__.__doc__) % artist.kwdocd + +def radius(): +def fget(self): +return self.width / 2. +def fset(self, radius): +self.width = self.height = 2 * radius +return locals() +radius = property(**radius()) class Arc(Ellipse): """ Index: examples/user_interfaces/embedding_in_wx3.py === --- examples/user_interfaces/embedding_in_wx3.py(revision 7128) +++ examples/user_interfaces/embedding_in_wx3.py(working copy) @@ -147,7 +147,7 @@ return True def OnBang(self,event): -bang_count = XRCCTRL(self.frame,"bang_count") +bang_count = xrc.XRCCTRL(self.frame,"bang_count") bangs = bang_count.GetValue() bangs = int(bangs)+1 bang_count.SetValue(str(bangs)) -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] 'BlendedGenericTransform' object has no attribute '_interpolation_steps'
When running `pyplot.spy` I ran into the following error: AttributeError: 'BlendedGenericTransform' object has no attribute '_interpolation_steps' Just from pattern matching (I have no idea what's going on in the code), I noticed that _interpolation_steps was usually called from a Path object, not a Transform object, so I tried switching the call (see diff below), which seems to work for me. Since this was a recent addition (r7130), I figure this was just a typo. Cheers, -Tony === --- lib/matplotlib/transforms.py(revision 7133) +++ lib/matplotlib/transforms.py(working copy) @@ -1145,7 +1145,7 @@ ``transform_path_affine(transform_path_non_affine(values))``. """ return Path(self.transform_non_affine(path.vertices), path.codes, -self._interpolation_steps) +path._interpolation_steps) def transform_angles(self, angles, pts, radians=False, pushoff=1e-5): """ -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Arc requires explicitly setting fill=False?
Currently, Arc in matplotlib.patches requires that it be called with
kwarg ``fill=False``. Was this behavior intentional? The code suggests
that a default value was left out of the kwarg lookup.
I've attached a simple patch to fix this (it still fails when fill set
to True).
Cheers,
-Tony
Index: lib/matplotlib/patches.py
===
--- lib/matplotlib/patches.py (revision 7137)
+++ lib/matplotlib/patches.py (working copy)
@@ -1189,7 +1189,7 @@
%(Patch)s
"""
-fill = kwargs.pop('fill')
+fill = kwargs.pop('fill', False)
if fill:
raise ValueError("Arc objects can not be filled")
kwargs['fill'] = False
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] semilogx and semilogy don't reset linear scale
Did this email ever appear on list? I didn't see it after sending my
original post, but I found it on the Sourceforge mail archives. I'm
trying a different email address as an experiment.
In any case, any comments on the patch?
-Tony
On Aug 24, 2009, at 5:31 PM, Tony Yu wrote:
> I noticed that semilogx and semilogy don't check if the linear axis
> (y-axis for semilogx; x-axis for semilogy) is actually linear. Thus,
> if I call semilogx and then call semilogy *on the same plot*, I end
> up with a loglog plot.
>
> Below is a simple patch. I'm not sure how useful this fix is since
> most people wouldn't want to make these calls on the same plot
> (since the second call would override the first)---I was working
> interactively in IPython so it did make a difference.
>
> Cheers,
> -Tony
>
>
> Index: lib/matplotlib/axes.py
> ===
> --- lib/matplotlib/axes.py(revision 7557)
> +++ lib/matplotlib/axes.py(working copy)
> @@ -3615,6 +3615,7 @@
> }
>
> self.set_xscale('log', **d)
> +self.set_yscale('linear')
> b = self._hold
> self._hold = True # we've already processed the hold
> l = self.plot(*args, **kwargs)
> @@ -3665,6 +3666,7 @@
> 'nonposy': kwargs.pop('nonposy', 'mask'),
> }
> self.set_yscale('log', **d)
> +self.set_xscale('linear')
> b = self._hold
> self._hold = True # we've already processed the hold
> l = self.plot(*args, **kwargs)
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: OS X 10.6 port
On Sep 28, 2009, at 2:14 AM, John Hunter wrote: > in case anyone has some suggestions, I'm forwarding this from the > sage list > > > -- Forwarded message -- > From: William Stein > Date: Sun, Sep 27, 2009 at 10:51 PM > Subject: OS X 10.6 port > To: sage-devel , John Hunter > > > > Hi, > > I spent several hours yesterday trying to get matplotlib for Sage to > work on OS X 10.6. On my laptop everything works perfectly, but on > another test machine (bsd.math) the workaround from my laptop doesn't > work. So at this point Sage still does not support OS X 10.6. > > The problem is in matplotlib's C++ wrapper for freetype2. It's a > Python extension module implemented directly in C++, and it simply > doesn't work correctly at all. For example, whenever it tries to > raise a Python exception, it just terminates Python with > > "11713 Abort trap sage-ipython "$@" -i" I thought I'd chime in since I recently upgraded to OSX 10.6. I don't think I ever got this error, so I probably didn't have the same issue, but just in case... I reinstalled freetype2, but I'm not sure if I needed to. I also made a change to setupext.py so that the setup script could find freetype2, but this doesn't seem to be your problem because your errors don't occur during the build. Did you happen to build on top of an old install? I had to clean out the old compiled extensions before everything would build properly. I had to clean out the build directory (obviously), but there are also *.so files in lib/matplotlib and lib/matplotlib/backends. I should note that I'm built on top of the system python (2.6.1) and I did not use make.osx. -Tony -- 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] experimental numscons support in matplotlib
On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote: > However, with svn r7985, the trunk fails to find the tests. This is so > weird. There's nothing in that commit that I can see that should cause > the failure, but it seems repeatable. r7984 doesn't have it and r7985 > does. And it appears to be more or less the issue that the scons branch > had. Sigh. Could this failure be related to the bug filed by Christoph Gohlke (see tracker)? The change corresponds to r7985 and affects setupext.py. I'm not sure if the numscons build uses setupext.py, but it may be worth checking out. -Tony-- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Segmentation fault from fresh OSX snow leopard build
On Nov 30, 2009, at 9:09 AM, Jcmottram wrote:
>
> Hi,
> I've been having an almost identical problem with described above with
> the MacOSX backend. When I switched to the TkAgg backend, the segfault
> occurs when I try pylab.close() instead.
>
>
I may have had the same problem. Do you happen to be on a recent revision?
Christoph Gohlke pointed out a typo introduced in r7985 (see bug report). The
patch below fixed the segfaults on my system.
Best,
-Tony
Index: setupext.py
===
--- setupext.py (revision 7987)
+++ setupext.py (working copy)
@@ -122,7 +122,7 @@
'backend': None}
defines = [
- ('PY_ARRAYAUNIQUE_SYMBOL', 'MPL_ARRAY_API'),
+ ('PY_ARRAY_UNIQUE_SYMBOL', 'MPL_ARRAY_API'),
('PYCXX_ISO_CPP_LIB', '1')]
# Based on the contents of setup.cfg, determine the build options
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Weird windowing issues since last update of OS X 10.6
I updated to the newest release of OS X---10.6.2---last night and I've been getting a weird windowing error for certain backends. I'm able to reproduce the error with the following: run a simple plot script (which calls plt.show) from the terminal. Close the figure. The problem is: * tkagg: window closes, but it doesn't return control to the terminal (i.e. terminal hangs). * macosx: axis is cleared from the figure window, but the window (w/o axis) remains and terminal hangs. * qt4agg: works fine. Alternatively, I can run the script from ipython. In this case, tkagg and qt4agg work as normal. The macosx backend hangs, the window does not close, and control is not returned to ipython. In all cases, the plot shows up fine (it just doesn't always close properly). Running the script with python -vv doesn't help: All the debug code it prints stops before plt.show is called. I wish I could provide more debug output, but I'm not sure how. Any ideas? -Tony PS. To add another piece to the mystery, I've been having problems running plot scripts from my text editor (Textmate): python hangs **before** plotting. I've traced the hang to a call to matplotlib.backends.pylab_setup.new_figure_manager, but I really don't understand where exactly hangs. Again: this only happens when running from Textmate, and started happening about a week ago (following a Textmate update). My guess is that this is a Textmate-related issue, but I thought I'd mention it in case these two issues combined suggest a more fundamental problem with my python install. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Weird windowing issues since last update of OS X 10.6
Hi Claus, I fixed the non-Textmate issues (i.e. everything before the P.S. in my original email), but the TextMate issue remains. I've had a friend confirm this issue (i.e. hanging on plot calls when scripts are run in Textmate) on his system, and it sounds like you're confirming the issue as well. I keep meaning to write to the TextMate list, but haven't yet done so. Let me know if you have any luck with this issue. Best, -Tony On Jan 7, 2010, at 10:02 AM, Claus13 wrote: > > Hi Tony, > > have you solved this issue? > What was the problem? > > I just installed the ScipySuperpack > http://macinscience.org/?page_id=6 > on a clean OSX 10.6 machine > > running > http://matplotlib.sourceforge.net/plot_directive/mpl_examples/pylab_examples/date_demo_rrule.py > for example from the command line works awesome, but not from TextMate. > > This sounds like the same problem you had.. > I'd appreciate any pointers! > > Cheers, > Claus > > > > > > > Tony Yu-3 wrote: >> >> I updated to the newest release of OS X---10.6.2---last night and I've >> been getting a weird windowing error for certain backends. >> >> I'm able to reproduce the error with the following: run a simple plot >> script (which calls plt.show) from the terminal. Close the figure. The >> problem is: >> >> * tkagg: window closes, but it doesn't return control to the terminal >> (i.e. terminal hangs). >> * macosx: axis is cleared from the figure window, but the window (w/o >> axis) remains and terminal hangs. >> * qt4agg: works fine. >> >> Alternatively, I can run the script from ipython. In this case, tkagg and >> qt4agg work as normal. The macosx backend hangs, the window does not >> close, and control is not returned to ipython. >> >> In all cases, the plot shows up fine (it just doesn't always close >> properly). Running the script with python -vv doesn't help: All the debug >> code it prints stops before plt.show is called. I wish I could provide >> more debug output, but I'm not sure how. >> >> Any ideas? >> >> -Tony >> >> PS. To add another piece to the mystery, I've been having problems running >> plot scripts from my text editor (Textmate): python hangs **before** >> plotting. I've traced the hang to a call to >> matplotlib.backends.pylab_setup.new_figure_manager, but I really don't >> understand where exactly hangs. Again: this only happens when running from >> Textmate, and started happening about a week ago (following a Textmate >> update). My guess is that this is a Textmate-related issue, but I thought >> I'd mention it in case these two issues combined suggest a more >> fundamental problem with my python install. >> -- >> Join us December 9, 2009 for the Red Hat Virtual Experience, >> a free event focused on virtualization and cloud computing. >> Attend in-depth sessions from your desk. Your couch. Anywhere. >> http://p.sf.net/sfu/redhat-sfdev2dev >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > -- > View this message in context: > http://old.nabble.com/Weird-windowing-issues-since-last-update-of-OS-X-10.6-tp26658846p27061342.html > Sent from the matplotlib - devel mailing list archive at Nabble.com. > > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Inconsistent behavior in plt.hist
I get inconsistent behavior when plotting multiple sets of data with plt.hist. Here's a quick example: >>> import numpy as np >>> import matplotlib.pyplot as plt >>> x = np.random.randn(10) >>> y = np.random.randn(9) >>> plt.hist([x, y]) The above code plots two sets of histograms, as expected. My data sets have different lengths, but by coincidence, I had two data sets with the same length. When you call hist on data sets with the same length >>> plt.hist([x[:-1], y]) then hist actually transposes the data; for the above, you get 9 sets of data instead of two. Below is a patch that fixes the issue, but unfortunately, it'll probably break other peoples' code; in fact, it breaks the example code (histogram_demo_extended.py). I'm not sure what's worse: dealing with the inconsistency or breaking a lot of code. But if there's a time to break code, MPL 1.0 might be it :) Best, -Tony Index: lib/matplotlib/axes.py === --- lib/matplotlib/axes.py (revision 8187) +++ lib/matplotlib/axes.py (working copy) @@ -7122,7 +7122,7 @@ try: # make sure a copy is created: don't use asarray -x = np.transpose(np.array(x)) +x = np.array(x) if len(x.shape)==1: x.shape = (1,x.shape[0]) elif len(x.shape)==2 and x.shape[1]http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Lowess smoothing
On Apr 24, 2010, at 4:25 AM, Michiel de Hoon wrote: > Hi everybody, > > A number of years ago I wrote a function to do Lowess smoothing to calculate > a smooth curve through a scatter plot. I copied an example script below and > attached the resulting figure to this mail. > I think that such a smoothing function would be a useful addition to > matplotlib. Does anybody have any objections against me adding this to > matplotlib? If not, what would be a suitable place to put this function? I'm not a matplotlib developer, but smoothing seems more appropriate for scipy. There's been some talk of starting a scikit for smoothing functions (see links below), but I'm not sure if anyone has the motivation to actually take the lead. -Tony http://mail.scipy.org/pipermail/scipy-user/2010-February/024402.html http://mail.scipy.org/pipermail/scipy-user/2010-February/024408.html-- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Histogram bug introduced in r8218
It seems that changes introduced in r8218 drastically changed how `hist` handles Python lists. For example, the histogram given by the following snippet, works as expected: >>> x = np.random.randn(100) >>> plt.hist(x) However, if you pass a 1D list to `hist`, the 1D list is cast to a list of length-1 arrays---each treated as a separate histogram. Continuing the above code, check the results of the following: >>> plt.hist(list(x)) I assume that this behavior is unintended, right? -Tony -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Direction keys not recognized in Qt4 backend
I'm running the Qt4 backend, and I noticed that I'd frequently get error
messages saying I was pressing unrecognized keys. It turns out that the
direction keys aren't recognized in the qt4 backend. (I'm using direction keys
to switch between spaces in OSX, so this error gets triggered quite frequently)
One possible fix is to just add the direction keys to the list of valid keys
(see patch below). Alternatively, the key event code could just ignore
unrecognized keys (i.e. `key == None`). This change could be made in
FigureCanvasQT.keyPressEvent (in backends.backend_qt4.py) or, more generally,
in FigureCanvasBase.key_press_event (in backend_bases.py).
-Tony
%---Diff
Index: lib/matplotlib/backends/backend_qt4.py
===
--- lib/matplotlib/backends/backend_qt4.py (revision 8315)
+++ lib/matplotlib/backends/backend_qt4.py (working copy)
@@ -129,6 +129,10 @@
keyvald = { QtCore.Qt.Key_Control : 'control',
QtCore.Qt.Key_Shift : 'shift',
QtCore.Qt.Key_Alt : 'alt',
+QtCore.Qt.Key_Up : 'up',
+QtCore.Qt.Key_Right : 'right',
+QtCore.Qt.Key_Down : 'down',
+QtCore.Qt.Key_Left : 'left',
}
# left 1, middle 2, right 3
buttond = {1:1, 2:3, 4:2}
%---Full traceback
Traceback (most recent call last):
File "/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_qt4.py",
line 198, in keyPressEvent
FigureCanvasBase.key_press_event( self, key )
File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line
1459, in key_press_event
self.callbacks.process(s, event)
File "/Users/Tony/python/devel/mpl/lib/matplotlib/cbook.py", line 169, in
process
func(*args, **kwargs)
File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line
2079, in key_press
if event.key in fullscreen_keys:
TypeError: 'in ' requires string as left operand, not NoneType
--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Some keys generate tracebacks in the GTK backend
On Jun 1, 2010, at 8:59 AM, João Luís Silva wrote:
> Hi,
>
> Pressing tab, the "Windows" key or the right click key (and maybe
> others) on a plot with the GTKAgg or GTK backend causes the following
> traceback:
>
> Traceback (most recent call last):
[snip]
> File "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py",
> line 2079, in key_press
> if event.key in fullscreen_keys:
> TypeError: 'in ' requires string as left operand
>
> This happens because in these cases the key is None. The WXAgg backend
> doesn't have this bug (I haven't tested qt nor tk backends).
This is similar to an issue I had. I posted a patch for my error, but it was
specific to Qt4 and required all keys to be manually added to the class
definition. I suggested a more robust solution: returning early in
backend_bases when the key is None. That suggestion kind of died after Darren
Dale solicited responses from other devs.
If it helps at all, I've attached a very simple patch. The early return at the
top of the patch is the important part. The change near the bottom is added
because we've already checked for None (i.e. purely cosmetic).
-Tony
Index: lib/matplotlib/backend_bases.py
===
--- lib/matplotlib/backend_bases.py (revision 8366)
+++ lib/matplotlib/backend_bases.py (working copy)
@@ -2062,6 +2062,8 @@
#self.destroy() # how cruel to have to destroy oneself!
#return
+if event.key is None:
+return
# Load key-mappings from your matplotlibrc file.
fullscreen_keys = rcParams['keymap.fullscreen']
home_keys = rcParams['keymap.home']
@@ -2128,8 +2130,7 @@
ax.set_xscale('log')
ax.figure.canvas.draw()
-elif event.key is not None and \
- (event.key.isdigit() and event.key!='0') or event.key in all:
+elif (event.key.isdigit() and event.key!='0') or event.key in all:
# keys in list 'all' enables all axes (default key 'a'),
# otherwise if key is a number only enable this particular axes
# if it was the axes, where the event was raised
--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Segfault in _path.so plugin when importing matplotlib in Chaco script
The recent "nasty import behavior" thread motivated me to post an issue I've
been having with matplotlib and chaco. (I've posted to the Chaco list
previously, without much luck.)
If I import matplotlib and chaco at the same time, I get a segmentation fault
in the _path.so plugin. Below is a simple script that segfaults on my computer.
I should note that this is installation dependent; someone on the Chaco list
only had the issue with certain versions of Python. Just for reference, I'm on
OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk.
-Tony
P.S. In reality, there's no reason to import matplotlib when using Chaco, but I
have some helper modules with some tangled imports (i.e. need to be refactored).
#---
import matplotlib.pyplot as plt
import enthought.traits.api as traits
import enthought.traits.ui.api as ui
import enthought.chaco.api as chaco
from enthought.enable.component_editor import ComponentEditor
class LinePlot(traits.HasTraits):
plot = traits.Instance(chaco.Plot)
traits_view = ui.View(
ui.Item('plot', editor=ComponentEditor()),
width=500, height=500, resizable=True)
def __init__(self):
plotdata = chaco.ArrayPlotData(x=[1,2,3], y=[1,2,3])
self.plot = chaco.Plot(plotdata)
self.plot.plot(('x', 'y'))
viewer = LinePlot()
viewer.configure_traits()
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Segfault in _path.so plugin when importing matplotlib in Chaco script
On Jul 8, 2010, at 12:16 PM, John Hunter wrote: > On Thu, Jul 8, 2010 at 11:13 AM, Tony S Yu wrote: >> The recent "nasty import behavior" thread motivated me to post an issue I've >> been having with matplotlib and chaco. (I've posted to the Chaco list >> previously, without much luck.) >> >> If I import matplotlib and chaco at the same time, I get a segmentation >> fault in the _path.so plugin. Below is a simple script that segfaults on my >> computer. >> >> I should note that this is installation dependent; someone on the Chaco list >> only had the issue with certain versions of Python. Just for reference, I'm >> on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk. >> >> -Tony >> >> P.S. In reality, there's no reason to import matplotlib when using Chaco, >> but I have some helper modules with some tangled imports (i.e. need to be >> refactored). > > First question -- are you compiling both yourself and are they > compiled against the same version of numpy. If not, I suspect we are > seeing a numpy version conflict. I am compiling both myself. I did clean compiles of both when Numpy had the whole ABI change (and change back). I've recompiled since then, but without cleaning out compiled code. I can try clean builds, but that will have to be later in the day. I'll post an update. Thanks, -Tony -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Segfault in _path.so plugin when importing matplotlib in Chaco script
On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote: > Can you get a gdb backtrace? > > Mike > This is as far as I can get with gdb: #- $ gdb python GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar 5 04:43:10 UTC 2010) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ... done (gdb) run test_import_chaco_and_plt.py Starting program: /usr/bin/python test_import_chaco_and_plt.py Reading symbols for shared libraries .++. done Program received signal SIGTRAP, Trace/breakpoint trap. 0x7fff5fc01028 in __dyld__dyld_start () (gdb) bt #0 0x7fff5fc01028 in __dyld__dyld_start () #1 0x0001 in ?? () (gdb) #- I'm not very experienced with gdb, so I'm not sure if I'm doing something wrong. Thanks, -Tony > On 07/08/2010 12:13 PM, Tony S Yu wrote: >> The recent "nasty import behavior" thread motivated me to post an issue I've >> been having with matplotlib and chaco. (I've posted to the Chaco list >> previously, without much luck.) >> >> If I import matplotlib and chaco at the same time, I get a segmentation >> fault in the _path.so plugin. Below is a simple script that segfaults on my >> computer. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Segfault in _path.so plugin when importing matplotlib in Chaco script
On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote: > Can you get a gdb backtrace? > > Mike Ignore my last email. The crash occurs here: #--- Continuing. Reading symbols for shared libraries . done Reading symbols for shared libraries + done 2010-07-08 14:15:20.218 Python[60899:d13] *** __NSAutoreleaseNoPool(): Object 0x1048a86d0 of class NSCFNumber autoreleased with no pool in place - just leaking Reading symbols for shared libraries + done Reading symbols for shared libraries + done Reading symbols for shared libraries ++ done Reading symbols for shared libraries + done Reading symbols for shared libraries + done Reading symbols for shared libraries + done Reading symbols for shared libraries + done Reading symbols for shared libraries + done Reading symbols for shared libraries + done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x00300040 agg::pod_bvector, 6u>::~pod_bvector (this=0x7fff5fbf8130) at agg_array.h:521 521 pod_allocator::deallocate(*blk, block_size); #--- and the first few lines of the traceback are here: #--- #0 agg::pod_bvector, 6u>::~pod_bvector (this=0x7fff5fbf8130) at agg_array.h:521 #1 0x000101795b65 in ~vertex_sequence [inlined] () at /Users/Tony/python/devel/mpl/agg24/include/agg_vertex_sequence.h:525 #2 0x000101795b65 in agg::vcgen_stroke::~vcgen_stroke (this=0x7fff5fbf80c8) at agg_vcgen_stroke.h:32 #3 0x00011a45ea07 in ~rasterizer_cells_aa [inlined] () at kiva_graphics_context.h:410 #4 0x00011a45ea07 in ~rasterizer_scanline_aa [inlined] () at /Users/Tony/python/devel/enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h:101 #--- I posted the full traceback on pastebin: http://pastebin.com/ViefksDC Are there conflicting versions of agg? -Tony > > On 07/08/2010 12:13 PM, Tony S Yu wrote: >> The recent "nasty import behavior" thread motivated me to post an issue I've >> been having with matplotlib and chaco. (I've posted to the Chaco list >> previously, without much luck.) >> >> If I import matplotlib and chaco at the same time, I get a segmentation >> fault in the _path.so plugin. Below is a simple script that segfaults on my >> computer. >> >> I should note that this is installation dependent; someone on the Chaco list >> only had the issue with certain versions of Python. Just for reference, I'm >> on OS X 10.6, Python 2.6.1, and matplotlib/chaco trunk. >> >> -Tony -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Segfault in _path.so plugin when importing matplotlib in Chaco script
On Jul 8, 2010, at 2:51 PM, Michael Droettboom wrote:
> On 07/08/2010 02:38 PM, John Hunter wrote:
>> On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu wrote:
>>
>>> On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:
>>>
>>> Can you get a gdb backtrace?
>>>
>>> Mike
>>>
>>> Ignore my last email. The crash occurs here:
>>> #---
>>> Continuing.
>>> Reading symbols for shared libraries . done
>>> Reading symbols for shared libraries + done
>>> 2010-07-08 14:15:20.218 Python[60899:d13] *** __NSAutoreleaseNoPool():
>>> Object 0x1048a86d0 of class NSCFNumber autoreleased with no pool in place -
>>> just leaking
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries ++ done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Reading symbols for shared libraries + done
>>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>>> Reason: KERN_INVALID_ADDRESS at address: 0x00300040
>>> agg::pod_bvector, 6u>::~pod_bvector
>>> (this=0x7fff5fbf8130) at agg_array.h:521
>>> 521pod_allocator::deallocate(*blk, block_size);
>>> #---
>>> and the first few lines of the traceback are here:
>>> #---
>>> #0 agg::pod_bvector, 6u>::~pod_bvector
>>> (this=0x7fff5fbf8130) at agg_array.h:521
>>> #1 0x000101795b65 in ~vertex_sequence [inlined] () at
>>> /Users/Tony/python/devel/mpl/agg24/include/agg_vertex_sequence.h:525
>>> #2 0x000101795b65 in agg::vcgen_stroke::~vcgen_stroke
>>> (this=0x7fff5fbf80c8) at agg_vcgen_stroke.h:32
>>> #3 0x00011a45ea07 in ~rasterizer_cells_aa [inlined] () at
>>> kiva_graphics_context.h:410
>>> #4 0x00011a45ea07 in ~rasterizer_scanline_aa [inlined] () at
>>> /Users/Tony/python/devel/enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h:101
>>> #---
>>> I posted the full traceback on pastebin: http://pastebin.com/ViefksDC
>>> Are there conflicting versions of agg?
>>>
>> Could be -- we both use 2.4 but Maxim was somewhat infamous for doing
>> several 2.4 release without changing any version numbers. Can you
>> diff the two agg_rasterizer_cells_a.h files? The problems could lie
>> in a different file, but this would be a start. You might recursively
>> diff the src dirs as well.
>>
> We also have some custom changes in the matplotlib tree -- because upstream
> agg 2.4 is basically closed.
>
> Mike
>
I've attached a diff of the file you suggested, John.There's a pretty
significant output when diff-ing recursively. It doesn't sound like there's
much to be done about this issue if matplotlib and enthought are using
different versions of Agg (assuming this difference is actually the cause of
the segfault).
In any case, I'll just refactor my code so that I don't run into this conflict.
Thanks,
-Tony
$ diff -b mpl/agg24/include/agg_rasterizer_cells_aa.h
enthought/Enable/enthought/kiva/agg/agg-24/include/agg_rasterizer_cells_aa.h32,33d31
< #include "CXX/Exception.hxx"
< #include
38a37
>
40a40
>
52c52
< cell_block_limit = 4096
---
> cell_block_limit = 1024
186,194c186
< if(m_num_blocks >= cell_block_limit) {
< static Py::Exception e(
< Py::OverflowError(
< "Agg rendering complexity exceeded. Consider
downsampling or decimating your data."));
<
< /* If this exception is thrown too often, one can
<increase cell_block_limit */
< throw e;
< }
---
> if(m_num_blocks >= cell_block_limit) return;
654a647
>
678,679d670
< i = m_num_cells & cell_block_mask;
< if (i) {
680a672
> i = m_num_cells & cell_block_mask;
686d677
< }
713,714d703
< i = m_num_cells & cell_block_mask;
< if (i) {
715a705
> i = m_num_cells & cell_block_mask;
723d712
< }
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Setting dpi in savefig has unexpected results for PDFs
I recently noticed that setting the dpi for savefig doesn't work as expected
when saving to pdf. Take the following code, for example:
>>> import matplotlib.pyplot as plt
>>>
>>> plt.figure(figsize=(8,6))
>>> plt.plot([1,2])
>>> plt.savefig('test.png', dpi=100)
>>> plt.savefig('test.pdf', dpi=100)
The resulting png file is 800 x 600 (as expected), while the pdf file is 576 x
432 [which is (800 x 600) * 72/100]. I found an old thread suggesting that a
dpi of 72 should be hard coded into the PDF renderer for compatibility with
older versions of the PDF spec. That makes sense; however, it'd be nice if the
docstring for savefig told users about his behavior.
Below, is a patch to the savefig docstring. I'm sure someone else could word
this better, but I thought I'd at least try.
Best,
-Tony
P.S. maybe enough time has passed that most people have adopted PDF
viewers/parsers using PDF >= 1.6, and this hard-coded dpi could be removed?
Just a thought.
Index: lib/matplotlib/figure.py
===
--- lib/matplotlib/figure.py(revision 8561)
+++ lib/matplotlib/figure.py(working copy)
@@ -1018,7 +1018,10 @@
*dpi*: [ None | scalar > 0 ]
The resolution in dots per inch. If *None* it will default to
-the value ``savefig.dpi`` in the matplotlibrc file.
+the value ``savefig.dpi`` in the matplotlibrc file. NOTE: when
+saving to pdf, the dpi will not affect the page dimensions (which
+is always 72 dpi), but it will affect the resolution of rasterized
+elements in the plot.
*facecolor*, *edgecolor*:
the colors of the figure rectangle
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Setting dpi in savefig has unexpected results for PDFs
On Jul 16, 2010, at 4:08 PM, Eric Firing wrote:
> On 07/16/2010 09:45 AM, Tony S Yu wrote:
>> I recently noticed that setting the dpi for savefig doesn't work as
>> expected when saving to pdf. Take the following code, for example:
>>
>>>>> import matplotlib.pyplot as plt
>>>>>
>>>>> plt.figure(figsize=(8,6))
>>>>> plt.plot([1,2])
>>>>> plt.savefig('test.png', dpi=100)
>>>>> plt.savefig('test.pdf', dpi=100)
>>
>> The resulting png file is 800 x 600 (as expected), while the pdf file is
>> 576 x 432 [which is (800 x 600) * 72/100]. I found an old thread
>
> No, 576 x 432 is the paper size in points, not dots, so it is 8x6 inches
> as requested. Since the content is all vector-based, there is no notion
> of dots or pixels in test.pdf.
[snip]
>>
>> P.S. maybe enough time has passed that most people have adopted PDF
>> viewers/parsers using PDF >= 1.6, and this hard-coded dpi could be
>> removed? Just a thought.
>
> No; I think the present behavior is correct, regardless of the pdf
> version. It is not really a hard-coded dpi at all, it is a confusing
> aspect of the way mpl uses variables called "dpi". (But someone who
> knows more about pdf may correct me if necessary.)
>
> Eric
Hmm, that makes sense.
I was just confused by the fact that some programs use points as dots or pixels
when displaying to screen. For example, that's how my presentation software
chooses to display embedded PDFs. As a result, an 8in x 6in PNG shows up as a
different size than an 8in x 6in PDF. (Yes, you can resize, but this screws up
all the font sizes). Anyway, I guess this is more an issue with my presentation
software than anything else.
Thanks for the clarification, Eric.
-Tony
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] tight subplot parameters
Unused whitespace is a pet-peeve of mine, so I tend to use bbox_inches='tight' when saving figures. However, when producing publications, I want figures with a very specific size (i.e., fit column width of page), but calling bbox_inches='tight' changes the figure size. Stretching to fit is out of the question (screws up the font sizes). Anyway, I coded up a way to automatically choose values for subplots_adjust. My main goal was to tighten the borders (top, bottom, left, right). Nevertheless, I ended up coding up a solution to automatically adjust 'hspace' and 'wspace'. Just curious if there's any interest in adding this functionality. Cheers, -Tony Code Notes: - * The code to tighten the subplot spacing only works for regular grids: not with subplots that span multiple columns/rows. * The code to tighten up the borders is short and fairly intuitive, but the code for subplot spacing is pretty messy (mainly because wspace/hspace depends on the border spacing and the number of rows/columns). * The code draws the figure twice to calculate subplot parameters (not sure if this is a big issue, but I thought it was worth mentioning). * Just execute the file to plot some examples with random label sizes to demonstrate subplot adjustment. import numpy as np import matplotlib.pyplot as plt from matplotlib.transforms import TransformedBbox, Affine2D PAD_INCHES = 0.1 def tight_layout(pad_inches=PAD_INCHES, h_pad_inches=None, w_pad_inches=None): """Adjust subplot parameters to give specified padding. Parameters -- pad_inches : float minimum padding between the figure edge and the edges of subplots. h_pad_inches, w_pad_inches : float minimum padding (height/width) between edges of adjacent subplots. Defaults to `pad_inches`. """ if h_pad_inches is None: h_pad_inches = pad_inches if w_pad_inches is None: w_pad_inches = pad_inches fig = plt.gcf() tight_borders(fig, pad_inches=pad_inches) # NOTE: border padding affects subplot spacing; tighten border first tight_subplot_spacing(fig, h_pad_inches, w_pad_inches) def tight_borders(fig, pad_inches=PAD_INCHES): """Stretch subplot boundaries to figure edges plus padding.""" # call draw to update the renderer and get accurate bboxes. fig.canvas.draw() bbox_original = fig.bbox_inches bbox_tight = _get_tightbbox(fig, pad_inches) # figure dimensions ordered like bbox.extents: x0, y0, x1, y1 lengths = np.array([bbox_original.width, bbox_original.height, bbox_original.width, bbox_original.height]) whitespace = (bbox_tight.extents - bbox_original.extents) / lengths # border padding ordered like bbox.extents: x0, y0, x1, y1 current_borders = np.array([fig.subplotpars.left, fig.subplotpars.bottom, fig.subplotpars.right, fig.subplotpars.top]) left, bottom, right, top = current_borders - whitespace fig.subplots_adjust(bottom=bottom, top=top, left=left, right=right) def _get_tightbbox(fig, pad_inches): renderer = fig.canvas.get_renderer() bbox_inches = fig.get_tightbbox(renderer) return bbox_inches.padded(pad_inches) def tight_subplot_spacing(fig, h_pad_inches, w_pad_inches): """Stretch subplots so adjacent subplots are separated by given padding.""" # Zero hspace and wspace to make it easier to calculate the spacing. fig.subplots_adjust(hspace=0, wspace=0) fig.canvas.draw() figbox = fig.bbox_inches ax_bottom, ax_top, ax_left, ax_right = _get_grid_boundaries(fig) nrows, ncols = ax_bottom.shape subplots_height = fig.subplotpars.top - fig.subplotpars.bottom if nrows > 1: h_overlap_inches = ax_top[1:] - ax_bottom[:-1] hspace_inches = h_overlap_inches.max() + h_pad_inches hspace_fig_frac = hspace_inches / figbox.height hspace = _fig_frac_to_cell_frac(hspace_fig_frac, subplots_height, nrows) fig.subplots_adjust(hspace=hspace) subplots_width = fig.subplotpars.right - fig.subplotpars.left if ncols > 1: w_overlap_inches = ax_right[:,:-1] - ax_left[:,1:] wspace_inches = w_overlap_inches.max() + w_pad_inches wspace_fig_frac = wspace_inches / figbox.width wspace = _fig_frac_to_cell_frac(wspace_fig_frac, subplots_width, ncols) fig.subplots_adjust(wspace=wspace) def _get_grid_boundaries(fig): """Return grid boundaries for bboxes of subplots Returns --- ax_bottom, ax_top, ax_left, ax_right : array bbox cell-boundaries of subplot grid. If a subplot spans cells, the grid boundaries cutting through that subplot will be masked. """ nrows, ncols, n = fig.axes[0].get_geometry() # Initialize boundaries as masked arrays; in the future, support subplots # that span multiple rows/columns, which would have masked values for grid # boundaries that cu
Re: [matplotlib-devel] tight subplot parameters
On Jul 21, 2010, at 11:26 PM, John Hunter wrote: > On Wed, Jul 21, 2010 at 10:09 PM, Tony S Yu wrote: >> Wow, I don't see that at all. I'm on OS X, mpl svn HEAD (r8567), and Qt4Agg. >> I don't have GTK installed, so unfortunately, I can't really do a proper >> comparison. Here's the output I get from your modified script. I get >> something similar with TkAgg (unfortunately, I get an AttributeError with >> the macosx backend). > > Works on my system for tkagg and qtagg4, so the bug appears gtkagg > specific. Must be something in the draw vs window realized and sized > pipeline. It appears you are getting some bogus size info.Wonder > if connecting to the draw_event might help here (longshot) or if any > any of Eric's recent work on show is impacting th behavior here. Well, since I don't have access to GTK, it's not really something I can debug (kind of a cop out, I know). Your original GTK image is really strange: it seems as though the script moves the ticks, axis labels, and titles relative to their associated axes-frame. But the only function I use to affect the plot spacing is Figure.subplots_adjust (everything else in the script serves to calculate appropriate spacing-values). I don't think Figure.subplots_adjust is designed to move the ticks/axis-labels/titles relative to its own axes, right? -Tony -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] tight subplot parameters
On Jul 22, 2010, at 8:59 AM, John Hunter wrote: > On Thu, Jul 22, 2010 at 7:40 AM, Michiel de Hoon wrote: > >> Is a backend required to implement a get_renderer method? I only see it >> implemented in backend_agg.py, and it's missing in backend_bases.py, >> backend_template.py, backend_cairo.py, and in the macosx backend. If you >> want to try your code with the macosx backend, you can use >> fig.canvas.renderer instead of fig.canvas.get_renderer(). > > According to backend_bases.FigureCanvas, a renderer attr is not > guaranteed either. > The Agg* backends rely on get_renderer so that they can get a properly > sized renderer on figure resizes, dpi changes, etc. We could handle > this on the agg side with a property, or require all canvases to > supply get renderer. > > The tricky bit is that renderers may not be available until draw time > for some backends, and thus may not have proper size information if > accessed too early (this is probably at the heart of the gtk bug we > are seeing). It is probably a good idea to settle on something so > developers can get access to the renderer in a consistent state, and > this might require support a "raise_event" which one could connect to > and get the figure as soon as it is raised (which would be triggered > on canvas creation for non gui backends presumably and after the > window is raised for gui backends). In the callback, accessing > canvas.renderer or canvas.get_renderer would return a renderer with > proper sizing. > > JDH Sorry, I don't know much about how the backends are structured. But this talk of backends got me thinking: Since the Agg backend (non-GUI version) is guaranteed to be installed (correct?), you could create an Agg renderer, and just use that to calculate all the sizing information. This experiment worked for all GUI backends on my system (Qt4Agg, TkAgg, MacOSX). Are there any downsides to using Agg to calculate sizing info and then rendering again on a GUI backend? Performance issues? I guess it's possible differences in sizing between backends will show up in the resized subplots, but these differences should be small, right? -Tony P.S. I've removed calls to "subplots" in example code for easier testing. import numpy as np import matplotlib.pyplot as plt from matplotlib.backends.backend_agg import RendererAgg from matplotlib.transforms import TransformedBbox, Affine2D PAD_INCHES = 0.1 def tight_layout(pad_inches=PAD_INCHES, h_pad_inches=None, w_pad_inches=None): """Adjust subplot parameters to give specified padding. Parameters -- pad_inches : float minimum padding between the figure edge and the edges of subplots. h_pad_inches, w_pad_inches : float minimum padding (height/width) between edges of adjacent subplots. Defaults to `pad_inches`. """ if h_pad_inches is None: h_pad_inches = pad_inches if w_pad_inches is None: w_pad_inches = pad_inches fig = plt.gcf() renderer = RendererAgg(fig.get_figwidth(), fig.get_figheight(), fig.get_dpi()) tight_borders(fig, renderer, pad_inches=pad_inches) # NOTE: border padding affects subplot spacing; tighten border first tight_subplot_spacing(fig, renderer, h_pad_inches, w_pad_inches) def tight_borders(fig, renderer, pad_inches=PAD_INCHES): """Stretch subplot boundaries to figure edges plus padding.""" # call draw to update the renderer and get accurate bboxes. fig.draw(renderer) bbox_original = fig.bbox_inches bbox_tight = fig.get_tightbbox(renderer).padded(pad_inches) # figure dimensions ordered like bbox.extents: x0, y0, x1, y1 lengths = np.array([bbox_original.width, bbox_original.height, bbox_original.width, bbox_original.height]) whitespace = (bbox_tight.extents - bbox_original.extents) / lengths # border padding ordered like bbox.extents: x0, y0, x1, y1 current_borders = np.array([fig.subplotpars.left, fig.subplotpars.bottom, fig.subplotpars.right, fig.subplotpars.top]) left, bottom, right, top = current_borders - whitespace fig.subplots_adjust(bottom=bottom, top=top, left=left, right=right) def tight_subplot_spacing(fig, renderer, h_pad_inches, w_pad_inches): """Stretch subplots so adjacent subplots are separated by given padding.""" # Zero hspace and wspace to make it easier to calculate the spacing. fig.subplots_adjust(hspace=0, wspace=0) fig.draw(renderer) figbox = fig.bbox_inches ax_bottom, ax_top, ax_left, ax_right = _get_grid_boundaries(fig, renderer) nrows, ncols = ax_bottom.shape subplots_height = fig.subplotpars.top - fig.subplotpars.bottom if nrows > 1: h_overlap_inches = ax_top[1:] - ax_bottom[:-1] hspace_inches = h_overlap_inches.max() + h_pad_inches hspace_fig_frac = hspace_inches / figbox.height
Re: [matplotlib-devel] tight subplot parameters
On Jul 22, 2010, at 10:07 AM, John Hunter wrote: > On Thu, Jul 22, 2010 at 8:57 AM, Tony S Yu >>> According to backend_bases.FigureCanvas, a renderer attr is not >>> guaranteed either. >>> The Agg* backends rely on get_renderer so that they can get a properly >>> sized renderer on figure resizes, dpi changes, etc. We could handle >>> this on the agg side with a property, or require all canvases to >>> supply get renderer. > > No, this won't work because the sizing information depends on the GUI > window size. Agg adapts the renderer to the GUI window size. So in > GTKAgg we are using the Agg renderer, but GTK is determining the > window size when it is raised. We try to get GTK to produce a canvas > of a fixed size, but cannot guarantee it so we reset the renderer size > in necessary when the canvas is raised. > > JDH I'm not sure if I understand. Are you talking about responding to window resizing events, or are you saying that Figure.get_height/get_width don't match the window size for some GUI backends? I create the Agg renderer based on Figure.get_height/get_width. If the window is resized, then the layout would definitely change, but you could call `tight_layout` again to adjust subplot spacing (which would create a new Agg renderer based on the new window size). Am I missing something here? Were you thinking I wanted to interactively adapt the spacings? (If that's the case, I wasn't that ambitious.) -Tony -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Exploring
On Jul 30, 2010, at 10:54 AM, Damon McDougall wrote:
> Hi,
>
> I'm interested in fiddling around with the matplotlib source. Let's say we
> set up various things:
>
> from matplotlib.figure import Figure()
> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
>
> fig = Figure()
> canvas = FigureCanvas(fig)
> ax = fig.add_subplot(1, 1, 1)
> fig.savefig('asd.pdf', bbox_inches='tight')
>
> I would like to know what exactly happens when bbox_inches='tight' is passed
> to savefig(). I've been searching in the figure.py source and nowhere can I
> see the bbox_inches='tight' keyword being tested for in the savefig() method.
> Having said that, all of the kwargs do get passed on to the
> canvas.print_figure() method, so I looked in the backend_pdf.py file but
> couldn't find a print_figure() method. Could someone point me in the right
> direction?
>
> Regards,
> -- Damon
That's funny: I was just looking at bbox_inches='tight' recently. You'll find
the relevant section in matplotlib.backend_bases.print_figure.
Best,
-Tony
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Exploring
On Jul 30, 2010, at 8:04 PM, Jae-Joon Lee wrote:
> I don't think this is just an issue of "bbox_inches" option. For
> example, if you create an axes of rect=[0,0,1,1] and save the figure
> (w/o bbox_inches option), you will see a similar behavior.
> Also, I believe that the result depends on the backends.
>
> I think this kind of issue is quite difficult to resolve and I doubt
> if this will be solved anytime soon.
> Any contribution will be very much appreciated.
>
> Regards,
>
> -JJ
I think this clipping issue is caused by a figure size that's one pixel larger
than the actual canvas. Here's the example that Jae-Joon suggested:
>>> import matplotlib.pyplot as plt
>>>
>>> fig = plt.figure(figsize=(8, 6), dpi=100)
>>> plt.axes([0, 0, 1, 1])
>>> print fig.transFigure.transform((0, 0))
>>> print fig.transFigure.transform((1, 1))
>>> plt.savefig('clipped_right_and_bottom_edge')
The saved figure is 800x600 pixels, and the right and bottom edge are clipped.
Also, notice that the figure coordinate (0, 0) gets transformed to (0, 0) in
pixel space (display space?), while the figure coordinate (1, 1) gets
transformed to (800, 600) in pixel space. But, a figure that includes a point
at (0, 0) and (800, 600) would have to be at least 801x601 in size.
The strange part is that the origin of the figure space is the bottom-left, but
the image gets clipped at the bottom and right edges. I would have expected the
bottom-and-left edges *or* the top-and-right edges to be clipped.
Best,
-Tony
>
>
> On Sat, Jul 31, 2010 at 5:48 AM, Damon McDougall
> wrote:
>> Aha! Even without the text, i.e. setting label1On = False for all the major
>> ticks, the behaviour I see is that with bbox_inches = 'tight' and pad_inches
>> = 0.0 I get the saved figure which includes the black border line for the
>> bottom and left edges, but not the top and right edges. This may have
>> something to do with it. Maybe it's an issue with the bounding box not being
>> 'inclusive' and leaving out the end points?
>>
>> Regards,
>> -- Damon
>>
>> --
>> Damon McDougall
>> Mathematics Institute
>> University of Warwick
>> Coventry
>> CV4 7AL
>> [email protected]
>>
>>
>>
>> On 30 Jul 2010, at 20:33, Eric Firing wrote:
>>
>>> On 07/30/2010 06:32 AM, Damon McDougall wrote:
Hmm, it seems as though tick labels get clipped on the top and on the
right when passing bbox_inches='tight' and pad_inches=0.0. I wouldn't
expect this behaviour. Is there perhaps a bug in Bbox.union that's causing
this?
>>>
>>> Not likely. Much more likely is a problem in calculating the rendered
>>> size of the text.
>>>
>>> Eric
>>>
Regards,
-- Damon
--
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
[email protected]
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] bug? line misses points with negative coordinates
On Sep 3, 2010, at 10:23 AM, Sébastien Barthélemy wrote:
> CC to matplotlib-devel & matplotlib-users
>
> 2010/9/3 Tony S Yu :
>> On Sep 3, 2010, at 4:33 AM, Sébastien Barthélemy wrote:
>>
>>> Hello,
>>>
>>> While using sage [1], I got problems drawing a line: for some reason,
>>> the points with negative coordinates are not plotted (or are plotted
>>> on top of others due to an offset problem and thus I cannot see them).
>>> I can only reproduce the bug with specific data sets.
>>>
>>> [1] www.sagemath.org
>>>
>>> I think I could track down the bug to matplotlib, which sage uses to
>>> render 2d plots.
>>>
>>> I included a sage script which generates the data set (in a pickle
>>> file), and a python script which draws the faulty line.
>>>
>>> Usage is :
>>>
>>> $ sage generate_data.sage
>>> $ python test_mpl.py
>>>
>>> I also included the pickled data, thus you don't need sage at all.
>>> I use matplotlib 1.0.0 for python 2.6 on mac os (as provided by macport).
>>>
>>> Could somebody here confirm the problem, and give me a hint about what
>>> is going on?
>>
>> I can confirm the issue.
>
> Great, thank you. I filed a bug:
> https://sourceforge.net/tracker/?func=detail&aid=3058804&group_id=80706&atid=560720
>
>> This appears to be a drawing bug: when I pan the drawing so that the
>> negative data touches the edge of the axes frame, the rest of the line is
>> drawn. So the line object is being created, but for some reason it's not
>> being drawn correctly.
>>
>> The bug is really finicky: if I plot starting from the 3rd value of your
>> data (i.e. slice xdata, ydata with [2:]), the line is drawn completely. The
>> strange thing is that the first 100 or so data points defines the exact same
>> point, so there's noting special about those first two points. (but this
>> overlaying of data may be related to the bug)
>>
>> I've reproduced the issue on TkAgg, Qt4Agg, and MacOSX backends, so maybe
>> the bug is in backend_bases. (Note: unlike Agg backends, MacOSX backend
>> doesn't show line even after panning the plot)
>>
>> I don't really know how to debug drawing errors like this; so this is as far
>> as can get.
I'm not sure if I should respond to this email or the bug report, but since I
made the claim here, I'll correct myself here: The bug is not in the drawing
code as I had suggested.
The bug is related to path simplification. If you turn off path simplification
(e.g. plt.rc('path', simplify=False), the line is drawn in its entirety. This
also explains why the bug disappeared when I trimmed the first two points: path
simplification is triggered from data sets with atleast 128 points (your data
has 129, so trimming two points turned off path simplification).
I just wanted to correct my earlier comments.
-T
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Turning off the frame/border
On Sep 29, 2010, at 1:06 PM, Jeremy Lounds wrote: > Hello again, > > I am not sure if this is a matplotlib question, or a basemap one. The > sample code I found on Google for this either broke my script or > didn't change the end result. > > I am attempting to turn the border (frame?) off altogether. Here is > the script, with some sections kept out for brevity: I'm assuming you're talking about turning off the frame around each axes (but maybe you're talking about something else?). The "frameon" attribute in your example code alters the background of the figure canvas, not the borders surrounding each axes. There's probably a shorter way, but I have a small function that I use to turn off the frame or border around an axes. def clear_frame(ax=None): if ax is None: ax = plt.gca() ax.xaxis.set_visible(False) ax.yaxis.set_visible(False) for spine in ax.spines.itervalues(): spine.set_visible(False) Best, -T -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Turning off the frame/border
On Sep 29, 2010, at 2:00 PM, Jeremy Lounds wrote: > On Wed, Sep 29, 2010 at 1:21 PM, Tony S Yu wrote: >> >> On Sep 29, 2010, at 1:06 PM, Jeremy Lounds wrote: >> >>> I am attempting to turn the border (frame?) off altogether. Here is >>> the script, with some sections kept out for brevity: >> >> >> I'm assuming you're talking about turning off the frame around each axes >> (but maybe you're talking about something else?). The "frameon" attribute in >> your example code alters the background of the figure canvas, not the >> borders surrounding each axes. >> >> There's probably a shorter way, but I have a small function that I use to >> turn off the frame or border around an axes. >> >> def clear_frame(ax=None): >>if ax is None: >>ax = plt.gca() >>ax.xaxis.set_visible(False) >>ax.yaxis.set_visible(False) >>for spine in ax.spines.itervalues(): >>spine.set_visible(False) >> >> Best, >> -T > > Hi Tony, > > Thanks, that works pretty good! > > However... it seems that "drawcoastlines" creates a border if I am not > "zoomed out" far enough. (i.e., the coastline is out of bounds). > > Do you know how I could turn that off? > > Thanks again! > > ~ Jeremy I'm glad that worked for you. Unfortunately, I don't use basemap, so I can't really help with this additional complication. I'm sure someone else on the list will be able to help you out, though. Best, -Tony -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SourceForge.net: matplotlib: Modify: 2973874 - Text box, Save dialog for mac
On Oct 9, 2010, at 10:46 PM, Matthew Brett wrote: > Hi, > > On Sat, Oct 9, 2010 at 7:30 PM, Eric Firing wrote: >> https://sourceforge.net/tracker/?func=detail&aid=2973874&group_id=80706&atid=560720 >> >> Would someone with a Mac please look at this bug and say whether it is >> occurring with our release of mpl? If not, I will close the ticket. > > Not for me (python.org 2.6 32 bit, mpl 1.0.0) with the macosx backend > or the tkagg backend. I don't have a 64 bit python / matplotlib to > test with - maybe that's the trick? Or maybe it was for a different > backend? > > Best, > > Matthew Works fine on my system: python 2.6 64 bit (system install), mpl svn r8726 with macosx, tkagg, and qt4agg. Best, -Tony -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Repeated method definition in custom_projection_example.py
I was reading through custom_projection_example.py and I noticed that the cla() method was defined twice (with the exact same code) for the same class. Here's a patch with one of the cla() methods (the one with fewer comments) deleted. delete_cla_copy.diff Description: Binary data -Tony- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] spy: ignore zero values in sparse matrix
When sparse matrices have explicit zero values, `axes.spy` plots those
zero values. This behavior seems unintentional. For example, the
following code should have a main diagonal with markers missing in the
middle, but `spy` currently plots a full main diagonal.
#~~~
import scipy.sparse as sparse
import matplotlib.pyplot as plt
sp = sparse.spdiags([[1,1,1,0,0,0,1,1,1]], [0], 9, 9)
plt.spy(sp, marker='.')
#~~~
Below is a patch which only plots the nonzero entries in a sparse
matrix. Note, sparse matrices with all zero entries raises an error;
this behavior differs from dense matrices. I could change this
behavior, but I wanted to minimize the code changed.
Cheers,
-Tony
PS: this patch also includes two trivial changes to some examples.
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 6122)
+++ lib/matplotlib/axes.py (working copy)
@@ -6723,9 +6723,11 @@
else:
if hasattr(Z, 'tocoo'):
c = Z.tocoo()
-y = c.row
-x = c.col
-z = c.data
+nonzero = c.data != 0.
+if all(nonzero == False):
+raise ValueError('spy cannot plot sparse zeros
matrix')
+y = c.row[nonzero]
+x = c.col[nonzero]
else:
Z = np.asarray(Z)
if precision is None: mask = Z!=0.
Index: examples/pylab_examples/masked_demo.py
===
--- examples/pylab_examples/masked_demo.py (revision 6122)
+++ examples/pylab_examples/masked_demo.py (working copy)
@@ -1,4 +1,4 @@
-#!/bin/env python
+#!/usr/bin/env python
'''
Plot lines with points masked out.
Index: examples/misc/rec_groupby_demo.py
===
--- examples/misc/rec_groupby_demo.py (revision 6122)
+++ examples/misc/rec_groupby_demo.py (working copy)
@@ -2,7 +2,7 @@
import matplotlib.mlab as mlab
-r = mlab.csv2rec('data/aapl.csv')
+r = mlab.csv2rec('../data/aapl.csv')
r.sort()
def daily_return(prices):
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] spy: ignore zero values in sparse matrix
On Sep 26, 2008, at 2:28 PM, John Hunter wrote:
> On Fri, Sep 26, 2008 at 12:39 PM, Tony S Yu <[EMAIL PROTECTED]> wrote:
>
>> +if all(nonzero == False):
>> +raise ValueError('spy cannot plot sparse zeros
>> matrix')
>
> Is raising an exception the right choice here -- why can't we plot an
> all zeros image?
>
> JDH
I guess you could plot sparse all-zero matrices with image mode. My
only hesitation is that sparse arrays tend to be very large and (I
imagine) this would lead to very slow performance. I assumed this was
the reason image mode wasn't adapted to use sparse arrays.
Actually, now that I think about it: you could plot a trivially small
image and just adjust the coordinates so that they correspond to the
original matrix shape. Is this what you were thinking?
I should note that a dense zero array also fails to plot with spy *if
marker mode is used*.
-T
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] spy: ignore zero values in sparse matrix
On Sep 26, 2008, at 3:38 PM, John Hunter wrote: > On Fri, Sep 26, 2008 at 2:36 PM, Tony S Yu <[EMAIL PROTECTED]> wrote: >> >> Actually, now that I think about it: you could plot a trivially >> small image >> and just adjust the coordinates so that they correspond to the >> original >> matrix shape. Is this what you were thinking? > > This is something I considered, but I was thinking less about the > implementation and more about the functionality. I don't want to > raise an exception unless the input doesn't make sense. I would > rather the user start at a boring image and figure out why it is blank > that deal with an exception. Yeah, I agree this is much friendlier. >> I should note that a dense zero array also fails to plot with spy >> *if marker >> mode is used*. > > Can you fix this along with spy2? I assume you mean spy, not spy2 (I just searched through the matplotlib files and saw that spy2 hasn't existed since 2006). I'll work on a patch to return a blank plot using the method described above (unless someone chimes in with a better suggestion). -Tony - 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
