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 efir...@hawaii.edu wrote: https://sourceforge.net/tracker/?func=detailaid=2973874group_id=80706atid=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 Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net 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 tsy...@gmail.com 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 Matplotlib-devel@lists.sourceforge.net 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 tsy...@gmail.com:
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=detailaid=3058804group_id=80706atid=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
Matplotlib-devel@lists.sourceforge.net
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
d.mcdoug...@warwick.ac.uk 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
d.mcdoug...@warwick.ac.uk
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
d.mcdoug...@warwick.ac.uk
--
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
Matplotlib-devel@lists.sourceforge.net
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
Matplotlib-devel@lists.sourceforge.net
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 mjldeh...@yahoo.com 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 hspace =
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 tsyu80@ 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 Matplotlib-devel@lists.sourceforge.net 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 cut through the subplot.
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 tsy...@gmail.com 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 Matplotlib-devel@lists.sourceforge.net 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
Matplotlib-devel@lists.sourceforge.net
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
Matplotlib-devel@lists.sourceforge.net
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
Matplotlib-devel@lists.sourceforge.net
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 Matplotlib-devel@lists.sourceforge.net 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_bvectoragg::point_basedouble, 6u::~pod_bvector (this=0x7fff5fbf8130) at agg_array.h:521 521 pod_allocatorT::deallocate(*blk, block_size); #--- and the first few lines of the traceback are here: #--- #0 agg::pod_bvectoragg::point_basedouble, 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 Matplotlib-devel@lists.sourceforge.net 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 Yutsy...@gmail.com 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_bvectoragg::point_basedouble, 6u::~pod_bvector
(this=0x7fff5fbf8130) at agg_array.h:521
521pod_allocatorT::deallocate(*blk, block_size);
#---
and the first few lines of the traceback are here:
#---
#0 agg::pod_bvectoragg::point_basedouble, 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 exception
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
Matplotlib-devel@lists.sourceforge.net
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 string' 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
Matplotlib-devel@lists.sourceforge.net
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 string' requires string as left operand, not NoneType
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
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 Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net 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]x.shape[0]: -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net 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
Matplotlib-devel@lists.sourceforge.net
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 wst...@gmail.com Date: Sun, Sep 27, 2009 at 10:51 PM Subject: OS X 10.6 port To: sage-devel sage-de...@googlegroups.com, John Hunter jdh2...@gmail.com 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 BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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
Matplotlib-devel@lists.sourceforge.net
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 Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net 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=100url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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=100url=/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
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=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
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=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
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=100url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
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=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
