Re: [matplotlib-devel] spy: ignore zero values in sparse matrix

Tony S Yu wrote: > > 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 s

Re: [matplotlib-devel] memory leak: gtk.gdk.Pixbuf and gtk.gdk.GCX11 with gtkagg backend

Mátyás János wrote: > Hi, > > I'm looking for memory leaks in a python application and found leaks in > matplotlib. The application is graphic intensive. Each time it updates > the screen, matplotlib allocates another 5-10 megabytes memory for the > new gtk.gdk.Pixbuf and gtk.gdk.GCX11 while does

Re: [matplotlib-devel] spy: ignore zero values in sparse matrix

Tony S Yu wrote: > 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 >&g

[matplotlib-devel] Axes.add_line() is oddly slow?

I am getting very inconsistent timings when looking into plotting a line with a very large number of points. Axes.add_line() is very slow, and the time is taken by Axes._update_line_limits(). But when I simply run the latter, on a Line2D of the same dimensions, it can be fast. import matplotl

[matplotlib-devel] path simplification with nan (or move_to)

Mike, John, Because path simplification does not work with anything but a continuous line, it is turned off if there are any nans in the path. The result is that if one does this: import numpy as np xx = np.arange(20) yy = np.random.rand(20) #plot(xx, yy) yy[1000] = np.nan plot(xx, yy)

Re: [matplotlib-devel] path simplification with nan (or move_to)

Michael Droettboom wrote: Eric Firing wrote: Mike, John, Because path simplification does not work with anything but a continuous line, it is turned off if there are any nans in the path. The result is that if one does this: import numpy as np xx = np.arange(20) yy = np.random.rand

Re: [matplotlib-devel] path simplification with nan (or move_to)

ASAP--certainly it is for my own work, at least. What happens with a nan should be somewhat similar to what happens with clipping, so perhaps one could take advantage of part of the clipping logic, but I have not looked at this approach closely. Eric Eric Firing wrote: > Michael Droettboom wrote:

Re: [matplotlib-devel] path simplification with nan (or move_to)

Michael Droettboom wrote: > John Hunter wrote: >> On Wed, Oct 8, 2008 at 11:37 AM, Michael Droettboom <[EMAIL PROTECTED]> >> wrote: >> >> >>> I figured this out. When this happens, a RuntimeError("Agg rendering >>> complexity exceeded") is thrown. >>> >> Do you think it is a good idea to

Re: [matplotlib-devel] scatter and alpha settings

Gregor Thalhammer wrote: > Dear developers, > > in matplotlib 0.98.3 I discoverd that in scatter individual alpha > settings (by giving a list of rgba values) are ignered. Here an example > that show this behaviour: All points show the same alpha value as given > by the alpha keyword argument.

Re: [matplotlib-devel] Line Integral Convolution

Anne Archibald wrote: > Hi, > > First of all, matplotlib is a very nice piece of software - I use it > all the time for interactive data analysis, for posters, and for > published papers. > > For visualizing low-resolution vector fields, quiver() is quite nice. > But for high-resolution vector fi

Re: [matplotlib-devel] suggestion for the interpolation in imshow()

Andrew Hawryluk wrote: > The interpolation algorithm used in imshow() can produce spurious > results, as has been noted before: > > _http://article.gmane.org/gmane.comp.python.matplotlib.general/12062_ > > This happens because the data is converted to RGB before the > interpolation/resampling,

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6217] trunk/matplotlib/lib/matplotlib/axes.py

Manuel, Although it doesn't hurt, I don't think it is worthwhile changing range to xrange. From the 2.5 docs: xrange( [start,] stop[, step]) This function is very similar to range(), but returns an ``xrange object'' instead of a list. This is an opaque sequence type which yields the same v

Re: [matplotlib-devel] [Re]: kwarg "range" in hist

Manuel Metz wrote: > Please see the end of the mail for the important point !!! Thank you--I see you are way ahead of me on this. See comments below. > > Eric Firing wrote: >> Manuel, >> >> Although it doesn't hurt, I don't think it is worthwhile changing ra

Re: [matplotlib-devel] colormap clipping for large numbers (small vmax - vmin)

Tony S Yu wrote: > 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 >

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6288] trunk/matplotlib

[EMAIL PROTECTED] wrote: > Revision: 6288 > http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6288&view=rev > Author: jdh2358 > Date: 2008-10-21 15:26:22 + (Tue, 21 Oct 2008) > > Log Message: > --- > restored the support for multiple pyplots that I broke earlier >

[matplotlib-devel] doc build failure?

I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the docs. The Latex is failing with output ending in ) (/usr/share/texmf-texlive/tex/latex/graphics/graphicx.sty (/usr/share/texmf-texlive/tex/latex/graphics/graphics.sty (/usr/share/texmf-texlive/tex/latex/graphics/trig.sty) (/

Re: [matplotlib-devel] doc build failure?

John Hunter wrote: > On Tue, Oct 21, 2008 at 12:52 PM, Eric Firing <[EMAIL PROTECTED]> wrote: >> I did svn up on Sphinx, deleted mpl doc/build, and tried to rebuild the >> docs. The Latex is failing with output ending in >> >> ) (/usr/share/texmf-texlive/tex/lat

Re: [matplotlib-devel] problems with shared axis

Mark Bakker wrote: > Hello list (especially Erik, who can fix this I hope) - > > I have had problems with shared axes, especially when one of the axis > has an aspect ratio that is set 'equal'. It has been discussed on the > list before (mostly with Erik Firing), but it hasn't been fixed yet. >

Re: [matplotlib-devel] problems with shared axis

ything or help in any other way, >> >> Mark >> >> On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> Mark Bakker wrote: >> >> Hello list (especially Erik, who can fix

Re: [matplotlib-devel] problems with shared axis

Mark Bakker wrote: > Hello list (especially Erik, who can fix this I hope) - > > I have had problems with shared axes, especially when one of the axis > has an aspect ratio that is set 'equal'. It has been discussed on the > list before (mostly with Erik Firing), but it hasn't been fixed yet. >

Re: [matplotlib-devel] problems with shared axis

David Trem wrote: > Thank you very much Eric ! > > It basically works for me but I think there is still a small bug > related to sharing y axes. I attach a small script that reproduce the > problem. > The end of the related error message is the following: > > File "*/lib/python2.5/site-package

Re: [matplotlib-devel] problems with shared axis

y for my changes related to shared axes. Eric > > Mark > > On Fri, Oct 24, 2008 at 7:57 AM, Eric Firing <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Mark Bakker wrote: > > Hello list (especially Erik, who can fix this I hope) - >

Re: [matplotlib-devel] problems with shared axis

Mark Bakker wrote: > Dang, I looked at it, but so much has changed since 0.98.3 release that > I have little chance of getting any changes implemented. > Any plans for a new release that you know of? > Thanks, Mark None that I know of. It would certainly be nice if we had the release package-bu

Re: [matplotlib-devel] problems with shared axis

066&view=markup > > > > Mike > > John Hunter wrote: >> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <[EMAIL PROTECTED]> wrote: >> >> >>> None that I know of. It would certainly be nice if we had the release >>> package-building

Re: [matplotlib-devel] legend class with paddings in canvas unit

Jae-Joon Lee wrote: > John, > > The current legend class has following options given in axes units. > > pad, labelsep, handlelen, hadletextsep, axespad > > Eric introduced borderpad (given as a fraction of the font size), > which replaces "pad". > One way is to introduce new names for all of a

[matplotlib-devel] logo example plots are wrong

John, Something really went haywire on this example: http://matplotlib.sourceforge.net/examples/pylab_examples/logo.html It works on my machine, so I don't know why the version on the web site is wrong. Eric - This SF.Ne

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6385] trunk/matplotlib/lib/matplotlib/cbook.py

[EMAIL PROTECTED] wrote: > Revision: 6385 > http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev > Author: ryanmay > Date: 2008-11-10 18:59:18 + (Mon, 10 Nov 2008) > > Log Message: > --- > Make iterable() and is_string_like() return True/False instead of

Re: [matplotlib-devel] SF.net SVN: matplotlib:[6385] trunk/matplotlib/lib/matplotlib/cbook.py

Ryan May wrote: > Eric Firing wrote: >> [EMAIL PROTECTED] wrote: >>> Revision: 6385 >>> >>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev >>> Author: ryanmay >>> Date: 2008-11-10 18:59:18 + (Mon,

Re: [matplotlib-devel] Help with scatter

Ryan May wrote: Ryan May wrote: Well, I can get the last one to work with SVN HEAD. The others don't work for me either, though I agree they probably should. It looks like any 1D sequence will trigger colormapping instead of strings being mapped to rgba arrays. I'll keep digging to see what c

Re: [matplotlib-devel] Help with scatter

Ryan May wrote: > On Mon, Nov 10, 2008 at 5:54 PM, Eric Firing <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Ryan May wrote: > > Ok, here's a patch that fixes the problem for me, as well as a test > script that tests a

[matplotlib-devel] modification of update_path_extents?

Mike, A bug was recently pointed out: axhline, axvline, axhspan, axvspan mess up the ax.dataLim. I committed a quick fix for axhline and axvline, but I don't think that what I did is a good solution, so before doing anything for axhspan and axvspan I want to arrive at a better strategy. What

Re: [matplotlib-devel] modification of update_path_extents?

Michael Droettboom wrote: > > Eric Firing wrote: >> Mike, >> >> A bug was recently pointed out: axhline, axvline, axhspan, axvspan >> mess up the ax.dataLim. I committed a quick fix for axhline and >> axvline, but I don't think that what I did is a go

Re: [matplotlib-devel] modification of update_path_extents?

>> if (x > 0.0 && x < *xm) *xm = x; >> if (y > 0.0 && y < *ym) *ym = y; >> } >> } >> >> >> In the last 2 lines, why are xm and ym being clipped at 0, when x0 and >> y0 are not? > xm and ym are the minimum positive values, used for log scales. > Definitely worth a comment. I

Re: [matplotlib-devel] svg.image_noscale and others

Jozef Vesely wrote: > Hello matplotlib developers, > > I have implemented "svg.image_noscale" feature for ps and pdf backends. I > think > that resampling/scaling should be avoided, when vector format can scale image > itself. It seems to me best if there is an option to scale or not; depending

Re: [matplotlib-devel] Bug in pylab.date2num

vschmidt wrote: > I'm hoping you can help me confirm/deny a bug in pylab's date2num() function. > > My assumption (this may be wrong) is that this function is meant to be > compatible with the MATLAB function date2num(). However, in ipython I can > execute: > > - > import datetime > impo

[matplotlib-devel] transforms bug: axhline with log y scale

Mike (or other transforms afficionados), The thread "[Matplotlib-users] Bug saving semilogy plots with a axvline" started by [EMAIL PROTECTED] pointed to a bug that appears to be deep in the transforms code. My head is spinning. The problem seems to be related to the propagation of the _inval

Re: [matplotlib-devel] transforms bug: axhline with log y scale

Mike, This is a gentle check--I suspect my original message, below, may have slipped under the radar. Eric Eric Firing wrote: > Mike (or other transforms afficionados), > > The thread "[Matplotlib-users] Bug saving semilogy plots with a axvline" > started by [EMAIL P

Re: [matplotlib-devel] transforms bug: axhline with log y scale

Michael Droettboom wrote: > Thanks for the reminder. It wasn't propagating the "non-affine" > invalidation correctly. I think I have a fix in r6465, but please let > me know if you see anything else funny. > > Cheers, > Mike Mike, It looks like that helps, fixing the window resize behavior,

Re: [matplotlib-devel] transforms bug: axhline with log y scale

zoom button, panning or zooming moves the plotted curve, but the axvline stays in the middle of the picture instead of moving with the x=0.5 point. Same with zoom-to-rect: the axvline stays in the middle of the window, not at x=0.5. Eric > > Mike > > Eric Firing wrote: >> Mi

Re: [matplotlib-devel] transforms bug: axhline with log y scale

sion, which doesn't matter at all for the uses to which I put it. Possibly it will catch up soon: http://www.selenic.com/mercurial/wiki/index.cgi/HgSubversion http://blog.red-bean.com/sussman/?p=116 Eric > > Mike > > Eric Firing wrote: >> Michael Droettboom wrote: >&g

Re: [matplotlib-devel] pyplot.fill() and masked arrays

Ryan May wrote: > Hi, > > Is there any reason pyplot.fill() doesn't support masked arrays? Or was it > just > overlooked? > I think the reason is that it is not obvious what any filled region with masked vertices should look like. Eric --

Re: [matplotlib-devel] pyplot.fill() and masked arrays

Ryan May wrote: > Ryan May wrote: >> Hi, >> >> Is there any reason pyplot.fill() doesn't support masked arrays? Or was >> it just overlooked? > > Looks like this is better handled by fill_between, nevermind. > > Now, what about dates? I'm having problems using dates for the x-axis for > fill_

Re: [matplotlib-devel] CHANGELOG tabs

Ryan May wrote: > Hi, > > It looks like some tabs have crept into the CHANGELOG file. Is anyone > opposed to > me changing them to the equivalent (8) spaces? It messes up my editor, which > is > set to display them as 4 spaces, and makes it think that tabs are the proper > way > to indent.

Re: [matplotlib-devel] Loss of filled vs. stroked distinction by Collections

Eric Bruning wrote: > I think of artists as having visual properties that persist (e.g., > filled vs. outlined, a colormap with min and max values) even as data > associated with the artist is changed. In the edge case described > below, this doesn't seem to hold true. > > I have code that animate

[matplotlib-devel] polar plotting and theta wrapping

Mike, Jan, The thread http://www.mail-archive.com/[email protected]/msg08342.html culminated in changeset r6106, which seemed to fix the immediate problem, but in fact introduced a major bug: polar plotting was broken for lines or patches with angles crossing zero. The rea

Re: [matplotlib-devel] polar plotting and theta wrapping

Michael Droettboom wrote: > Eric Firing wrote: >> Mike, Jan, >> >> Any attempt to normalize the angles to a fixed range of length 2 pi >> inside of mpl is sure to wreck valid user code; it merely moves the >> trouble spot to a different angle. > Thanks for cat

Re: [matplotlib-devel] contour plots & linestyles

Manuel Metz wrote: > Hi, > I just noted a strange behavior of contour(). When a contour plot is > created with negative values and using a single color instead of a cmap, > contour _always_ uses the contour.negative_linestyle, even if linestyles > are specifically provided: > > x = linspace(-p

Re: [matplotlib-devel] Problem with pan/ZOOM on semilog plot

John Hunter wrote: > On Sat, Jan 10, 2009 at 12:28 PM, David Trem wrote: >> Hi, >> >> I've just discover a problem with the pan/zoom tool. >> When using the pan/zoom tool (in the toolbar) on a semilogy plot the >> zoom does not work correctly. >> To visualize the problem launch the small script i

[matplotlib-devel] pruning the codebase

While trying to track down the zoom bug reported by David Trem, I got all tangled up in what appear to be completely obsolete and unneeded "zoom" etc. methods. These are left over from the original NavigationToolbar and the pre-transforms code. I would like to see all of this, including the e

[matplotlib-devel] refactoring for units; was Re: John: Thoughts on a standard test system

John Hunter wrote: > On the issue of units (not unit testing but unit support which is > motivating your writing of unit test) I think we may need a new > approach. The current approach is to put unitized data into the > artists, and update the converted data at the artist layer. I don't > know

Re: [matplotlib-devel] [SciPy-user] recursion limit in plot

Ryan May wrote: > Ok, my debugging tells me the problem comes down to the units support, > specifically this code starting at line 130 in units.py: > > if converter is None and iterable(x): > # if this is anything but an object array, we'll assume > # there are no

Re: [matplotlib-devel] units/ example scripts

John Hunter wrote: [...] > > The code is trying to add a non-unitized quantity (eg an errorbar > width but just guessing) of int type with a unitized quantity > TaggedValue (this is from the mockup basic_units testing package). > You'd have to dig a little bit to find out where the non-unitized >

Re: [matplotlib-devel] svnmerge broken?

John Hunter wrote: > After reading in a separate thread that Eric was having trouble with > svnmerge, I gave it a try and got > > jdhun...@uqbar:mpl> svnmerge.py merge v0_98_5_maint > svnmerge: "v0_98_5_maint" is not a subversion working directory > > Maybe our svn merge guru (MD) could take

Re: [matplotlib-devel] svnmerge broken?

v0_98_5_maint > > I just tested a change to the branch followed by a merge and everything > seems to be working fine here. > > Eric Firing wrote: >> John Hunter wrote: >> svnmerge init >> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/v0_98_5_

Re: [matplotlib-devel] set_aspect with shared axes

Ryan May wrote: > Hi, > > Does anyone know why set_aspect('equal', 'box') isn't accepted on shared axes? > I'm trying to make the following type of scenario work: Ryan, Mark Bakker keeps asking about this, too. I have never been able to figure out an algorithm, consistent with the present mpl

Re: [matplotlib-devel] Line2D.set_pickradius missing in svn

Martin Spacek wrote: > Hi, > > I just updated my checkout to rev 6829, and it seems > lines.Line2D.set_pickradius > has been renamed to setpickradius. Is this a typo? get_pickradius still > exists. > This is on line 318 in lines.py. Renaming it back to set_pickradius seems > make > it work t

Re: [matplotlib-devel] gtk backend silently ignores all exceptions

John Hunter wrote: > On Mon, Jan 26, 2009 at 6:02 PM, Jae-Joon Lee wrote: >> Michael, >> >> It seems that the gtk backend in the current svn silently ignores ALL >> exceptions raised during the drawing. >> >> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/b

Re: [matplotlib-devel] Updated units.ConversionInterface

James Evans wrote: > All, > > I have just submitted an updated units.ConversionInterface. For each of the > static methods it now takes the invoking Axis instance > as a parameter. I have updated the appropriate calling functions. This > allows the DateConverter to now guarantee that the defa

[matplotlib-devel] broken examples/units/*

James, The scripts in examples/units (and run by backend_driver.py) are broken; they have not been updated to match your addition of the new mandatory axis argument to convert() and default_units(). Would you fix them, please? (While you are in the neighborhood, you might also update the met

Re: [matplotlib-devel] Can we retire numerix?

Chris Barker wrote: > Hi all, > > I just ran into an issue with py2exe -- my app failed because various > numpy sub-packages weren't included. However, I wasn't using them. But > it failed because numerix imports them, and they weren't included > because it imports them with __import__ > > Any

Re: [matplotlib-devel] Can we retire numerix?

John Hunter wrote: > On Tue, Feb 24, 2009 at 1:44 PM, Christopher Barker > wrote: > >>> happy get it out of matplotlib, or phase it out if necessary. I don't >>> think it should be left there forever. > > I think it can be removed. It lives on the maintenance branch 0.91. Good point. I am in

Re: [matplotlib-devel] Can we retire numerix?

Christopher Barker wrote: > Eric Firing wrote: >> It has been purged from the svn trunk. > > Thanks. Has it been deprecated somehow? I don't want folks' code to > break too fast! No, I guess I was in a dangerous mood--I just ripped it out. I could put it back wit

Re: [matplotlib-devel] Can we retire numerix?

Chris Barker wrote: > Hi all, > > I just ran into an issue with py2exe -- my app failed because various > numpy sub-packages weren't included. However, I wasn't using them. But > it failed because numerix imports them, and they weren't included > because it imports them with __import__ > > Any

Re: [matplotlib-devel] Can we retire numerix?

Christopher Barker wrote: > Eric Firing wrote: >> It has been purged from the svn trunk. > > Thanks. Has it been deprecated somehow? I don't want folks' code to > break too fast! I have restored a stripped-down numpy-only version of numerix, with a prominen

Re: [matplotlib-devel] File format for plots

Sandro Tosi wrote: > Hi Sam, > > On Wed, Feb 25, 2009 at 09:35, sam tygier wrote: >> I think this topic has come up before, but i don't think anything has >> resulted from it. >> Correct, because the capability would require a *lot* of work to implement, and most of us don't see a compelling nee

Re: [matplotlib-devel] File format for plots

sam tygier wrote: > Eric Firing wrote: >> Sandro Tosi wrote: >>> Hi Sam, >>> >>> On Wed, Feb 25, 2009 at 09:35, sam tygier wrote: >>>> I think this topic has come up before, but i don't think anything has >>>> resulted from it. >

Re: [matplotlib-devel] Selecting WX2.8 in examples

Sandro Tosi wrote: > On Fri, Mar 6, 2009 at 22:12, Sandro Tosi wrote: > import wxversion > wxversion.select('2.8') > from wx import * > wx.__version__ >> '2.8.7.1' >> >> That solves the problem of multi-wx on a system. >> >> What do you think about adding those 2 line into wx examp

Re: [matplotlib-devel] Selecting WX2.8 in examples

Sandro Tosi wrote: > On Fri, Mar 6, 2009 at 22:24, Sandro Tosi wrote: >> On Fri, Mar 6, 2009 at 22:12, Sandro Tosi wrote: >> import wxversion >> wxversion.select('2.8') >> from wx import * >> wx.__version__ >>> '2.8.7.1' >>> >>> That solves the problem of multi-wx on a system. >>>

Re: [matplotlib-devel] Polar Plot

Sherif Ahmed wrote: > Hello Mike, > > Thanks for your advice. I think this is exactly what I need. I am not sure > how to use this option, might you help me? > > I use simply the following lines in my code: > > self.figure.clf() > self.axes = self.figure.add_axes([0.1,0.1,0.8,0.8], projection='p

Re: [matplotlib-devel] Polar Plot

atplo > tlib\axes.py", line 537, in __init__ > if len(kwargs): martist.setp(self, **kwargs) > File > "c:\python25\lib\site-packages\matplotlib-0.98.3.0001-py2.5-win32.egg\matplo > tlib\artist.py", line 894, in setp > func = getattr(o,funcName) >

Re: [matplotlib-devel] Polar Plot

Sherif Ahmed wrote: > Hi Eric, > > Thanks agaon. Now it works after updating to matplotlib 98.5. > > Well I also attach the code. I find it good if we can publish it to other > interested users. May be some one needs it or likes to upgrade it. I made > already the basic work. How does this work?

Re: [matplotlib-devel] patches have incorrect alpha values

Jae-Joon Lee wrote: > Hi, > > When drawing a patch, the alpha value of its edgeolor is ignored. The > following command draw a circle whose edgecolor has alpha=1, instead > of 0.1. > > > gca().add_patch(Circle((0.5, 0.5), 0.3, >ec=(1,0,0,0.1), fc="none")) > > > Attached

Re: [matplotlib-devel] patches have incorrect alpha values

Jae-Joon Lee wrote: > > Thanks for the explanation. > I personally think that the default behavior for setting alpha is > better to be multiplying with the previous one, instead of overriding. This was causing havoc in contourf; I don't see the logic of multiplying a previous alpha by a new one

Re: [matplotlib-devel] patches have incorrect alpha values

John Hunter wrote: > > > On Mon, Mar 23, 2009 at 3:24 PM, Jae-Joon Lee > wrote: > > The example (e) in my previous script have a code and a text label > mismatched. > I'm attaching the corrected one. > > I took a more look on how a patch is drawn. >

Re: [matplotlib-devel] patches have incorrect alpha values

Michael Droettboom wrote: > Jouni K. Seppänen wrote: >> Eric Firing writes: >> >>> John Hunter wrote: >>> >>>> One possibility would be to have a facecolor/edgecolor property on >>>> the gc itself, which would be rgba tuples. Since

Re: [matplotlib-devel] question about imshow's support for masked arrays

Darren Dale wrote: > I am experimenting with numpy masked arrays, and have a question about > how imshow handles them: > > from numpy import ma > from pylab import colorbar, imshow, show > > a=ma.array([[1,2,3],[4,5,6]],mask=[[0,0,1],[0,0,0]], fill_value=0) > imshow(a, interpolation='nearest') >

Re: [matplotlib-devel] Multithreading problem with print_png and font object?

Karen Tracey wrote: > I originally posted this to the user's list but got no response there. > As I think there's a bug in matplotlib here, I'm re-trying on the > development list. Here's what I sent to -users back on Mar 13: Karen, (I saw your question to the users group, and was hoping so

Re: [matplotlib-devel] Multithreading problem with print_png and font object?

Karen Tracey wrote: > Hmm, the Ubuntu packaging for matplotlib seems to put a copy of > matplotlibrc only in /etc, where, I gather, it will not ever be used by > matplotlib? I guess one is supposed to copy it to one's home directory > and do per-user customization there. For my case, where th

[matplotlib-devel] And the winner is...

http://thread.gmane.org/gmane.comp.python.devel/102706 http://article.gmane.org/gmane.comp.python.devel/102742 The above two posts are worth reading for any among us who are interested in an eventual migration to a DVCS. Eric (happy hg user) ---

Re: [matplotlib-devel] SF.net SVN: matplotlib:[7016] branches/v0_98_5_maint/lib/matplotlib

[email protected] wrote: > Revision: 7016 > http://matplotlib.svn.sourceforge.net/matplotlib/?rev=7016&view=rev > Author: mdboom > Date: 2009-03-31 15:22:06 + (Tue, 31 Mar 2009) > ... > Modified: branches/v0_98_5_maint/lib/matplotlib/transforms.py > ===

[matplotlib-devel] [Fwd: [Matplotlib-users] imshow without resampling]

Jouni, Darren, I'm not sure who the SVG expert is, and I presume the attached message applies to pdf as well as ps. I'm bringing it to your attention because it is suggesting what would seem to be significant improvements in some backends by taking better advantage of their native image suppo

[matplotlib-devel] release strategy, and the role of v0_98_5_maint

It is not always clear what should go in the 0.98.5 maintenance branch. For example, is the _png.cpp patch by Tobias, committed by Andrew, a bug fix or a new feature? I would have said the latter, but I can see arguments either way. More generally, how long do we need to keep updating this m

Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint

John Hunter wrote: [...] >> And is there a release schedule in mind? Any prospect of more >> thoroughly automating official releases and of adding svn snapshot >> releases? And of following numpy's buildbot example? >> >> I don't think I can help with any of this; I am just casting about to >> see

Re: [matplotlib-devel] release strategy, and the role of v0_98_5_maint

Charlie Moad wrote: > I might be able to squeeze some time in this weekend. I am not > thrilled about the new visual studio requirements, nor do I have > access to it. I know John started a build script for OSX and I have > been meaning to try something similar for mingw. Is anyone opposed to >

Re: [matplotlib-devel] Rasterized artists have wrong transform

Jae-Joon Lee wrote: > On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning wrote: >> I like that this solution doesn't litter every call to draw with >> rasterize checks. But it means that the rasterization support had >> better be robust, since Artist authors might not know they're >> interacting with

Re: [matplotlib-devel] DeprecationWarning message fix for polyfit

Aleksandar Veselinovic wrote: > Correcting function spelling (poyfit->polyfit) error in depreciation > warning. Fixed in 7088. Thank you. Eric > > > Index: trunk/matplotlib/lib/matplotlib/mlab.py > === > --- trunk/matplotlib/lib/

Re: [matplotlib-devel] clabel and rotation

Evan Mason wrote: > Hi, would it be possible to add a keyword to clabel to optionally switch > off the angle fix in contour.py lines 384+? Evan, Done in r7097. I called the kwarg "rightside_up", defaulting to True. You have come up with a novel use for clabel. Longer-term, we should be able t

Re: [matplotlib-devel] Cairo Backend and Subpixel Rendering

John Hunter wrote: > On Sat, May 9, 2009 at 9:32 AM, Freddie Witherden > wrote: >> Hi all, >> >> As some of you probably know I am working on the GSoC project to >> externalise the Mathtex engine from Matplotlib. Today I have been >> toying around with the renderer using various backends. >> >> O

[matplotlib-devel] time series zoom/pan speedup

Please check and try out revision 7100. For example, with ipython -pylab: x = np.arange(100, dtype=float) * 0.2 y = np.sin(x) plot(x,y) xlim(10,20) Then play around with panning and zooming. To see what the behavior is like without the changes, just reverse the sign of x, since at presen

Re: [matplotlib-devel] Selecting WX2.8 causes problems on wx 2.8.4

Tony Yu wrote: > I hope you don't mind if I bump this. > > I'm curious if Eric, or any others from the following thread had a > comment on this issue: > http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html > > I don't mind upgrading if that's what's required, but I was just > wonde

Re: [matplotlib-devel] Units issue

John Hunter wrote: > The fundamental problem here is that some artists (Line2D) have > support for storing original unitized data (_xorig, _yorig) and > handling the conversion on unit change internally with the callback, > and some artists (eg Patches) do not . axes._process_plot_var_arg > sub

Re: [matplotlib-devel] dropped spine support

Andrew Straw wrote: > I've implemented initial support for "dropped spines". This is motivated > by the ability to draw figures that look like > http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm > attaching the patches and an image created by the new example. > > This is a somewhat i

Re: [matplotlib-devel] radial grids broken on polar?

Jae-Joon Lee wrote: > The default resolution (which is used to interpolate a path in polar > coordinate) has change to 1 at some point. And because of this, a > radial grid becomes a 0-length line. Increasing the resolution will > bring back your gridlines. This is not the right solution, though.

Re: [matplotlib-devel] radial grids broken on polar?

Eric Firing wrote: > Jae-Joon Lee wrote: >> The default resolution (which is used to interpolate a path in polar >> coordinate) has change to 1 at some point. And because of this, a >> radial grid becomes a 0-length line. Increasing the resolution will >> bring back y

Re: [matplotlib-devel] 'BlendedGenericTransform' object has no attribute '_interpolation_steps'

Tony S Yu wrote: > 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 us

Re: [matplotlib-devel] radial grids broken on polar?

keeping, since as you suggest, it makes more sense for > it to be a property of the artist. I'd almost prefer to raise a warning > if the user provides a resolution argument (other than 1) to Polar > rather than trying to make it work. Is anyone actually using it, other > than to

Re: [matplotlib-devel] Arc requires explicitly setting fill=False?

Tony S Yu wrote: > 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

Re: [matplotlib-devel] Arc requires explicitly setting fill=False?

John Hunter wrote: > On Sun, May 24, 2009 at 7:20 PM, Eric Firing wrote: >> Tony S Yu wrote: >>> Currently, Arc in matplotlib.patches requires that it be called with >>> kwarg ``fill=False``. Was this behavior intentional? The code suggests >>> that a def

Re: [matplotlib-devel] arbitrary spine locations in svn trunk

Andrew Straw wrote: > Andrew Straw wrote: >> I believe I addressed all the issues raised with the patch I emailed the >> list last week and I tried to avoid any breakage. Thanks to all who >> commented -- you made this a better implementation. > > Upon further reflection, I realize I didn't add an

Re: [matplotlib-devel] Building docs

Reinier Heeres wrote: > Hi all, > > While trying to work on some docs for mplot3d I ran into trouble > building them. I started with the stock ubuntu sphinx (0.5.2), but > that ran into errors. Following the documentation suggestion I tried > the repository at http://svn.python.org/projects/doctoo

  1   2   3   4   5   6   7   8   9   10   >