[matplotlib-devel] xlim() turns off autoscaling

The help for xlim() says: Set/Get the xlimits of the current axes:: xmin, xmax = xlim() # return the current xlim xlim( (xmin, xmax) ) # set the xlim to xmin, xmax xlim( xmin, xmax )# set the xlim to xmin, xmax but it also has the unexpected behavior of turning

[matplotlib-devel] pyplot commands appear to ignore interactive status

using a recent svn (r8900), I've noticed that after starting from a regular python shell: >>> import matplotlib.pyplot as plt >>> plt.isinteractive() False >>> plt.plot([1,2,3],[1,3,2]) [] >>> plt.plot([1,2,3],[1,2,3]) [] # plt.draw() is not required, the figure pops up # and both plots are

Re: [matplotlib-devel] pyplot commands appear to ignore interactive status

On 2/7/11 9:02 PM, Benjamin Root wrote: > On Mon, Feb 7, 2011 at 7:20 PM, Mike Kaufman <mailto:mck...@gmail.com>> wrote: > > > using a recent svn (r8900), I've noticed that after starting from a > regular python shell: > >

Re: [matplotlib-devel] pyplot commands appear to ignore interactive status

On 2/7/11 9:28 PM, Eric Firing wrote: >>> Which backend are you using and using which OS? >> >> Good question. Snow Leopard and the MacOSX backend. If I use the Gtk > > This is a known bug in the MacOSX backend. > >> backend this bug does _not_ occur (though I have to use the plt.show() >> command

Re: [matplotlib-devel] pyplot commands appear to ignore interactive status

On 2/7/11 10:30 PM, Benjamin Root wrote: > > The behavior in gtk and other backends is the designed/intended > behavior. macosx backend is actually the odd-man out because it was > coded to only work in one of those modes. > > Maybe we should emit a warning when macosx backend is used when > inter

[matplotlib-devel] patch to add legend.frameon to rcParams

I noticed that this didn't exist and I never seem to want a frame anyway so here's a patch. I wasn't sure if anything in doc/ needed to be changed... I don't really like the name "legend.frameon". I'd rather have "legend.frame" or "legend.useframe". If people would accept changing the name of

[matplotlib-devel] behavior of drawing in interactive mode

Hi, After switching over from the MacOSX backend to the GTKAgg backend, I started notice a big change in drawing behavior. Now I know that MacOSX is interactive all the time by [mis]design, so I wasn't surprised that I would have to add draw() commands when isinteractive()==False; however, whe

[matplotlib-devel] exception in sankey demo in examples

Possible bug report: "Exception occurred rendering plot." http://matplotlib.github.com/examples/api/sankey_demo.html This is with firefox 6.0.2 M -- All of the data generated in your IT infrastructure is seriously valu

Re: [matplotlib-devel] exception in sankey demo in examples

This is all fine. I just wanted to make sure that the documentation on the web got squared with the current state of things. M On 9/24/11 10:57 PM, Kevin Davies wrote: > Mike, > sankey_demo.py doesn't exist in the latest build. It has been renamed to > sankey_demo_old.py and there are 3 new sank

[matplotlib-devel] savefig to pdf and ps don't respect mew=0 or mec

for this code: clf() plot(arange(5),arange(5), 'y.', ms=30.0, mew=0, mec='r') draw() savefig('mew.pdf') savefig('mew.ps') The pdf and ps show a marker edge even though the gtkagg window doesn't (neither do the png or svg savefigures). The marker edge in the ps is black instead of red. I haven'

Re: [matplotlib-devel] savefig to pdf and ps don't respect mew=0 or mec

Both Skim 1.3.18 and Preview on OSX 10.6.8 show this. I'm using gv 3.7.1 as a postscript viewer. M > Mike, > > I was recently tracking down a somewhat similar problem a few days ago. > It turned out not to have been related to mpl at all, but rather a bug > in the PDF viewer. Which viewer ar

[matplotlib-devel] should the ordering of clf() matter for AxesGrid?

Given the code snippet below with clf() #1 uncommented works like one would expect - both plots are drawn. If #1 is commented out and #2 is uncommented, then the figure is cleared and neither plot is drawn. Is this the correct behavior? It seems like a bug to me. M import numpy as np import

Re: [matplotlib-devel] should the ordering of clf() matter for AxesGrid?

Ok, this was my bad. I was under the [mistaken] impression (and in retrospect I'm not sure why) that the AxesGrid call just set up the geometry and the plot calls actually created the axes. Thanks for setting me straight. M On 1/11/12 9:05 PM, Paul Ivanov wrote: > Hi Mike, > >

[matplotlib-devel] Bug: errorbar caps require mew!=0

If mew=0, then the caps on errorbars are not drawn regardless of the setting of the "capsize" option. I don't think this should be the behavior, it certainly caught me off guard, since I had mew=0 set in rcParams. This is present as of 5b499f0180befea04fab7bfda17ba3ad7cf2380e (Mar 22nd master)

[matplotlib-devel] axes.arrow and FancyArrow documentation and concerns

Hi all, I just sent in a pull request #941 to update the documentation for axes.arrow, because width,head_width,head_length, etc weren't documented, but I ran into a couple of concerns that I thought to discuss: 1. the default width of 0.001 seems absurdly small. 0.05 seems better. You can tel

Re: [matplotlib-devel] Hacking on matplotlib

On 7/10/12 4:18 PM, Benjamin Root wrote: > > > On Tue, Jul 10, 2012 at 4:15 PM, Amy Dyer > wrote: > > Hi everyone, > > We're part of the summer 2012 batch at Hackerschool > (www.hackerschool.com ) and we chose to > spend this we

[matplotlib-devel] log scale plots ignore tick_params

The example code should explain the problem. tick_params(), at least for the ticks themselves, is ignored by log plots. clf() x = arange(10) subplot(211) plot(x, x) tick_params(right='off') # works. subplot(212) semilogy(x, x) tick_params(right='off') # doesn't work! draw() M -

Re: [matplotlib-devel] log scale plots ignore tick_params

On 10/9/12 9:42 PM, Eric Firing wrote: > On 2012/10/09 3:03 PM, Mike Kaufman wrote: >> clf() >> x = arange(10) >> subplot(211) >> plot(x, x) >> tick_params(right='off') # works. >> >> subplot(212) >> semilogy(x, x) >> tick_params(

[matplotlib-devel] tick_params direction 'inout'

Hi all, I don't have time to make a patch at the moment, but I thought I'd point it out for anyone to give it a go... tick_params(axis='both', **kwargs) Change the appearance of ticks and tick labels. Keyword arguments: ... *direction* : ['in' | 'out'] Puts ticks insid

Re: [matplotlib-devel] tick_params direction 'inout'

On 11/15/12 2:54 PM, Paul Ivanov wrote: > On Wed, Nov 14, 2012 at 7:37 PM, Mike Kaufman > I just found that *direction* accepts 'inout' as well, which > does indeed place the tick on both sides of the spine. So the > documentation should be updated to reflect

Re: [matplotlib-devel] png error with git master, is it just me?

I've had problems like this using a git-source matplotlib and macports. This usually happens after libpng is upgraded. Turns out a 'python setup.py install ...' in matplotlib will not solve things until you manually delete the contents of the matplotlib build/ directory. After which new go at s

Re: [matplotlib-devel] backporting the boxplot fix

So it seems I was using the old branch (now deleted?) v1.4.x rather than v1.4.3-doc, which does have the commit for the fix in question. I was naively assuming that v1.4.x was always the latest release in the v1.4 series. False alarm. Sorry. M On 4/25/15 4:26 PM, Thomas Caswell wrote: > The c