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

[Tony Yu]

Sorry, I attached the wrong file:

colormap_clipping.patch
Description: Binary data
On Oct 18, 2008, at 11:23 AM, 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) 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,-TonyExample 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 challengeBuild the coolest Linux based applications with Moblin SDK & win great prizesGrand prize is a trip for two to an Open Source event anywhere in the worldhttp://moblin-contest.org/redirect.php?banner_id=100&url="">Matplotlib-devel mailing listMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] reimplemented legend class

[Tony Yu]

On Dec 4, 2008, at 7:21 PM, Jae-Joon Lee wrote:


John,

I just committed changes to SVN that reflect most of your comments.
I didn't add the optional transformation support yet though.



I'm getting a truncated line when calling:

>>> plt.legend(numpoints=1)

In the legend, I see a short dashed line followed by the marker.  
Before, the line went through the marker. I've attached a couple of  
images showing numpoints set to 1 and 2.


I think this behavior was introduced with the improved legend class.

Thanks,
-Tony

<><>


mpl svn 6497--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Jagged plot in macosx backend

[Tony Yu]

There appears to be a bug in the macosx backend. When I plot large  
numbers with small variations in the value, the numbers seem to be  
coarsely rounded off. This bug doesn't appear with other backends (I  
tried WxAgg and TkAgg). Below is a simple script showing the problem  
and the resulting plot on the macosx backend.


Thanks,
-Tony

Mac OS X 10.5.6
Matplotlib svn r6779

#

import numpy as np
import matplotlib.pyplot as plt

x = np.linspace(0, 1)
plt.plot(x, x + 1e6)
plt.show()<>--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Tony Yu]

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  
wondering if this issue was an intended result of the patch.


Best,
-Tony


On May 8, 2009, at 8:46 PM, Tony S Yu wrote:


I'm running into the following error with the wx backend


import wx
import matplotlib.backends.backend_wxagg

Traceback (most recent call last):
 File "", line 1, in 
 File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
matplotlib/backends/backend_wxagg.py", line 23, in 
   import backend_wx# already uses wxversion.ensureMinimal('2.8')
 File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
matplotlib/backends/backend_wx.py", line 120, in 
   except wxversion.AlreadyImportedError:
AttributeError: 'module' object has no attribute
'AlreadyImportedError'


This problem seems to be related to additions made here:
http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html

The problem is that my version of wxversion raises 'VersionError'
instead of 'AlreadyImportedError'.

I'm running wxPython 2.8.4.0 while people in the above thread seem to
be using at least 2.8.7.1. Do I need to upgrade, or is this a bug?

Thanks,
-Tony

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances!  
Your
production scanning environment may not be a perfect world - but  
thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW  
KODAK i700

Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel







--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Tony Yu]

I just downloaded wxversion.py from the wxPython trunk and everything  
seems to working fine. Thanks for your help!


-T

On May 14, 2009, at 1:27 PM, Eric Firing wrote:


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  
wondering if this issue was an intended result of the patch.


Tony,

No, it certainly wasn't.

As for upgrading, it looks to me like you don't need to upgrade  
wxpython, just wxversion, which is a single independent file.


I don't know whether wxversion is always packaged with a wxpython  
itself, or whether it is distributed separately.


I don't see any decent workaround.  We can't just catch VersionError  
instead of AlreadyImportedError because that would defeat the  
purpose. It looks to me like upgrading wxversion is the only option,  
unless someone with wx expertise wants to plunge in and figure out a  
better solution.  The only other thing I can think of would be for  
mpl to include its own copy of wxversion.  I would prefer not to  
clutter mpl that way--it would be just one more obscure thing to  
maintain.


Eric


Best,
-Tony
On May 8, 2009, at 8:46 PM, Tony S Yu wrote:

I'm running into the following error with the wx backend


import wx
import matplotlib.backends.backend_wxagg

Traceback (most recent call last):
File "", line 1, in 
File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
matplotlib/backends/backend_wxagg.py", line 23, in 
  import backend_wx# already uses  
wxversion.ensureMinimal('2.8')

File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
matplotlib/backends/backend_wx.py", line 120, in 
  except wxversion.AlreadyImportedError:
AttributeError: 'module' object has no attribute   
'AlreadyImportedError'


This problem seems to be related to additions made here:
http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html

The problem is that my version of wxversion raises 'VersionError'   
instead of 'AlreadyImportedError'.


I'm running wxPython 2.8.4.0 while people in the above thread seem  
to  be using at least 2.8.7.1. Do I need to upgrade, or is this a  
bug?


Thanks,
-Tony

--
The NEW KODAK i700 Series Scanners deliver under ANY  
circumstances! Your
production scanning environment may not be a perfect world - but  
thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW  
KODAK i700

Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel





Tony S Yu
PhD Candidate
Hatsopoulos Microfluids Laboratory

email: tsy...@gmail.com
office: 617.324.0128




--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] pyplot.rgrids returns wrong values?

[Tony Yu]

Sorry for reposting, but the original may have been overlooked since  
it was buried deep in a matplotlib-users thread.

Currently, `pyplot.rgrids` is returning tick lines instead of grid  
lines. My guess is that this is a typo, but there may be a compelling  
reason to return the tick lines. If it is a typo, here's a patch:


Index: lib/matplotlib/projections/polar.py
===
--- lib/matplotlib/projections/polar.py (revision 7300)
+++ lib/matplotlib/projections/polar.py (working copy)
@@ -397,7 +397,7 @@
 self._r_label2_position.clear().translate(angle, -self._rpad  
* rmax)
 for t in self.yaxis.get_ticklabels():
 t.update(kwargs)
-return self.yaxis.get_ticklines(), self.yaxis.get_ticklabels()
+return self.yaxis.get_gridlines(), self.yaxis.get_ticklabels()

 set_rgrids.__doc__ = cbook.dedent(set_rgrids.__doc__) % kwdocd

--
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] pyplot.rgrids returns wrong values?

[Tony Yu]

Sorry for sending this twice, John; I forgot to copy the list.

On Jul 31, 2009, at 9:14 AM, John Hunter wrote:


On Thu, Jul 30, 2009 at 10:01 AM, Tony Yu wrote:

Sorry for reposting, but the original may have been overlooked since
it was buried deep in a matplotlib-users thread.

Currently, `pyplot.rgrids` is returning tick lines instead of grid
lines. My guess is that this is a typo, but there may be a compelling
reason to return the tick lines. If it is a typo, here's a patch:



Doesn't pyplot.rgrids need to be fixed too:



def rgrids(*args, **kwargs):
  """

[Snip]


Should

lines = ax.yaxis.get_ticklines()

be

lines = ax.yaxis.get_gridlines()


I'm going to make both these changes in svn , but I'd like you to  
confirm this.


Yes, that's correct. I called `rgrids` with arguments so I completely  
missed that call to `get_ticklines`. However, I think there's a typo  
in svn: yaxis.gridlines is called instead of yaxis.get_gridlines().


-T

Index: lib/matplotlib/pyplot.py
===
--- lib/matplotlib/pyplot.py(revision 7313)
+++ lib/matplotlib/pyplot.py(working copy)
@@ -1102,7 +1102,7 @@
if not isinstance(ax, PolarAxes):
raise RuntimeError('rgrids only defined for polar axes')
if len(args)==0:
-lines = ax.yaxis.gridlines()
+lines = ax.yaxis.get_gridlines()
labels = ax.yaxis.get_ticklabels()
else:
lines, labels = ax.set_rgrids(*args, **kwargs)

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] semilogx and semilogy don't reset linear scale

[Tony Yu]

I noticed that semilogx and semilogy don't check if the linear axis (y- 
axis for semilogx; x-axis for semilogy) is actually linear. Thus, if I  
call semilogx and then call semilogy *on the same plot*, I end up with  
a loglog plot.

Below is a simple patch. I'm not sure how useful this fix is since  
most people wouldn't want to make these calls on the same plot (since  
the second call would override the first)---I was working  
interactively in IPython so it did make a difference.

Cheers,
-Tony


Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py  (revision 7557)
+++ lib/matplotlib/axes.py  (working copy)
@@ -3615,6 +3615,7 @@
   }

  self.set_xscale('log', **d)
+self.set_yscale('linear')
  b =  self._hold
  self._hold = True # we've already processed the hold
  l = self.plot(*args, **kwargs)
@@ -3665,6 +3666,7 @@
   'nonposy': kwargs.pop('nonposy', 'mask'),
   }
  self.set_yscale('log', **d)
+self.set_xscale('linear')
  b =  self._hold
  self._hold = True # we've already processed the hold
  l = self.plot(*args, **kwargs)

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Fwd: IOError: [Errno 4] Interrupted system call (Qt4 backend)

[Tony Yu]

I probably should have sent this to the devel list instead of the user list.
Is anyone else running into a similar problem with Qt, or is something in my
install screwy?

Thanks,
-Tony

-- Forwarded message --
From: Tony Yu 
Date: Mon, Jul 18, 2011 at 5:58 PM
Subject: IOError: [Errno 4] Interrupted system call (Qt4 backend)
To: matplotlib-users 


When using the Qt4 backend, I'm getting an IOError similar to the one
detailed in:
http://old.nabble.com/matplotlib-with-Qt4-backend-td26311369.html
But it's definitely a separate issue (see Traceback below). This issue also
seems specific to Qt (I couldn't reproduce it on 'macosx', 'tkagg', or 'agg'
backends).

I found a number of other people who ran into similar problems with Qt.
Their solutions tend to be: catch the error and just try running the process
again.

I'm on Qt 4.7.3, OS X 10.6.8, Matplotlib trunk. Any help would be much
appreciated.

-Tony


Script reproducing issue

import matplotlib
matplotlib.use('qt4agg')
import matplotlib.pyplot as plt

for n in xrange(300):
plt.plot([0, 1])
plt.savefig('test.jpg')
# Since it's a signaling issue, it gets triggered randomly, so the attached
# script may or not reproduce the issue.

Traceback
=

traceback (most recent call last):
  File "qterror.py", line 8, in 
plt.savefig('test.jpg')
  File "/Users/Tony/python/devel/mpl/lib/matplotlib/pyplot.py", line 428, in
savefig
return fig.savefig(*args, **kwargs)
  File "/Users/Tony/python/devel/mpl/lib/matplotlib/figure.py", line 1162,
in savefig

self.canvas.print_figure(*args, **kwargs)
  File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_qt4agg.py",
line
 153, in print_figure
FigureCanvasAgg.print_figure(self, *args, **kwargs)
  File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line
1979, in
print_figure
**kwargs)
  File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line
1799, in
print_jpg
buf, size = agg.print_to_buffer()
  File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
45
7, in print_to_buffer
FigureCanvasAgg.draw(self)
  File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
40
0, in draw
self.renderer = self.get_renderer()
  File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
41
1, in get_renderer
self.renderer = RendererAgg(w, h, self.figure.dpi)
  File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
51
, in __init__
RendererBase.__init__(self)
  File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line
114, in _
_init__
self._text2path = textpath.TextToPath()
   File "/Users/Tony/python/devel/mpl/lib/matplotlib/textpath.py", line 37,
in __init_
_
self._adobe_standard_encoding = self._get_adobe_standard_encoding()
  File "/Users/Tony/python/devel/mpl/lib/matplotlib/textpath.py", line 41,
in _get_ad
obe_standard_encoding
enc_name = dviread.find_tex_file('8a.enc')
  File "/Users/Tony/python/devel/mpl/lib/matplotlib/dviread.py", line 837,
in find_te
x_file
 result = pipe.communicate()[0].rstrip()
  File
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/subpro
cess.py", line 663, in communicate
stdout = self.stdout.read()
IOError: [Errno 4] Interrupted system call
--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Another colormap

[Tony Yu]

On Thu, Sep 22, 2011 at 5:16 PM, Nathaniel Smith  wrote:

> On Sep 21, 2011 5:29 PM, "Christoph Gohlke"  wrote:
> > On 9/13/2011 12:24 AM, Eric Firing wrote:
> > > On 07/18/2011 07:07 AM, Sameer Grover wrote:
> > >> I came across this website where different colormaps have been
> compared
> > >> and the author has come up with an optimal colormap for data
> > >> visualization called the "cool-warm colormap".
> > >>
> > >> http://www.cs.unm.edu/~kmorel/documents/ColorMaps/index.html
> > >>
> > >> It is somewhat similar to the cool colormap already included in
> > >> matplotlib, but I've added the new colormap to matplotlib in the patch
> > >> attached in case it is deemed fit to be included in the matplotlib
> source.
> > > We should include this, but I think the 257-entry version is overkill;
> > > it adds a big chunk to the _cm.py file, and I doubt it is visually
> > > distinguishable from the 33-entry version.  Would you mind providing a
> > > patch for the latter?  (Or better yet, the functions that generate the
> > > r,g,b values.)
> > Here's a pull request for the 33 entry map:
> > 
>
> Let me open a can of worms here...
>
> I looked at the paper, and the goal was specifically to produce a good
> "default" colormap - not necessarily the best for any situation, but good
> overall and certainly better than the rainbow ('jet') colormap in most
> cases. (I agree with the author that jet is pretty terrible and tends to
> distort data.)
>
> Should we switch to this as the default matplotlib colormap? I think it
> would be a clear improvement.
>
I have absolutely no clout here, but I'd definitely be in favor of changing
the default colormap away from "jet".

Personally, I'd prefer a two-tone colormap as the default (two-distinct
tones at the limits with a gradient in-between---dubbed "sequential" in the
paper) instead of a three-tone colormap (three-distinct tones---dubbed
"diverging" in the paper). (I think this is a more common use case, and I
think using a "diverging" colormap effectively requires setting vmin/vmax.)
But really, (almost) anything is better than "jet".

Don't misunderstand: I know I can change the default colormap in my
matplotlibrc file (and this is what I do). But 90% of people don't bother to
change the defaults. If changing this default in matplotlib prevents just 1
person from publishing a paper with a "jet" colormap, I think we'll have
made the world a better place. ;)

-Tony
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] remove xpm flag in _load_bitmap function of backend_wx.py and alternate tool bar icons

[Tony Yu]

Hi,

I apologize if this isn't the right forum for this email; I'm not  
actually a matplotlib developer.

I was trying to use custom icons for the mpl Wx backend, but the  
version of mpl I was using had a _load_bitmap method that only read  
xpm bitmaps. This requirement is enforced by the wx.BITMAP_TYPE_XPM  
flag on:

line 1398 of backend_wx.py in trunk
line 1458 of backend_wx.py in v0_91_maint

The default flag wx.BITMAP_TYPE_ANY allows wx to autodetect the  
format. Deleting the wx. BITMAP_TYPE_XPM argument allows me to change  
to toolbar icons to png files. I noticed that the trunk and  
v0_91_maint versions of mpl have a _load_pngicon method to load png  
icons. This additional method seems unnecessary (or am I missing  
something) if the offending argument is deleted.

One final note: I made some new icons for the toolbars of the plot  
windows. I'm not sure if many people would be interested in them since  
I've made them following a OS X aesthetic (also, I replaced the home  
icon with a reload icon because that made more sense to me). In any  
case, I'd like to make these available as an alternative, but I'm not  
sure where to post them.

Thanks in advance for reading my ramblings.

-Tony

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] remove xpm flag in _load_bitmap function of backend_wx.py and alternate tool bar icons

[Tony Yu]

On May 23, 2008, at 4:47 PM, John Hunter wrote:


On Fri, May 23, 2008 at 2:00 PM, Tony Yu <[EMAIL PROTECTED]> wrote:

Hi,

I apologize if this isn't the right forum for this email; I'm not
actually a matplotlib developer.

I was trying to use custom icons for the mpl Wx backend, but the
version of mpl I was using had a _load_bitmap method that only read
xpm bitmaps. This requirement is enforced by the wx.BITMAP_TYPE_XPM
flag on:

line 1398 of backend_wx.py in trunk
line 1458 of backend_wx.py in v0_91_maint

The default flag wx.BITMAP_TYPE_ANY allows wx to autodetect the
format. Deleting the wx. BITMAP_TYPE_XPM argument allows me to change
to toolbar icons to png files. I noticed that the trunk and
v0_91_maint versions of mpl have a _load_pngicon method to load png
icons. This additional method seems unnecessary (or am I missing
something) if the offending argument is deleted.


We made these changes recently on the advice of a user, but I am no wx
guru.  If you can post a patch that behaves properly and uses the png
icons (the xpms don't render properly on some platforms). that would
be great.


I'd like to try, but I've never contributed to a software project so  
submitting a patch seems pretty daunting. I'll have to read up on how  
to do this.






One final note: I made some new icons for the toolbars of the plot
windows. I'm not sure if many people would be interested in them  
since

I've made them following a OS X aesthetic (also, I replaced the home
icon with a reload icon because that made more sense to me). In any
case, I'd like to make these available as an alternative, but I'm not
sure where to post them.


post them here as a small screenshot or just attach the icons.  They
can't be that large.  I'm the list moderator so I can approve it if
there is a problem.  What I'd really like to see is a patch that
allows users to customize the toolbar, eg by adding buttons, removing
buttons, or changing the icons.  This is not easy, especially across
the user interfaces.  Our toolbars would need to expose some common
api for this...


Here are the pngs:

<>
 <>
 <>
 <>
 <>
 <>
 <>


I also have ppm, xpm, and the original Inkscape svgs, but I didn't  
want to clutter this with attachments.





JDH


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] remove xpm flag in _load_bitmap function of backend_wx.py and alternate tool bar icons

[Tony Yu]

On May 23, 2008, at 7:05 PM, John Hunter wrote:


Could I ask you to submit a svn diff of the maintenance branch -- this
will be easier for me to apply.  simoply make your changes in the
branch and then do


svn diff > my.patch


and send that.


I think this is what you're asking for, but I may have done the diff  
from the wrong directory.


backend_wx.patch
Description: Binary data




I think your icons look nice, but I was surprised that they were
grayscale.  Is this a minimalist aesthetic?

Yeah, this is what I meant by OS X aesthetic. Many of the OS X icons  
are grayscale so this matches better with the look of my other apps.  
It would probably seem out of place on a linux or windows box.


One last thing: is there some sort of tutorial for beginners who *may*  
want to contribute. Like a "Getting Started" page for developers. I  
have tons of questions, but I don't want to spam this list. For  
example: I checked out the maintenance version of MPL but the build  
and install set everything up in a new/separate directory. This means  
my subversion working copy is separate from the installed copy (what  
actually gets imported).


Thanks,
-Tony-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] future of mpl documentation

[Tony Yu]

On May 25, 2008, at 12:13 PM, John Hunter wrote:


I played around with this a bit this morning -- it may be too busy for
your OS X sensibilities, but let me know if you think think this is an
approach wotrh pursuing.  I've added the mathtext background and a few
axes and there are a few more axes to do.  In svn as
examples/api/logo2.py


I must admit, I was a little worried when you suggested adding a big  
equation in the background, but I think you did a good job of making  
it look nice. Unfortunately, I get an error when I try to run the  
logo2 script:


AttributeError: 'NoneType' object has no attribute 'get_ticklabels'

module body in logo2.py at line 23
for label in ax.get_xticklabels() + ax.get_yticklabels():

If I comment-out that for-block, I run into another error:

NotImplementedError: xlim not meaningful for polar axes

module body in logo2.py at line 43
ax.set_xlim(-2*sigma, 2*sigma)

I'm guessing the first error is a trunk vs. v0_91_maint issue? Is the  
second a naming error in the commit? Maybe axhist.set_xlim instead of  
ax.set_xlim?


Overall I really like the new logo, but I'd like play around with it a  
bit for kicks.


Thanks!
-Tony-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] future of mpl documentation

[Tony Yu]

On May 31, 2008, at 10:30 PM, John Hunter wrote:
>
> And I made several changes -- mainly to simplify the logo.  My wife
> thought it looked busy, and she has better taste than I do,  so I
> stripped it down a bunch and added the many small subplots as a
> sidebar on the right.

I agree, the stripped down logo looks much better.

> Let me know what you think and don't be shy
> about being critical despite Darren's kind sensitivities.  I don't
> take pride in my graphic design abilities and so will happily make
> changes
>
> See http://matplotlib.sf.net for the new logo(s) and the attached for
> the stripped down script.

I like the new color scheme on the website. Since you asked for  
criticism, though, I'm not a fan of the blue "matplotlib" in the logo  
(on the website, the attached logo is actually different). I think  
black or a dark gray looks better (color=[0.2, 0.2, 0.2]). Or, if you  
prefer blue, something less like the default hyperlink color (e.g.  
color=[.1,.1,.5]). My 2 cents.

BTW, I noticed that website is a little old (pure HTML, no CSS). If  
you're ever interested in redesigning the website (nothing fancy,  
mainly just moving to CSS), I'd be happy to help out.

-Tony

> JDH
> 


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] future of mpl documentation

[Tony Yu]

On Jun 1, 2008, at 6:00 AM, Darren Dale wrote:

> On Sunday 01 June 2008 12:53:48 am John Hunter wrote:
>>
>>
>> We're definitely interested.  Try checking out the htdocs svn
>> repository.

Hmm, the README file says I need all the backends working. I don't  
think I want to try that on my Mac. I'll try it out with a linux  
machine I have in lab.

>>  Admittedly we do things in our own special way (eg the
>> YAPTU template engine), but if we could improve the look-and-feel  
>> that
>> would be great.  None of us have any special powers in the
>> website-design department.  Even better, as part of our new trunk
>> documentation effort, we have moved to a sphinx based documentation
>> system (in the doc subdir of svn trunk).  If you could figure out a
>> way to hook custom CSSandr mpl figures/screenshots or any other  
>> snazzy
>> features into the base sphinx build system, that would be a big help
>> since we hope to jettison the somewhat anachronistic website build
>> system n the not-too-distant-future.
>
> I was intending to write the list and ask if anyone was interested  
> in playing
> with CSS to customize the looks of the new sphinx-based  
> documentation effort.
> I'm really happy to hear that you're interested in helping out, Tony.

Actually, I really like the default look of sphinx-based docs, but I  
wouldn't mind playing around with it. What did you have in mind?

> For the moment, you can build the html documentation by running  
> "make.py html"
> in the doc directory. The latex->pdf docs are experiencing growing  
> pains,
> I'll work on it this morning.


html built fine on my machine; it looks really nice. The pdf docs also  
built without problems. Nice work.

-Tony


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] future of mpl documentation

[Tony Yu]

On Jun 1, 2008, at 9:47 AM, Rob Hetland wrote:
>
> 2. I like the figure to the side (and agree that there should be  
> only one), but it seems that polar plots are more rarely used than  
> normal x-y plots.  Perhaps an x-y plot (the histogram, for example)  
> would be better advertising.

I was the one who originally chose the polar plot. I admit, it was  
mainly for aesthetics. Here are a few reasons:

* I think a circular plot works better on the logo than a rectangular  
plot would.
* The polar plot is one of the more attractive plots in the examples.
* It's a plotting featuring that most plotting software wouldn't have  
so it seems to differentiate matplotlib from other plotting software.

Originally, it wasn't a big deal because there were other plots in the  
logo. Still, I'd be in favor of keeping the polar plot for aesthetic  
reasons.

Great, now I'm that guy who's arguing for looks over practicality. :(

-Tony

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] empty mathtext "$$" in labels generates an exception

[Tony Yu]

On Jun 3, 2008, at 4:18 PM, Jörgen Stenarson wrote:

using an empty mathtext "$$" in labels generates an exception. See
example and traceback below.


My guess is that this is a LaTeX error. If you enter $$ in a normal  
LaTeX document, you will get:


pdflatex -interaction=nonstopmode -file-line-error-style exited with  
status 1


This error comes from the fact that double dollar signs ($$) are used  
to wrap display equations (single dollar signs are used to wrap inline  
equations). If you were to instead write "$ $" (or "$$ $$"), you  
shouldn't get an error.


-Tony


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] RegularPolyCollection inputs in collections_demo.py are wrong?

[Tony Yu]

I think the arguments for RegularPolyCollection were changed from  
0.91.x to 0.98.0, but the example in collections_demo.py were not  
changed.

-Tony

Index: examples/api/collections_demo.py
===
--- examples/api/collections_demo.py(revision 5400)
+++ examples/api/collections_demo.py(working copy)
@@ -86,7 +86,7 @@

  a = fig.add_subplot(2,2,3)

-col = collections.RegularPolyCollection(fig.dpi, 7,
+col = collections.RegularPolyCollection(7,
  sizes = N.fabs(xx)*10.0,  
offsets=xyo,
  transOffset=a.transData)
  trans = transforms.Affine2D().scale(fig.dpi/72.0)

-
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

[matplotlib-devel] size of pcolor boxes don't match X, Y input

[Tony Yu]

When I plot a matrix using pcolor, the size of the boxes don't match  
the input (each box is off by about 10% from the input coordinates).

I think the problem is caused by the new draw method in PolyCollection  
(added in revision 5403). If I revert to the previous version of  
collections.py, the boxes are displayed properly.

The below script is a simple test case. It should print the corners of  
the boxes on integer coordinates, but (on my computer, at least), the  
corners do not land on integer values.

:-Tony

==
N = 2
pts = np.arange(0, N+1)
X, Y = np.meshgrid(pts, pts)
col = plt.pcolor(X, Y, np.random.rand(N, N))
plt.show()

-
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

[matplotlib-devel] image_demo.py raises AttributeError: set_resample

[Tony Yu]

I apologize if this doesn't belong in the developers mailing list:

When I run image_demo.py in examples/pylab (using mpl r, I get  
AttributeError: set_resample.


This error seems to have been introduced in revision 5433 with the agg  
resample patch (i.e. image_demo.py works fine with r5432).


-Tony

Here's the full traceback:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/lib-tk/Tkinter.py", line 1403, in __call__

return self.func(*args)
  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
backends/backend_tkagg.py", line 188, in resize

self.show()
  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
backends/backend_tkagg.py", line 191, in draw

FigureCanvasAgg.draw(self)
  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
backends/backend_agg.py", line 255, in draw

self.figure.draw(self.renderer)
  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
figure.py", line 825, in draw

for a in self.axes: a.draw(renderer)
  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
axes.py", line 1455, in draw

im.draw(renderer)
  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
image.py", line 232, in draw

im = self.make_image(renderer.get_image_magnification())
  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
image.py", line 205, in make_image

im.set_resample(self._resample)
AttributeError: set_resample-
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

Re: [matplotlib-devel] image_demo.py raises AttributeError: set_resample

[Tony Yu]

On Jun 11, 2008, at 11:47 AM, John Hunter wrote:

> On Wed, Jun 11, 2008 at 10:13 AM, Tony Yu <[EMAIL PROTECTED]> wrote:
>> I apologize if this doesn't belong in the developers mailing list:
>> When I run image_demo.py in examples/pylab (using mpl r, I
>> get AttributeError: set_resample.
>> This error seems to have been introduced in revision 5433 with the  
>> agg
>> resample patch (i.e. image_demo.py works fine with r5432).
>
> I think you may be getting your mpl versions mixed up -- svn trunk
> does not have examples/pylab/image_demo.py.  The directory has been
> renamed examples/pylab_examples to avoid code breakage for people
> importing pylab and  running in the examples dir.  The image_demo
> example is running for me on the trunk.

Actually I mistyped earlier; I was using image_demo from  
pylab_examples.  In any case, an svn up fixed the problem.

Strangely enough, reverting back to the revision that was originally  
raising errors didn't bring the errors back. I must have been running  
a cached version of one of the files.

Thanks for your help.
-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

[matplotlib-devel] Fwd: rgrids and thetagrids raise AttributeError and TypeError

[Tony Yu]

I was playing around with polar plots and trying to alter the grid  
labels when I ran into some weird errors. Whenever I call  
pyplot.thetagrids() (and similarly with rgrids) I get:


>>> AttributeError: 'PolarAxesSubplot' object has no attribute  
'thetagridlines


After searching the MPL directory, it didn't seem like thetagridlines  
was defined anywhere. Alternatively, If I call thetagrids with an  
argument [e.g. thetagrids(range(45,360,90))], I get


>>> TypeError: 'NoneType' object is not iterable

which comes from the following line in pyplot:

>>> lines, labels = ax.set_thetagrids(*args, **kwargs)

Strangely, the set_thetagrids method of PolarAxes doesn't return any  
values and this is causing the TypeError above.


I'm really confused about these errors. Any help would be greatly  
appreciated.


-Tony

PS: Full tracebacks are shown below.
I'm on MPL trunk, r5588.

CASE 1:

Traceback (most recent call last):
  File "polar.py", line 19, in 
lines, labels = thetagrids()
  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
pyplot.py", line 984, in thetagrids

lines = ax.thetagridlines()
AttributeError: 'PolarAxesSubplot' object has no attribute  
'thetagridlines'


CASE 2:

Traceback (most recent call last):
  File "polar.py", line 19, in 
lines, labels = thetagrids(range(45,360,90))
  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/matplotlib/ 
pyplot.py", line 987, in thetagrids

lines, labels = ax.set_thetagrids(*args, **kwargs)
TypeError: 'NoneType' object is not iterable

-
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

Re: [matplotlib-devel] Fwd: rgrids and thetagrids raise AttributeError and TypeError

[Tony Yu]

Hi Mike,

I just updated to r5595 and both rgrids and thetagrids work perfectly.

Thanks for your help.
-Tony


On Jun 19, 2008, at 9:24 AM, Michael Droettboom wrote:

> That's a bug created by not updating thetagrids and rgrids after the  
> recent transformation refactoring.
>
> I believe it is not fixed in r5594.  Can you update and let me know  
> if you're still having trouble?
>
> Thanks,
> Mike
>
> Tony Yu wrote:
>> I was playing around with polar plots and trying to alter the grid  
>> labels when I ran into some weird errors. Whenever I call  
>> pyplot.thetagrids() (and similarly with rgrids) I get:
>>
>> *>>> AttributeError:* 'PolarAxesSubplot' object has no attribute  
>> 'thetagridlines
>>
>> After searching the MPL directory, it didn't seem like  
>> thetagridlines was defined anywhere. Alternatively, If I call  
>> thetagrids with an argument [e.g. thetagrids(range(45,360,90))], I  
>> get
>>
>> *>>> TypeError:* 'NoneType' object is not iterable
>>
>> which comes from the following line in pyplot:
>>
>> >>> lines, labels = ax.set_thetagrids(*args, **kwargs)
>>
>> Strangely, the set_thetagrids method of PolarAxes doesn't return  
>> any values and this is causing the TypeError above.
>>
>> I'm really confused about these errors. Any help would be greatly  
>> appreciated.
>>
>> -Tony
>>
>> PS: Full tracebacks are shown below. I'm on MPL trunk, r5588.
>>
>> CASE 1:
>> 
>> Traceback (most recent call last):
>>  File "polar.py", line 19, in 
>>lines, labels = thetagrids()
>>  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/ 
>> matplotlib/pyplot.py", line 984, in thetagrids
>>lines = ax.thetagridlines()
>> AttributeError: 'PolarAxesSubplot' object has no attribute  
>> 'thetagridlines'
>>
>> CASE 2:
>> 
>> Traceback (most recent call last):
>>  File "polar.py", line 19, in 
>>lines, labels = thetagrids(range(45,360,90))
>>  File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/ 
>> matplotlib/pyplot.py", line 987, in thetagrids
>>lines, labels = ax.set_thetagrids(*args, **kwargs)
>> TypeError: 'NoneType' object is not iterable
>>
>> 
>>
>> -
>> 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
>>
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>


-
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

[matplotlib-devel] Fwd: Repeated method definition in custom_projection_example.py

[Tony Yu]

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

PS. I tried sending this earlier from a non-member email address, but  
the link to cancel the post gave me a "Bad confirmation string" page  
so I wasn't able to cancel the post. Sorry about that.




-
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

Re: [matplotlib-devel] Example images broken in docs

[Tony Yu]

On Jul 7, 2008, at 12:19 PM, Michael Droettboom wrote:

> I noticed today that the examples in the docs have the ticks on the
> outside of the axes.  You can see it here:
>
>  http://matplotlib.sourceforge.net/doc/html/users/pyplot_tutorial.html
>
> I'm having a terrible time tracking down the cause -- maybe I'm just  
> not
> thinking clearly today.  By version bisection, I determined that it
> broke with revision 5690:
>
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=5690
>
> I've verified this twice (cleaning all build and installation remnants
> out in between), and I'm pretty sure that's the revision where  
> things break.
>
> But there's nothing in that revision that leaps out as a cause
> (particularly since the effect is global and affects plots that  
> weren't
> even updated in that revision).

I think this problem is actually caused by contour_demo.py which sets

 >>> matplotlib.rcParams['xtick.direction'] = 'out'
 >>> matplotlib.rcParams['ytick.direction'] = 'out'

Every plot called after contour_demo.py will probably have ticks  
outside of the axes. I think this problem has to do with how Python  
does imports (I'm on shaky ground here, so my explanation may be  
wrong). If matplotlib is already imported then a new call to `import  
matplotlib` doesn't actually do anything. So the above change rcParams  
never gets reinitialized to the default values.

Try adding

 >>> matplotlib.rcParams['xtick.direction'] = 'in'
 >>> matplotlib.rcParams['ytick.direction'] = 'in'

to the end of contour_demo.py.


-Tony

>
> One other tidbit of information -- the example plots work fine when
> called directly.  This only seems to affect plots generated for the  
> docs.
>
> Any ideas?
>
> Mike
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
> -
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Modifications to axis.py to allow more flexibility in positioning axis lines, ticks, etc.

[Tony Yu]

I've been to trying add more flexible control over the axis lines,  
ticks, tick labels, etc., but I think I'm in over my head on this  
project. Again and again, I've settled on one approach only to  
completely rewrite it the next time I look at the code. I'm looking  
for some major design advice/ideas that will make the code simpler  
(AND maintain compatibility with the current implementation of Axis  
and Tick objects).


For simplicity, I've only made changes to the x-axis. Since this  
involves some major changes, I wrote this as a module that subclasses  
XTicks and XAxis as opposed to a patch on axis.py (which would be the  
ultimate, but at this point unlikely, goal). The attached module is  
quite long at the moment, but most of it is comments and methods  
copied (but slightly modified) from `axis.py`. I tried to document how/ 
why the method has changed if I copied the method.


Sorry for the code dump.
-Tony

#!/usr/bin/env python
"""
Add more flexibility in positioning of the x and y axes (only xaxis is implemented, currently).

In this module, I use the word 'frame' to denote the collection of axis elements, i.e. the axis label, ticks, tick-labels, and the axis-line. Is there a better name for this container???

To allow an arbitrary number of frames to be placed on the axes, XAxis stores a list of frames in `XAxis.frames`. Each frame contains parameters that control the look of the axis label, ticks, tick-labels, and axis-line. An x-frame can be placed at any height, `y` (in axes or data coordinates), and has a range `xmin` to `xmax` (in axes or data coordinates).

Unfortunately, XTicks have lists `ticklines`, `labels`, `tick_on`, and `label_on` whose lengths must match the length of `XAxis.frames`. This design seems rather volatile. If each tick were a child of a single XFrame, this complication could be avoided, but this is too much change for now. Is there another way?

To maintain compatibility with the current interface, XAxis.frames[0] and XAxis.frames[1] are reserved for the bottom and top frames, respectively.

I think there maybe some performance issues with this implementation, but I'm not sure where it's coming from.
"""
import numpy as np
from numpy.random import randn

from matplotlib import rcParams
import matplotlib.axis as maxis
import matplotlib.axes as maxes
import matplotlib.text as mtext
import matplotlib.pyplot as plt
import matplotlib.lines as mlines
import matplotlib.artist as martist
import matplotlib.patches as mpatches
import matplotlib.collections as mcoll
import matplotlib.transforms as mtrans
import matplotlib.projections as projections
import matplotlib.font_manager as font_manager


class XTick(maxis.XTick):
"""Customize XTick to place ticks based on XFrame properties.

Add `labels` list to replace `label#`s, `ticklines` list to replace
`tick#line`s, `tick_on` list to replace `label#On`s, and `label_on` to
replace `label#On`. Also, add methods to these lists.
"""
_type_map = {True: 'major', False: 'minor'}
def __init__(self, axes, loc, label, major=True, **kwargs):
"""Override to add `ticklines`, `labels`, `tick_on`, and `label_on`"""
super(XTick, self).__init__(axes, loc, label, major=major, **kwargs)
self._type = self._type_map[major]
# An XTick is at a specific x-position, but draws the tick, tick
# label, etc for every frame at that x-position (just like the
# current implentation has top and bottom ticks drawn by a single
# XTick instance)
# `ticklines` replaces `tick1line` and `tick2line`
self.ticklines = []
# `labels` replaces `label1` and `label2`
self.labels = []
# `tick_on` replaces `tick1On` and `tick2On`
self.tick_on = []
# 'label_on' replaces `label1On` and `label2On`
self.label_on = []
self.num_frames = 0

def _init_frames(self, frames):
"""Initialize frames for XTick."""
# This method is separated from __init__ so the call signature of
# XTick doesn't need to be changed.
self._update_frames(frames)
return self

def _update_frames(self, frames):
"""Add tickline and label for each frame in `frames` list

This method calls `_get_tickline` and  `_get_text` which replicate
the _get_tick#line, _get_text# (# = 1 or 2) methods. Note that
_get_tick#line, _get_text# are called only on XTick init in `axis.py`.
In contrast, `_update_frames` should be called on both XTick init and
XAxis.add_frames so that frames that are added after init are
recognized.
"""
preset = len(self.ticklines)
# redefine `ticklines` and `labels` for preset frames
for n, frame in enumerate(frames[:preset]):
self.ticklines[n] = self._get_tickline(frame)
self.labels[n] = self._get_text(frame)
self.tick_on[n] = frame._tick_on
self.label_on[n] = frame.

[matplotlib-devel] Really minor changes

[Tony Yu]

I noticed a couple of really minor typos as shown below:

Index: matplotlib/lib/matplotlib/axis.py
===
--- matplotlib/lib/matplotlib/axis.py   (revision 5860)
+++ matplotlib/lib/matplotlib/axis.py   (working copy)
@@ -147,7 +147,7 @@
  """
  self._pad = val

-def get_pad(self, val):
+def get_pad(self):
  'Get the value of the tick label pad in points'
  return self._pad

Index: matplotlib/examples/event_handling/lasso_demo.py
===
--- matplotlib/examples/event_handling/lasso_demo.py(revision 5860)
+++ matplotlib/examples/event_handling/lasso_demo.py(working copy)
@@ -69,7 +69,7 @@
  # acquire a lock on the widget drawing
  self.canvas.widgetlock(self.lasso)

-if 0:
+if __name__ == '__main__':

  data = [Datum(*xy) for xy in rand(100, 2)]



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Another colormap

[Tony Yu]

On Fri, Sep 23, 2011 at 1:27 AM, Nathaniel Smith  wrote:

> On Thu, Sep 22, 2011 at 7:00 PM, Benjamin Root  wrote:
> > On Thursday, September 22, 2011, Tony Yu  wrote:
> >> On Thu, Sep 22, 2011 at 5:16 PM, Nathaniel Smith  wrote:
> >>> I looked at the paper, and the goal was specifically to produce a good
> >>> "default" colormap - not necessarily the best for any situation, but
> good
> >>> overall and certainly better than the rainbow ('jet') colormap in most
> >>> cases. (I agree with the author that jet is pretty terrible and tends
> to
> >>> distort data.)
> >>>
> >>> Should we switch to this as the default matplotlib colormap? I think it
> >>> would be a clear improvement.
> >>
> >> I have absolutely no clout here, but I'd definitely be in favor of
> >> changing the default colormap away from "jet".
> >>
> >> Personally, I'd prefer a two-tone colormap as the default (two-distinct
> >> tones at the limits with a gradient in-between---dubbed "sequential" in
> the
> >> paper) instead of a three-tone colormap (three-distinct tones---dubbed
> >> "diverging" in the paper). (I think this is a more common use case, and
> I
> >> think using a "diverging" colormap effectively requires setting
> vmin/vmax.)
> >> But really, (almost) anything is better than "jet".
>
> For those following along, the article is here:
> http://www.cs.unm.edu/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
> The discussion about whether to use a "sequential" or "diverging" map
> is in section 3.
>
> I had the same gut reaction as you, but found the paper fairly
> convincing. I'm used to diverging maps that really highlight the
> center point, like matplotlib's RdBu colormap, and use them all the
> time for data where the zero point really matters (and set vmin/vmax
> appropriately, like you say). But this colormap is actually really
> different from the ones I'm used to, because it's really designed
> *not* to highlight the center point as being special. The clearest
> example of this is Figure 8 in the paper -- the image on the left is
> the one that you'd get from something like RdBu, and the one on the
> right is what this colormap produces. And, like he says, it gives you
> better detail than a sequential map could.
>
> I actually *wouldn't* want to use this for images that I currently use
> RdBu for. But I'm picky -- the map he suggests would still make a heck
> of a better colormap for those images than jet does, and Rdbu *really*
> isn't appropriate for general use.
>
> On Thu, Sep 22, 2011 at 7:00 PM, Benjamin Root  wrote:
> > Anyway, this is certainly is worthy of debate, but it certainly won't
> happen
> > for this release.  We should be cutting RC tomorrow.
> >
> > After the release, I encourage you guys to make your cases.  Show us
> plots
> > that have been in "jet" and show them as better in another colormap.
>
> Figure 16 in that paper (page 17) is a good start. In the examples
> given, for both of the top two jet actively distorts the features of
> the data. In row 1, it makes it look like the bars taper off as you
> move towards the top of the image, which they don't (compare to the
> greyscale image for reference). In row 2, it makes it look like the
> "circles" vary in size across the image (which, again, they don't). In
> the bottom two images, jet introduces apparent asymmetries that aren't
> there: in row 3, you have these 5 apparent stripes of unequal width,
> and the yellow is narrower than the cyan. In row 4, well, it's just
> obviously terribly misleading. (This isn't surprising, since 'jet'
> sweeps through the frequencies of visible light; the big band of
> yellow in simulated deuteranope vision corresponds to where they're
> missing one of the spectral sensors that most of us have.)
>
> If you want more examples though I can certainly pull some out of my
> thesis :-).
>
> > As a bit of a challenge to you all, I am not color-blind, but I do wear
> > tinted glasses that make it difficult to tell the difference between
> darker
> > blues and black, and sometimes greens and blues are hard to distinguish.
> >  Furthermore, as a radar meteorologist, I am very accustomed to the
> > colormaps commonly used for radar reflectivies (and is similar to "jet").
>
> No colormap is going to be perfect for everyone, and maybe someone
> else will pop up with a pointer to a map that's e

[matplotlib-devel] Bug in transform argument for some collections?

[Tony Yu]

There seems to be a bug in the "transform" argument for CircleCollection,
EllipseCollection, and RegularPolyCollection. These classes override any
transform passed on instantiation and uses the IdentityTransform instead.

Take, for example, the init method CircleCollection:

#~~~
def __init__(self, sizes, **kwargs):
"""
*sizes*
Gives the area of the circle in points^2

%(Collection)s
"""
Collection.__init__(self,**kwargs)
self._sizes = sizes
self.set_transform(transforms.IdentityTransform())
self._paths = [mpath.Path.unit_circle()]
#~~~

If "transform" is passed as a kwarg, it gets updated by the call to
``Collection.__init__`` (this update is done in Artist, which is a parent
class of Collection). But a couple lines after that, the transform is
manually reset to the IdentityTransform. Is this a bug?

As it stands, setting the transform kwarg does nothing (and doesn't
complain), so I have to call the set_transform method after creating the
collection (not a big deal, but it's confusing that the first option
doesn't work).

A couple of notes:
* Artist already defaults to setting Artist._transform (and hence
Collection._transform) to the IdentityTransform.
* Nevertheless, the set_transform line above is *not* a do-nothing line:
not only does set_transform set the _transform attribute, it also sets the
_transformSet attribute.

A few solutions:
* Replace the set_transform line with ``self._transformSet = True``.
(preserves current behavior, without overriding a user-prescribed transform)
* Replace transform passed to self.set_transform with self.get_transform.
(same behavior as above.)
* Just remove the set_transform line. This changes the behavior since
self._transformSet is left False, but I'm not sure what the correct
behavior is.

-Tony
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

[Tony Yu]

On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing  wrote:

> On 12/30/2011 01:57 PM, Paul Ivanov wrote:
>
>> Eric Firing, on 2011-12-27 15:31,  wrote:
>>
>>> It looks like this is something I can fix by modifying ListedColormap.
>>> It is discarding the alpha values, and I don't think there is any reason
>>> it needs to do so.
>>>
>>
>> One of my first attempts at a contribution to matplotlib three
>> years ago was related to this. It was in reply to a similar
>> question on list, and I wrote a patch, but never saw it through
>> to inclusion because it wasn't something I needed.
>>
>> http://www.mail-archive.com/**matplotlib-users@lists.**
>> sourceforge.net/msg09216.html
>>
>> I think it's a helpful starting point, as I include a discussion
>> on the limitation of mpl colormaps there.
>>
>
> I'm switching this to the devel list.
>
> Please try
> https://github.com/efiring/**matplotlib/tree/colormap_alpha
> which has changes similar to yours so that alpha is fully changeable in
> colormaps.
>
> I think this is going to be OK as far as the colormap end of things is
> concerned, but it turns up a new problem related to alpha in images, and
> reminds us of an old problem with alpha in agg, at least.  The problems are
> illustrated in the attached modification of the custom_cmap.py example.  I
> added a fourth panel for testing alpha.  Look at the comments on the code
> for that panel, and try switching between pcolormesh and imshow.
>  Pcolormesh basically works as expected, except for the prominent artifacts
> on patch boundaries (visible also in the colorbar for that panel).  These
> boundary artifacts are the old problem. The new problem is that imshow with
> alpha in the colormap is completely wonky with a white background, but
> looks more normal with a black background--which is not so good if what you
> really want is a white background showing through the transparency.
>
> Eric
>

This is great! I had hacked together a custom colormap class and overrode
its __call__ method to get a similar effect. This solution is much more
elegant and general.

As for the imshow issue, it seems to be an issue with the "nearest"
interpolation method. The example copied below shows the result for three
different interpolation methods. The weird behavior only occurs when
interpolation is set to 'nearest' (I checked all other interpolation
methods, not just the 3 below). What's really strange is that
`interpolation='none'` gives the expected result, but in theory, 'none'
maps to the same interpolation function as 'nearest'. A quick scan of
matplotlib.image suggests that 'none' and 'nearest' share the same code
path, but I'm obviously missing something.

-Tony

#
import matplotlib.pyplot as plt


cdict = {'red':  ((0.0, 0.0, 0.0),
  (0.5, 0.8, 1.0),
  (1.0, 0.4, 1.0)),

'green': ((0.0, 0.0, 0.0),
  (0.5, 0.9, 0.9),
  (1.0, 0.0, 0.0)),

'blue':  ((0.0, 0.0, 0.4),
  (0.5, 1.0, 0.8),
  (1.0, 0.0, 0.0)),

'alpha': ((0.0, 1.0, 1.0),
  (0.5, 0.3, 0.3),
  (1.0, 1.0, 1.0))}

plt.register_cmap(name='BlueRedAlpha', data=cdict)


if __name__ == '__main__':
import numpy as np

w = 10
y = np.linspace(0, 2*np.pi, w+1)
Z = np.tile(y, (w+1, 1))

plt.rcParams['image.cmap'] = 'BlueRedAlpha'

f, axes = plt.subplots(ncols=3)
interp_method = ['none', 'bilinear', 'nearest']
for interp, ax in zip(interp_method, axes):
# Draw a line with low zorder so it will be behind the image.
ax.plot([0, w], [0, w], color='c', lw=20, zorder=-1)
ax.imshow(Z, interpolation=interp)
ax.set_title(interp)

plt.show()
#
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

[Tony Yu]

 On Tue, Jan 3, 2012 at 1:10 AM, Eric Firing  wrote:

> On 01/02/2012 05:51 PM, Tony Yu wrote:
>
>>
>>
>> On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing > <mailto:efir...@hawaii.edu>> wrote:
>>
>>On 12/30/2011 01:57 PM, Paul Ivanov wrote:
>>
>>Eric Firing, on 2011-12-27 15:31,  wrote:
>>
>>It looks like this is something I can fix by modifying
>>ListedColormap.
>>It is discarding the alpha values, and I don't think there
>>is any reason
>>it needs to do so.
>>
>>
>>One of my first attempts at a contribution to matplotlib three
>>years ago was related to this. It was in reply to a similar
>>question on list, and I wrote a patch, but never saw it through
>>to inclusion because it wasn't something I needed.
>>
>>http://www.mail-archive.com/__**matplotlib-users@lists.__**
>> sourceforge.net/msg09216.html<http://www.mail-archive.com/__matplotlib-users@lists.__sourceforge.net/msg09216.html>
>>
>><http://www.mail-archive.com/**matplotlib-users@lists.**
>> sourceforge.net/msg09216.html<http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg09216.html>
>> >
>>
>>I think it's a helpful starting point, as I include a discussion
>>on the limitation of mpl colormaps there.
>>
>>
>>I'm switching this to the devel list.
>>
>>Please try
>>
>> https://github.com/efiring/__**matplotlib/tree/colormap_alpha<https://github.com/efiring/__matplotlib/tree/colormap_alpha>
>>
>>
>> <https://github.com/efiring/**matplotlib/tree/colormap_alpha<https://github.com/efiring/matplotlib/tree/colormap_alpha>
>> **>
>>which has changes similar to yours so that alpha is fully changeable
>>in colormaps.
>>
>>I think this is going to be OK as far as the colormap end of things
>>is concerned, but it turns up a new problem related to alpha in
>>images, and reminds us of an old problem with alpha in agg, at
>>least.  The problems are illustrated in the attached modification of
>>the custom_cmap.py example.  I added a fourth panel for testing
>>alpha.  Look at the comments on the code for that panel, and try
>>switching between pcolormesh and imshow.  Pcolormesh basically works
>>as expected, except for the prominent artifacts on patch boundaries
>>(visible also in the colorbar for that panel).  These boundary
>>artifacts are the old problem. The new problem is that imshow with
>>alpha in the colormap is completely wonky with a white background,
>>but looks more normal with a black background--which is not so good
>>if what you really want is a white background showing through the
>>transparency.
>>
>>Eric
>>
>>
>> This is great! I had hacked together a custom colormap class and
>> overrode its __call__ method to get a similar effect. This solution is
>> much more elegant and general.
>>
>> As for the imshow issue, it seems to be an issue with the "nearest"
>> interpolation method. The example copied below shows the result for
>> three different interpolation methods. The weird behavior only occurs
>> when interpolation is set to 'nearest' (I checked all other
>> interpolation methods, not just the 3 below). What's really strange is
>> that `interpolation='none'` gives the expected result, but in theory,
>> 'none' maps to the same interpolation function as 'nearest'. A quick
>> scan of matplotlib.image suggests that 'none' and 'nearest' share the
>> same code path, but I'm obviously missing something.
>>
>
> It looks to me like 'none' is going through _draw_unsampled_image instead
> of the path that all the other interpolations, including 'nearest' go
> through.  I think that JJ put in this unsampled functionality about two
> years ago.  I've never dug into the guts of image operations and rendering,
> so I don't even understand what sort of "sampling" is referred to here.
>
> Eric
>

Well, that's embarrassing: Apparently I searched for 'none' with single
quotes, but not double quotes.

Unfortunately, I can't figure out the issue, but while debugging, I noticed
that constant alpha values have the same issue. For example, if you replace
the alpha spec in the custom colormap with:

 'alpha': ((0.0, 0.7, 0.7),
  

[matplotlib-devel] Add `streamplot` function

[Tony Yu]

I just submitted a pull request to add a `streamplot` function to plot the
streamlines of a vector field. This implementation is a modified version of
the streamplot function posted to the list by Tom Flannagan [1].

This PR isn't complete, but I wanted to submit it in order to get comments.
In particular:

* I haven't added the pyplot function, only the axes method. It looks like
the pyplot function should be generated by some boiler plate code.

* I'm not sure what the docstring conventions are (the code isn't terribly
consistent), so I just (more-or-less) followed the numpy docs.

* Some parameter that probably should be adjustable aren't at the moment
(e.g. max streamline length, some arrow properties).

* I left the original copyright from Tom's implementation, but I don't know
if the BSD license has anything to say about that.

I'm not totally familiar with the matplotlib architecture so I'm probably
forgetting a number of things. Feedback appreciated.

-Tony

[1]
http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg20208.html
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Test invitation: activate figure windows for non-interactive macosx backend

[Tony Yu]

On Thu, Jan 12, 2012 at 1:37 PM, Gellule Xg  wrote:

> If you are a macosx backend user, you are welcomed to test the following
> branch: https://github.com/gellule/matplotlib. With the branch, when
> issuing a pylab.show() in non-interactive mode, the plot windows should
> appear in the foreground with focus, instead of appearing in the
> background. It should make things a little easier for you.
>

This works as advertised on my system (plot window grabs focus when running
scripts in MacVim, Terminal, and IPython when in non-interactive mode).
Unfortunately, I tend to use the QT4Agg backend, which also leaves plot
windows in the background. Maybe I'd switch to the macosx backend with this
addition.


> I am also curious to know what people think of making pylab.show() also
> yield the focus to the plot windows in -interactive- mode? All the other
> commands update the plot windows automatically, keeping the focus in the
> python interpreter. So pylab.show() would only do that: yield the focus
> to the plot windows. That is not in the branch (yet).
>

I'd lean toward no: the plot window shouldn't grab focus in interactive
mode. I have some scripts that take command-line input in-between plot
calls. If the plot window grabbed focus, then I'd have to switch focus back
to enter input. This probably isn't a common use case, though.

-Tony


>
> Cheers,
>
> -Gellule/Julien
>
>
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Test invitation: activate figure windows for non-interactive macosx backend

[Tony Yu]

On Fri, Jan 13, 2012 at 6:32 PM, Gellule Xg  wrote:

> On 1/13/12 12:53 , Tony Yu wrote:
>
>>
>> On Thu, Jan 12, 2012 at 1:37 PM, Gellule Xg > <mailto:gellule...@free.fr>> wrote:
>>
>>If you are a macosx backend user, you are welcomed to test the
>> following
>>branch: 
>> https://github.com/gellule/**matplotlib<https://github.com/gellule/matplotlib>.
>> With the branch, when
>>issuing a pylab.show() in non-interactive mode, the plot windows should
>>appear in the foreground with focus, instead of appearing in the
>>background. It should make things a little easier for you.
>>
>>
>> This works as advertised on my system (plot window grabs focus when
>> running scripts in MacVim, Terminal, and IPython when in non-interactive
>> mode). Unfortunately, I tend to use the QT4Agg backend, which also
>> leaves plot windows in the background. Maybe I'd switch to the macosx
>> backend with this addition.
>>
>
> Thanks!
>
> I am also curious to know what people think of making pylab.show() also
>>yield the focus to the plot windows in -interactive- mode? All the
>> other
>>commands update the plot windows automatically, keeping the focus in
>> the
>>python interpreter. So pylab.show() would only do that: yield the focus
>>to the plot windows. That is not in the branch (yet).
>>
>>
>> I'd lean toward no: the plot window shouldn't grab focus in interactive
>> mode. I have some scripts that take command-line input in-between plot
>> calls. If the plot window grabbed focus, then I'd have to switch focus
>> back to enter input. This probably isn't a common use case, though.
>>
>
> But you don't use show() in interactive mode, do you? The focus grab would
> not happen until you call show().
>
> I other words, show() would always send the focus to the plot windows. But
> depending on how interactive is set, it would block or not. If you are in
> interactive mode and don't want to send the focus to the plot windows, you
> would have to not call show().
>
> -Julien
>

Good point: my scripts call draw(), instead of show(). Ignore what I said
earlier. :)

-Tony
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] "Data cursor" for matplotilb.widgets

[Tony Yu]

On Sun, Jan 22, 2012 at 5:58 PM, Joe Kington wrote:

> I've recently been playing around with a widget intended to be similar to
> matlab's "data cursor".
>
> Would this be useful for inclusion into matplotlib.widgets?
>
> https://gist.github.com/1659108
>
> At the moment, it doesn't inherit from the base Widget class, but that's
> easily changed.
>
> On the other hand, it doesn't fit the model of the rest of the widgets in
> that it takes a sequence (or single) artist, instead of an axes instance.
>
> If folks think it would be useful, I can submit a pull request.
>
> Thanks,
> -Joe
>

This is pretty cool. Any idea how much work it would take to add handling
of images?

-Tony
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] "Data cursor" for matplotilb.widgets

[Tony Yu]

On Tue, Jan 24, 2012 at 10:12 AM, Tony Yu  wrote:

>
>
> On Sun, Jan 22, 2012 at 5:58 PM, Joe Kington wrote:
>
>> I've recently been playing around with a widget intended to be similar to
>> matlab's "data cursor".
>>
>> Would this be useful for inclusion into matplotlib.widgets?
>>
>> https://gist.github.com/1659108
>>
>> At the moment, it doesn't inherit from the base Widget class, but that's
>> easily changed.
>>
>> On the other hand, it doesn't fit the model of the rest of the widgets in
>> that it takes a sequence (or single) artist, instead of an axes instance.
>>
>> If folks think it would be useful, I can submit a pull request.
>>
>> Thanks,
>> -Joe
>>
>
> This is pretty cool. Any idea how much work it would take to add handling
> of images?
>
> -Tony
>

Just to clarify: by "handling images", I mean displaying the intensity
value at a point (it currently just displays the x, y coordinates).

-Tony
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] Problem with cachedRenderer

[Tony Yu]

On Wed, Jan 25, 2012 at 7:14 AM, andi  wrote:

>  Hi Tony,
>
> thanks for your reply! I am not using the pdf backend, but the GTKAgg
> backend. Is it working with this backend in the development version?
>
> Cheers
> Andi
>

Hi Andi,

Unfortunately, I can't run the GTKAgg backend, but I checked your code
snippet on the backends I have on my system. It seems this behavior is
really inconsistent:

Works:
* agg
* qt4agg
* tkagg

Doesn't work:
* pdf
* macosx

To be honest, I don't understand the magical workings of the backends very
well. I've copied the developer list since the consistency of backends
seems like a relevant issue.

-Tony

P.S. Andi: Be sure to "reply all" since the mailing list doesn't
automatically do this for some reason.


>
> On 25/01/12 00:26, Tony Yu wrote:
>
>
>
> On Tue, Jan 24, 2012 at 12:53 PM, andi  wrote:
>
>> Hi all,
>>
>> I have some old custom code for generating videos from matplotlib (not
>> using the animation module). It used to work, but is now failing.
>> Here is what I am doing:
>>
>> ---
>> import matplotlib.pyplot as plt
>> import numpy as np
>>
>> fig = plt.figure()
>> ax = fig.add_subplot(111)
>> im = ax.imshow(np.zeros((100, 100)))
>> fig.canvas.draw()
>> ax.draw_artist(im)
>> --
>>
>> ... and draw_artist from axes.py then gives me an AssertionError because
>> no renderer is found (assert self._cachedRenderer is not None).
>>
>> Right now I am using matplotlib 1.0.1 and I think that the above used to
>> work with older versions in matplotlib. See e.g.
>>
>> http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/msg06598.html
>>
>> Any ideas?
>>
>> Cheers
>> Andi
>>
>>
> Hi Andi,
>
> I'm running a development version of matplotlib, and your code runs
> without issue. That doesn't really solve your issue, but it means that it's
> not due to deprecation.
>
> On a hunch, I tried running the code with
> >>> import matplotlib
> >>> matplotlib.use('pdf')
> at the top of the file, and I got the same error. Not really sure why,
> though. Do you happen to have the pdf backend set as the default?
>
> -Tony
>
>
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Font rc-setting not updating

[Tony Yu]

The title is a bit misleading: The problem is that the last font-related
rc-setting seems to override all previous settings. To clarify, if I save a
figure with certain font settings and *after that* change the rc-setting,
the older figure appears to have the newer setting. Note that this only
appears to happen with fonts---the linewidth setting, for example, shows up
as expected. (See script belows)


-Tony


import matplotlib.pyplot as plt

def test_simple_plot():
fig, ax = plt.subplots()

ax.plot([0, 1])
ax.set_xlabel('x-label')
ax.set_ylabel('y-label')
ax.set_title('title')

return fig

plt.rcParams['lines.linewidth'] = 10
plt.rcParams['font.family'] = 'serif'
plt.rcParams['font.size'] = 20
fig1 = test_simple_plot()

plt.rcParams['lines.linewidth'] = 1
plt.rcParams['font.family'] = 'sans-serif'
plt.rcParams['font.size'] = 10
fig2 = test_simple_plot()

plt.show()
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] faulty design for Lasso widget?

[Tony Yu]

On Fri, Feb 17, 2012 at 12:17 PM, Benjamin Root  wrote:

>
>
> On Fri, Feb 17, 2012 at 11:06 AM, Ryan May  wrote:
>
>> On Fri, Feb 17, 2012 at 10:14 AM, Benjamin Root  wrote:
>> > Hello all,
>> >
>> > I tracked down an annoying problem in one of applications to the Lasso
>> > widget I was using.  The widget constructor lets you specify a function
>> to
>> > call when the lasso operation is complete.  So, when I create a Lasso,
>> I set
>> > the canvas's widget lock to the new lasso, and the release function will
>> > unlock it when it is done.  What would occassionally happen is that the
>> > canvas wouldn't get unlocked and I wouldn't be able to use any other
>> widget
>> > tools.
>> >
>> > It turns out that the release function is not called if the number of
>> > vertices collected is not more than 2.  So, accidental clicks that
>> activate
>> > the lasso never get cleaned up.  Because of this design, it would be
>> > impossible to guarantee a proper cleanup.  One could add another
>> > button_release callback to clean up if the canvas is still locked, but
>> there
>> > is no guarantee that that callback is not called before the lasso's
>> > callback, thereby creating a race condition.
>> >
>> > The only solution I see is to guarantee that the release callback will
>> be
>> > called regardless of the length of the vertices array.  Does anybody
>> see a
>> > problem with that?
>>
>> Not having looked at the Lasso code, wouldn't it be possible to use
>> one internal callback for the button_release event, and have this
>> callback call the users' callbacks if points > 2 and always handle the
>> unlocking of the canvas?
>>
>> Ryan
>>
>>
> The problem is that the constructor does not establish the lock.  It is
> the user's responsibility to establish a lock and release the locks for
> these widgets.  Plus, if the user's callback has cleanup code (such as mine
> did), not guaranteeing that the callback is done can leave behind a mess.
>
> Now, if we were to change the paradigm so that the Widget class
> establishes and releases the lock, and that the user should never handle
> that, then that might be a partial solution, but still leaves unsolved the
> user's cleanup needs.
>
> Ben Root
>
> I just started looking at the Lasso widget for some other changes, and I
agree: the `points > 2` check should be removed.

As for the design of Lasso, I don't quite understand why it disconnects the
callbacks after a single call. If the onpress event from the lasso
demowas
made a method of Lasso, then you could reuse the Lasso widget instead
of having to create a new one for each selection. Of course, this might
complicate the widget lock used in the demo, but that's true for all other
widgets, right?

-Tony
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] faulty design for Lasso widget?

[Tony Yu]

On Tue, Feb 28, 2012 at 2:04 PM, Benjamin Root  wrote:

>
>
> On Tue, Feb 28, 2012 at 1:00 PM, Tony Yu  wrote:
>
>>
>>
>> On Tue, Feb 28, 2012 at 11:44 AM, Benjamin Root  wrote:
>>
>>> On Mon, Feb 27, 2012 at 9:45 PM, Tony Yu  wrote:
>>>
>>>>
>>>>
>>>> On Fri, Feb 17, 2012 at 12:17 PM, Benjamin Root wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 17, 2012 at 11:06 AM, Ryan May  wrote:
>>>>>
>>>>>> On Fri, Feb 17, 2012 at 10:14 AM, Benjamin Root 
>>>>>> wrote:
>>>>>> > Hello all,
>>>>>> >
>>>>>> > I tracked down an annoying problem in one of applications to the
>>>>>> Lasso
>>>>>> > widget I was using.  The widget constructor lets you specify a
>>>>>> function to
>>>>>> > call when the lasso operation is complete.  So, when I create a
>>>>>> Lasso, I set
>>>>>> > the canvas's widget lock to the new lasso, and the release function
>>>>>> will
>>>>>> > unlock it when it is done.  What would occassionally happen is that
>>>>>> the
>>>>>> > canvas wouldn't get unlocked and I wouldn't be able to use any
>>>>>> other widget
>>>>>> > tools.
>>>>>> >
>>>>>> > It turns out that the release function is not called if the number
>>>>>> of
>>>>>> > vertices collected is not more than 2.  So, accidental clicks that
>>>>>> activate
>>>>>> > the lasso never get cleaned up.  Because of this design, it would be
>>>>>> > impossible to guarantee a proper cleanup.  One could add another
>>>>>> > button_release callback to clean up if the canvas is still locked,
>>>>>> but there
>>>>>> > is no guarantee that that callback is not called before the lasso's
>>>>>> > callback, thereby creating a race condition.
>>>>>> >
>>>>>> > The only solution I see is to guarantee that the release callback
>>>>>> will be
>>>>>> > called regardless of the length of the vertices array.  Does
>>>>>> anybody see a
>>>>>> > problem with that?
>>>>>>
>>>>>> Not having looked at the Lasso code, wouldn't it be possible to use
>>>>>> one internal callback for the button_release event, and have this
>>>>>> callback call the users' callbacks if points > 2 and always handle the
>>>>>> unlocking of the canvas?
>>>>>>
>>>>>> Ryan
>>>>>>
>>>>>>
>>>>> The problem is that the constructor does not establish the lock.  It
>>>>> is the user's responsibility to establish a lock and release the locks for
>>>>> these widgets.  Plus, if the user's callback has cleanup code (such as 
>>>>> mine
>>>>> did), not guaranteeing that the callback is done can leave behind a mess.
>>>>>
>>>>> Now, if we were to change the paradigm so that the Widget class
>>>>> establishes and releases the lock, and that the user should never handle
>>>>> that, then that might be a partial solution, but still leaves unsolved the
>>>>> user's cleanup needs.
>>>>>
>>>>> Ben Root
>>>>>
>>>>> I just started looking at the Lasso widget for some other changes, and
>>>> I agree: the `points > 2` check should be removed.
>>>>
>>>> As for the design of Lasso, I don't quite understand why it disconnects
>>>> the callbacks after a single call. If the onpress event from the lasso
>>>> demo<http://matplotlib.sourceforge.net/examples/event_handling/lasso_demo.html>was
>>>>  made a method of Lasso, then you could reuse the Lasso widget instead
>>>> of having to create a new one for each selection. Of course, this might
>>>> complicate the widget lock used in the demo, but that's true for all other
>>>> widgets, right?
>>>>
>>>> -Tony
>>>>
>>>>
>>> The Lasso disconnects itself after the button_release event because
>>> that's what indicates that you are done.  The user gets bac

[matplotlib-devel] Resizing bug in qt4 backend.

[Tony Yu]

When resizing a figure using `fig.set_size_inches`, the Qt backend doesn't
take into account the height of the status bar or the toolbar.

For example, the following script plots two figures---both *should* be
1-inch square, but this is only true of the second figure.

#~
import matplotlib as mpl
mpl.use('qt4agg')
import matplotlib.pyplot as plt

fig = plt.figure()
fig.set_size_inches(1, 1, forward=True)

plt.figure(figsize=(1, 1))

plt.show()
#~

Note that this bug doesn't appear with `savefig` since that doesn't need to
account of toolbar/status bar heights.

I've submitted a PR for a
fix,
but I don't know how general this is. For example, I couldn't get the
figure to redraw after changing the figure size with `fig.set_figwidth` or
`fig.set_figheight`, so I couldn't test for that.

Also, I noticed that 'tkagg' has problems with this example code, but I
didn't have time to look into that.

-Tony
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Minor bug with colo(u)rs outstanding since 2007

[Tony Yu]

On Fri, Mar 9, 2012 at 3:54 PM, Peter Hansen  wrote:

> I was just analyzing why 145 colours were listed in
> matplotlib.colors.cnames instead of the 140 that are apparently "HTML
> standard" and, although there's a good reason for that, in the process I
> discovered that an issue reported in 2007 in the mailing list is still
> outstanding in 1.1.0:
>
>
> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg00669.html
>
> Basically, although there is block of code there to "add british
> equivs", the master list already has the British 'lightgrey' in it,
> instead of 'lightgray'.  For consistency with all the other cases
> ('darkgray', 'dimgray', etc) the patch in the message above should be
> applied, with the result that both "lightgray" and "lightgrey" would be
> legal, as all the other types of gray already are.
>
> Is this something I should just ticket, or is a report here sufficient?
>
> Thanks.
> --
> Peter Hansen, P.Eng.
> Engenuity Corporation


It's a trivial change, but I added a PR to fix
this,
just to make it as easy as possible for the devs.
-Tony
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Different alphas for patch edges and faces

[Tony Yu]

Is it possible to set different alpha values for patch edges and faces?

I found an old thread on this
topic.
It seems like there was some general agreement about the design. Was there
any progress on the implementation?

Thanks,
-Tony
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Using `hexbin` with `edgecolors = 'none'`

[Tony Yu]

I'm drawing hexbins with alpha < 1 and get dark lines at the bin edges. It
turns out that setting `edgecolors = 'none'` sets the edge color to be the
same as the face color, as mentioned in the docstring:

   If ``'none'``, draws the edges in the same color as the fill
color.
   This is the default, as it avoids unsightly unpainted pixels
   between the hexagons.

This behavior is a bit weird, since setting colors to 'none' usually makes
the element invisible. Wouldn't it be more consistent to let 'none' be
passed to the PolyCollection (which draws the hexbins), such that edges
aren't drawn. Then, to maintain the current behavior, change the default to
'face'. (Of course, this wouldn't really maintain current behavior for code
that explicitly passes `edgecolors='none'`.)

Also, if I let 'none' get passed to the PolyCollection, I don't see the
"unsightly unpainted pixels between the hexagons". Is this just a
system-dependent artifact, or is it an outdated docstring?

Thanks,
-Tony
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Using `hexbin` with `edgecolors = 'none'`

[Tony Yu]

On Mon, Mar 26, 2012 at 7:42 PM, Tony Yu  wrote:

> I'm drawing hexbins with alpha < 1 and get dark lines at the bin edges. It
> turns out that setting `edgecolors = 'none'` sets the edge color to be the
> same as the face color, as mentioned in the docstring:
>
>If ``'none'``, draws the edges in the same color as the fill
> color.
>This is the default, as it avoids unsightly unpainted pixels
>between the hexagons.
>
> This behavior is a bit weird, since setting colors to 'none' usually makes
> the element invisible. Wouldn't it be more consistent to let 'none' be
> passed to the PolyCollection (which draws the hexbins), such that edges
> aren't drawn. Then, to maintain the current behavior, change the default to
> 'face'. (Of course, this wouldn't really maintain current behavior for code
> that explicitly passes `edgecolors='none'`.)
>
> Also, if I let 'none' get passed to the PolyCollection, I don't see the
> "unsightly unpainted pixels between the hexagons". Is this just a
> system-dependent artifact, or is it an outdated docstring?
>
> Thanks,
> -Tony
>

Just to clarify, here's an example of how I think hexbin should behave:
https://github.com/tonysyu/matplotlib/commit/39e28540d30a55c18975533fe3625c47506c5908

-Tony
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Saving animations

[Tony Yu]

On Sat, Apr 7, 2012 at 8:40 PM, Benjamin Root  wrote:

>
>
> On Sat, Apr 7, 2012 at 1:34 PM, Tony Yu  wrote:
>
>> I've been using the animations subpackage since it was introduced, but I
>> only recently tried to save an animation using the `save` method.
>> Unfortnately, I get a RuntimeError whenever I try to use it:
>>
>> ...
>>   File
>> "/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_agg.py", line
>> 4
>> 52, in print_raw
>> renderer._renderer.write_rgba(filename_or_obj)
>> RuntimeError: Error writing to file
>>
>>
>> This can be reproduced with any animation example, e.g. 
>> simple_anim.py<http://matplotlib.sourceforge.net/examples/animation/simple_anim.html>,
>>  by
>> replacing `plt.show()` with `ani.save('simple_anim.avi')`. The actual error
>> is from a shell call to ffmpeg, which roughly boils down to:
>>
>> #
>> import subprocess
>> import matplotlib.pyplot as plt
>>
>> fig, ax = plt.subplots()
>> ax.plot([0, 1])
>> command = ['ffmpeg', '-f', 'rawvideo', '-vcodec', 'rawvideo',
>>'-s', '800x600', '-pix_fmt', 'rgba', '-r', '5.0',
>>'-i', 'pipe:', '-vcodec', 'mpeg4', '-y', 'test.avi']
>> proc= subprocess.Popen(command, shell=False, stdout=subprocess.PIPE,
>>stderr=subprocess.STDOUT,
>> stdin=subprocess.PIPE)
>> fileobj = proc.stdin
>> fig.savefig(fileobj, format='rgba', dpi=100)
>> #
>>
>> (I just copied the ffmpeg command from an example run, so the option
>> values may vary on other systems.) The error here is the same, and,
>> unfortunately, not very informative. Is this saving functionality platform
>> dependent? (I'm on osx.)
>>
>> Thanks,
>> -Tony
>>
>>
> Tony,
>
> The animation saving feature has be completely rewritten by Ryan recently
> and is in master.  Could you give that a try?
>
> Ben Root
>
> Hey Ben,

This is error is using the current master, actually. I think the previous
implementation saved images and read them with ffmpeg (or some other
utility) instead of piping directly to ffmpeg.

-Tony

(Ben: sorry for the duplicate emails. Forgot to "reply-all")
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Qt close bug revisited

[Tony Yu]

I'm getting a strange error when multiple figures are created *without a
call to show*. Here's the traceback:

Traceback (most recent call last):
  File
"/Users/Tony/python/devel/mpl/lib/matplotlib/backends/backend_qt4.py", line
151, in 
lambda: self.close_event())
  File "/Users/Tony/python/devel/mpl/lib/matplotlib/backend_bases.py", line
1564, in close_event
self.callbacks.process(s, event)
AttributeError: 'FigureCanvasQTAgg' object has no attribute 'callbacks'


Here's a simple test case:

import matplotlib.pyplot as plt
fig = plt.figure()
plt.plot([0, 1])
fig = plt.figure()
plt.plot([0, 1])


This issue appears in versions after the PR to fix the Qt4 close
bug.
The error occurs even without the `plot` calls, but the failures aren't as
consistent (the error will randomly disappear).

Note that sticking a call to `plt.show()` at the end and then manually
closing the figures does not seem to produce this error. I'm having a
difficult time locating the source of the bug: when I stick a pdb trace in
the code, the error doesn't get raised.

Can anyone reproduce this issue?

-Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Tony Yu]

On Fri, May 11, 2012 at 4:20 PM, Benjamin Root  wrote:

>
>
> On Fri, May 11, 2012 at 4:17 PM, Paul Ivanov  wrote:
>
>> Hey everyone,
>>
>> I wanted to highlight Matthew Emmett's (memmett) PR in progress [1] that
>> brings the ability to switch between rcParams.
>>
>> Matthew's implementation started with just being able to read in and use
>> an rcParam file, and I suggested the idea of having a context manager,
>> that would allow you to do something like:
>>
>>  with rc_context(fname):
>>  plt.plot()
>>  ...
>>
>> and have the rcParams restored outside of the context.
>>
>> I know there have been a few threads (can't find links now for some
>> reason) and in-person discussions in the past about having this kind of
>> ability in matplotlib, and having an idea of "styles", and Tony Yu
>> implemented a variant of this on top of matplotlib in mpltools [2], but
>> I wanted to ping the list here for other ideas and feelings about such
>> functionality (if anyone can find pointers to previous discussions, that
>> would be very welcome).
>>
>> 1. https://github.com/matplotlib/matplotlib/pull/861
>> 2. https://github.com/tonysyu/mpltools
>>
>> best,
>> --
>> Paul Ivanov
>> 314 address only used for lists,  off-list direct email at:
>> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>>
>>
> Such a feature would clean up the test code considerably.
>
> Ben Root
>
>
Thanks for pinging me on the PR, Paul. Both the original PR and the
addition of the context manager are great ideas.

Just to clarify, what I implemented in mpltools was a sort-of stylesheet
that can be easily accessed (i.e. you don't have to remember the path, just
the name; and if you forget that, it's listed in a module attribute). But,
I ended up using ConfigObj to parse the rc file instead of using
matplotlib's parser. One major disadvantage of that approach is that
ConfigObj uses a different syntax than matplotlib's rc parameters. In this
sense, the PR would help greatly to fix this discrepancy.

Unfortunately, the PR doesn't completely fulfill my needs. I wanted to
allow multiple stylesheets to be declared in a single file; this means I'd
need to plug into the loop that iterates over the lines of the file. I can
push in that direction on the PR, but I don't want to do that unless people
think this would be more-generally useful.

-Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] switching rc files (and discussion of styles)

[Tony Yu]

On Sat, May 12, 2012 at 3:11 PM, Gökhan Sever  wrote:

> Hello,
>
> This is a good idea indeed. Especially, when one creates plots for
> presentations and papers. Usually, I make ticks, ticklabels, axes labels,
> line widths, marker sizes as large as possible (within reasonable limits)
> to make them more readable for presentation purposes. However, the same
> element sizes don't look very pretty when I create the same plots for paper
> or vice versa. The solution is either keep modify two rc files or adjust
> one rc file accordingly for each plotting style.
>
> Could the syntax be simplfied a bit? Say rather than using that with
> statement and the extra 4 spaces, can it be just a one simple liner like
> matplotlib.rcuse(mpl_paper.rc) or matplotlib.rcuse(mpl_presentation.rc)?
>

I believe that's what the `rc_file` function does in the
PR<https://github.com/matplotlib/matplotlib/pull/861/files>,
so both use cases are possible. I think it makes sense to allow both.

Cheers,
-Tony


On Fri, May 11, 2012 at 2:17 PM, Paul Ivanov  wrote:
>
>> Hey everyone,
>>
>> I wanted to highlight Matthew Emmett's (memmett) PR in progress [1] that
>> brings the ability to switch between rcParams.
>>
>> Matthew's implementation started with just being able to read in and use
>> an rcParam file, and I suggested the idea of having a context manager,
>> that would allow you to do something like:
>>
>>  with rc_context(fname):
>>  plt.plot()
>>  ...
>>
>> and have the rcParams restored outside of the context.
>>
>> I know there have been a few threads (can't find links now for some
>> reason) and in-person discussions in the past about having this kind of
>> ability in matplotlib, and having an idea of "styles", and Tony Yu
>> implemented a variant of this on top of matplotlib in mpltools [2], but
>> I wanted to ping the list here for other ideas and feelings about such
>> functionality (if anyone can find pointers to previous discussions, that
>> would be very welcome).
>>
>> 1. https://github.com/matplotlib/matplotlib/pull/861
>> 2. https://github.com/tonysyu/mpltools
>>
>> best,
>> --
>> Paul Ivanov
>> 314 address only used for lists,  off-list direct email at:
>> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> --
> Gökhan
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Strange bug when saving animations (with streamplot)

[Tony Yu]

I'm having a tough time figuring this out: Saving an animation seems to
hang when using `streamplot`. The exact same animation runs without issue
when calling show.

On my system, the example below hangs consistently at frame 173. However,
the number of saved frames (before hanging) varies with density of stream
lines (i.e. number of line segments in streamplot): More frames saved for
lower density.

Seems to be a memory or file-size issue, but

   * Memory use doesn't seem to grow. (this suggests that ffmpeg adds
frames to disk as opposed to memory.)
   * Saving the animation up to the frame just before it hangs gives modest
(~1MB) videos.
Maybe this is a limitation of `ffmpeg`?

Can someone confirm that the example hangs on their system? (Somehow, I
often run into bugs that are not reproducible.)

In case this is system dependent:
* OSX 10.6
* Python 2.6.1 (system install)
* matplotlib master
* ffmpeg 0.10

Simple plots seem to work fine, but I should probably try to reproduce
using something other than streamplot (maybe create the equivalent number
of line and arrow collections).

-Tony

#~~~ Example
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.animation as animation

fig, ax = plt.subplots()

# do nothing function that prints frame
def update(frame_num):
print frame_num
return []

Y, X = np.mgrid[:1:100j, :1:100j]
U = np.ones_like(X)
V = np.ones_like(X)
ax.streamplot(X, Y, U, V, density=1)

ani = animation.FuncAnimation(fig, update, save_count=500)

# save hangs at frame 173 (this probably varies by system, if it's
reproducible).
ani.save('animation.avi')
# show animates all frames w/o issue.
#plt.show()
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Strange bug when saving animations (with streamplot)

[Tony Yu]

On Sun, Jun 24, 2012 at 10:02 AM, Tony Yu  wrote:

> I'm having a tough time figuring this out: Saving an animation seems to
> hang when using `streamplot`. The exact same animation runs without issue
> when calling show.
>
> On my system, the example below hangs consistently at frame 173. However,
> the number of saved frames (before hanging) varies with density of stream
> lines (i.e. number of line segments in streamplot): More frames saved for
> lower density.
>
> Seems to be a memory or file-size issue, but
>
>* Memory use doesn't seem to grow. (this suggests that ffmpeg adds
> frames to disk as opposed to memory.)
>* Saving the animation up to the frame just before it hangs gives
> modest (~1MB) videos.
> Maybe this is a limitation of `ffmpeg`?
>
> Can someone confirm that the example hangs on their system? (Somehow, I
> often run into bugs that are not reproducible.)
>
> In case this is system dependent:
> * OSX 10.6
> * Python 2.6.1 (system install)
> * matplotlib master
> * ffmpeg 0.10
>
> Simple plots seem to work fine, but I should probably try to reproduce
> using something other than streamplot (maybe create the equivalent number
> of line and arrow collections).
>
> -Tony
>
> #~~~ Example
> import numpy as np
> import matplotlib.pyplot as plt
> import matplotlib.animation as animation
>
> fig, ax = plt.subplots()
>
> # do nothing function that prints frame
> def update(frame_num):
> print frame_num
> return []
>
> Y, X = np.mgrid[:1:100j, :1:100j]
> U = np.ones_like(X)
> V = np.ones_like(X)
> ax.streamplot(X, Y, U, V, density=1)
>
> ani = animation.FuncAnimation(fig, update, save_count=500)
>
> # save hangs at frame 173 (this probably varies by system, if it's
> reproducible).
> ani.save('animation.avi')
> # show animates all frames w/o issue.
> #plt.show()
>
>
>
I finally had some time to revisit this issue. It seems that subprocess
PIPEs have fairly limited buffers [1] (also see docs for
`subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a decent
amount of output to stderr. A simple solution is to redirect stderr to a
temporary file. This change fixes the issue on my system.

If this bug is reproducible, I can submit a PR. The temporary file here
could be created using tempfile so it gets cleaned up automatically, or
maybe a more permanent log file for debugging. Thoughts?

-Tony

[1]
http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/

[2]
http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Strange bug when saving animations (with streamplot)

[Tony Yu]

On Mon, Jul 2, 2012 at 11:42 PM, Tony Yu  wrote:

>
>
> On Sun, Jun 24, 2012 at 10:02 AM, Tony Yu  wrote:
>
>> I'm having a tough time figuring this out: Saving an animation seems to
>> hang when using `streamplot`. The exact same animation runs without issue
>> when calling show.
>>
>> On my system, the example below hangs consistently at frame 173. However,
>> the number of saved frames (before hanging) varies with density of stream
>> lines (i.e. number of line segments in streamplot): More frames saved for
>> lower density.
>>
>> Seems to be a memory or file-size issue, but
>>
>>* Memory use doesn't seem to grow. (this suggests that ffmpeg adds
>> frames to disk as opposed to memory.)
>>* Saving the animation up to the frame just before it hangs gives
>> modest (~1MB) videos.
>> Maybe this is a limitation of `ffmpeg`?
>>
>> Can someone confirm that the example hangs on their system? (Somehow, I
>> often run into bugs that are not reproducible.)
>>
>> In case this is system dependent:
>> * OSX 10.6
>> * Python 2.6.1 (system install)
>> * matplotlib master
>> * ffmpeg 0.10
>>
>> Simple plots seem to work fine, but I should probably try to reproduce
>> using something other than streamplot (maybe create the equivalent number
>> of line and arrow collections).
>>
>> -Tony
>>
>> #~~~ Example
>> import numpy as np
>> import matplotlib.pyplot as plt
>> import matplotlib.animation as animation
>>
>> fig, ax = plt.subplots()
>>
>> # do nothing function that prints frame
>> def update(frame_num):
>> print frame_num
>> return []
>>
>> Y, X = np.mgrid[:1:100j, :1:100j]
>> U = np.ones_like(X)
>> V = np.ones_like(X)
>> ax.streamplot(X, Y, U, V, density=1)
>>
>> ani = animation.FuncAnimation(fig, update, save_count=500)
>>
>> # save hangs at frame 173 (this probably varies by system, if it's
>> reproducible).
>> ani.save('animation.avi')
>> # show animates all frames w/o issue.
>> #plt.show()
>>
>>
>>
> I finally had some time to revisit this issue. It seems that subprocess
> PIPEs have fairly limited buffers [1] (also see docs for
> `subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a decent
> amount of output to stderr. A simple solution is to redirect stderr to a
> temporary file. This change fixes the issue on my system.
>
> If this bug is reproducible, I can submit a PR. The temporary file here
> could be created using tempfile so it gets cleaned up automatically, or
> maybe a more permanent log file for debugging. Thoughts?
>
> -Tony
>
> [1]
> http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/
>
> [2]
> http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
>
>
And just to clarify: My original email mentioned that saving would hang
only when `streamplot` was used to create the figure. It turns out that
ffmpeg prints more output (keyframes?) for more complex images, so when I
ran simpler plots, they didn't produce enough output to fill the subprocess
`PIPE` (although they would eventually).

Also, theres's a simpler fix than piping ffmpeg output to a file: Just
set `-loglevel quiet` in the ffmpeg command.

-Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Strange bug when saving animations (with streamplot)

[Tony Yu]

On Tue, Jul 3, 2012 at 10:22 AM, Ryan May  wrote:

> On Tue, Jul 3, 2012 at 9:14 AM, Tony Yu  wrote:
> > On Mon, Jul 2, 2012 at 11:42 PM, Tony Yu  wrote:
> >> On Sun, Jun 24, 2012 at 10:02 AM, Tony Yu  wrote:
> >>>
> >>> I'm having a tough time figuring this out: Saving an animation seems to
> >>> hang when using `streamplot`. The exact same animation runs without
> issue
> >>> when calling show.
> >>>
> >>> On my system, the example below hangs consistently at frame 173.
> However,
> >>> the number of saved frames (before hanging) varies with density of
> stream
> >>> lines (i.e. number of line segments in streamplot): More frames saved
> for
> >>> lower density.
> >>>
> >>> Seems to be a memory or file-size issue, but
> >>>
> >>>* Memory use doesn't seem to grow. (this suggests that ffmpeg adds
> >>> frames to disk as opposed to memory.)
> >>>* Saving the animation up to the frame just before it hangs gives
> >>> modest (~1MB) videos.
> >>> Maybe this is a limitation of `ffmpeg`?
> >>>
> >>> Can someone confirm that the example hangs on their system? (Somehow, I
> >>> often run into bugs that are not reproducible.)
> >>>
> >>> In case this is system dependent:
> >>> * OSX 10.6
> >>> * Python 2.6.1 (system install)
> >>> * matplotlib master
> >>> * ffmpeg 0.10
> >>>
> >>> Simple plots seem to work fine, but I should probably try to reproduce
> >>> using something other than streamplot (maybe create the equivalent
> number of
> >>> line and arrow collections).
> >>>
> >>> -Tony
> >>>
> >>> #~~~ Example
> >>> import numpy as np
> >>> import matplotlib.pyplot as plt
> >>> import matplotlib.animation as animation
> >>>
> >>> fig, ax = plt.subplots()
> >>>
> >>> # do nothing function that prints frame
> >>> def update(frame_num):
> >>> print frame_num
> >>> return []
> >>>
> >>> Y, X = np.mgrid[:1:100j, :1:100j]
> >>> U = np.ones_like(X)
> >>> V = np.ones_like(X)
> >>> ax.streamplot(X, Y, U, V, density=1)
> >>>
> >>> ani = animation.FuncAnimation(fig, update, save_count=500)
> >>>
> >>> # save hangs at frame 173 (this probably varies by system, if it's
> >>> reproducible).
> >>> ani.save('animation.avi')
> >>> # show animates all frames w/o issue.
> >>> #plt.show()
> >>>
> >>>
> >>
> >> I finally had some time to revisit this issue. It seems that subprocess
> >> PIPEs have fairly limited buffers [1] (also see docs for
> >> `subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a
> decent
> >> amount of output to stderr. A simple solution is to redirect stderr to a
> >> temporary file. This change fixes the issue on my system.
> >>
> >> If this bug is reproducible, I can submit a PR. The temporary file here
> >> could be created using tempfile so it gets cleaned up automatically, or
> >> maybe a more permanent log file for debugging. Thoughts?
> >>
> >> -Tony
> >>
> >> [1]
> >>
> http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/
> >>
> >> [2]
> >>
> http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
> >>
> >
> > And just to clarify: My original email mentioned that saving would hang
> only
> > when `streamplot` was used to create the figure. It turns out that ffmpeg
> > prints more output (keyframes?) for more complex images, so when I ran
> > simpler plots, they didn't produce enough output to fill the subprocess
> > `PIPE` (although they would eventually).
> >
> > Also, theres's a simpler fix than piping ffmpeg output to a file: Just
> set
> > `-loglevel quiet` in the ffmpeg command.
> >
> > -Tony
>
> It's not a bad idea to have it logged to a file in a temp directory.
> We could potentially just do this if debug is set to verbose, however,
> and just use -loglevel quiet otherwise. Can you manage PR for this or
> do I need to?
>
> Ryan
>
>
Hey Ryan,

If you have time, that'd be great. Otherwise, I should have some time at
the end of the week to submit a PR.

-Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Strange bug when saving animations (with streamplot)

[Tony Yu]

On Tue, Jul 3, 2012 at 11:18 AM, Ryan May  wrote:

> On Tue, Jul 3, 2012 at 10:03 AM, Tony Yu  wrote:
> >
> >
> > On Tue, Jul 3, 2012 at 10:22 AM, Ryan May  wrote:
> >>
> >> On Tue, Jul 3, 2012 at 9:14 AM, Tony Yu  wrote:
> >> > On Mon, Jul 2, 2012 at 11:42 PM, Tony Yu  wrote:
>
> >> >> I finally had some time to revisit this issue. It seems that
> subprocess
> >> >> PIPEs have fairly limited buffers [1] (also see docs for
> >> >> `subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a
> >> >> decent
> >> >> amount of output to stderr. A simple solution is to redirect stderr
> to
> >> >> a
> >> >> temporary file. This change fixes the issue on my system.
> >> >>
> >> >> If this bug is reproducible, I can submit a PR. The temporary file
> here
> >> >> could be created using tempfile so it gets cleaned up automatically,
> or
> >> >> maybe a more permanent log file for debugging. Thoughts?
> >> >>
> >> >> -Tony
> >> >>
> >> >> [1]
> >> >>
> >> >>
> http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/
> >> >>
> >> >> [2]
> >> >>
> >> >>
> http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
> >> >>
> >> >
> >> > And just to clarify: My original email mentioned that saving would
> hang
> >> > only
> >> > when `streamplot` was used to create the figure. It turns out that
> >> > ffmpeg
> >> > prints more output (keyframes?) for more complex images, so when I ran
> >> > simpler plots, they didn't produce enough output to fill the
> subprocess
> >> > `PIPE` (although they would eventually).
> >> >
> >> > Also, theres's a simpler fix than piping ffmpeg output to a file: Just
> >> > set
> >> > `-loglevel quiet` in the ffmpeg command.
> >> >
> >> > -Tony
> >>
> >> It's not a bad idea to have it logged to a file in a temp directory.
> >> We could potentially just do this if debug is set to verbose, however,
> >> and just use -loglevel quiet otherwise. Can you manage PR for this or
> >> do I need to?
> >>
> >> Ryan
> >>
> >
> > Hey Ryan,
> >
> > If you have time, that'd be great. Otherwise, I should have some time at
> the
> > end of the week to submit a PR.
> >
> > -Tony
> >
>
> I might be able to squeeze it in. If you don't see anything by the end
> of the week, hit me up.
>
> Ryan
>
>
Hey Ryan,

I didn't see a PR for this issue, so I just added a fix:

https://github.com/matplotlib/matplotlib/pull/989

As mentioned before, the PR suppresses logging in ffmpeg under normal
circumstances. When the verbosity level is set to debug, however, the
subprocess output (stdout + stderr) are piped to `sys.stdout`. This is
where verbose reports are posted, so I figured that was the best place (oh,
actually, I guess could have piped to `verbose.fileo`).

If you feel the debug output should go to a file instead, let me know.

Cheers,
-Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Tony Yu]

On Wed, Jul 11, 2012 at 11:27 AM, Benjamin Root  wrote:

>
>
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter  wrote:
>
>>
>>
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
>> damon.mcdoug...@gmail.com> wrote:
>>>
>>> Well, as Ben said, that error fill plot is neato! It doesn't look too
>>> complicated, either. I'd be more than happy to port it over later today
>>> when I get bored of typing up my thesis. It'll probably only take me
>>> about 30 minutes.
>>>
>>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
>>> evening (British Summer (hah!) Time).
>>>
>>
>>
>> While it is a nice graph, I am not sure that the use case is common
>> enough to justify a new plotting method.  One can get the same result with:
>>
>>
>>   In [68]: x = np.linspace(0, 2 * np.pi)
>>
>>   In [69]: y_sin = np.sin(x)
>>
>>   In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
>>
>>   In [71]: plot(x, y_sin)
>>   Out[71]: []
>>
>>   In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
>> facecolor='red', alpha=0.5)
>>   Out[72]: 
>>
>> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
>> adding a new plotting method, perhaps we would be better off with a helper
>> method to create the xs and ys for fill_between
>>
>>   xs, ys = mlab.pad_line(x, y, 0.2)
>>   fill_between(xs, ys)
>>
>> JDH
>>
>
> At the very least, it should be added to the gallery.  Also, one thing
> that might (or might not) get in the way of getting merged into mainline
> mpl is how well it interacts with legends.  What does it produce in the
> legend?
>
> Ben Root
>
>
As I said before, it is a really simple function: I wrote `errorfill` just
to get an interface that is somewhat similar to `errorbar`. I tend to think
that the Axes object is a bit bloated, so I'm inclined to agree that it
might be best leave it out of matplotlib-proper. +1 on the gallery, though.

Ben: Good point about the legend-interaction. I just added a fix on github;
here's the result:


http://tonysyu.github.com/mpltools/auto_examples/special/plot_errorfill.html

Cheers,
-Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Tony Yu]

On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root  wrote:

>
>
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter  wrote:
>
>>
>>
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
>> damon.mcdoug...@gmail.com> wrote:
>>>
>>> Well, as Ben said, that error fill plot is neato! It doesn't look too
>>> complicated, either. I'd be more than happy to port it over later today
>>> when I get bored of typing up my thesis. It'll probably only take me
>>> about 30 minutes.
>>>
>>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
>>> evening (British Summer (hah!) Time).
>>>
>>
>>
>> While it is a nice graph, I am not sure that the use case is common
>> enough to justify a new plotting method.  One can get the same result with:
>>
>>
>>   In [68]: x = np.linspace(0, 2 * np.pi)
>>
>>   In [69]: y_sin = np.sin(x)
>>
>>   In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
>>
>>   In [71]: plot(x, y_sin)
>>   Out[71]: []
>>
>>   In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
>> facecolor='red', alpha=0.5)
>>   Out[72]: 
>>
>> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
>> adding a new plotting method, perhaps we would be better off with a helper
>> method to create the xs and ys for fill_between
>>
>>   xs, ys = mlab.pad_line(x, y, 0.2)
>>   fill_between(xs, ys)
>>
>> JDH
>>
>
>
> I could definitely agree with a pad_line() function.  We might want to
> revisit the issue of how much visibility the mlab module should get in the
> documentation (it currently doesn't get much at all).  My whole take on
> mlab was that it was a left-over from the days of working around issues in
> NumPy and SciPy and that it was being slowly phased out.  As for other
> possible locations, cbook feels like it is more for the devs than for the
> users, and adding it to pyplot would render the whole purpose of creating
> this function as opposed to errorfill moot.
>
> As an additional point about such a pad_line function, it should probably
> be nice to mirror the errorbar() functionality to allow not only a constant
> error, but also a N, Nx1, or 2xN array of +/- error. (note that errorbar()
> for the 2xN array case does -row1 and +row2).
>

Damon: it sounds like you're volunteering to submit a PR to add this
function ;)

Here's the relevant bit (which should already handle the cases Ben mentions
above):


https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54

It needs a docstring and a home (pyplot.py?). I kind of think `offset_line`
is more explicit than `pad_line` (both of these are *much* better than my
original `extrema_from_error_input`).

Cheers,
-Tony


> Cheers!
> Ben Root
>
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Tony Yu]

On Thu, Jul 12, 2012 at 9:28 AM, Damon McDougall
wrote:

> On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:
> > On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root  wrote:
> >
> > >
> > >
> > > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter 
> wrote:
> > >
> > >>
> > >>
> > >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
> > >> damon.mcdoug...@gmail.com> wrote:
> > >>>
> > >>> Well, as Ben said, that error fill plot is neato! It doesn't look too
> > >>> complicated, either. I'd be more than happy to port it over later
> today
> > >>> when I get bored of typing up my thesis. It'll probably only take me
> > >>> about 30 minutes.
> > >>>
> > >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
> > >>> evening (British Summer (hah!) Time).
> > >>>
> > >>
> > >>
> > >> While it is a nice graph, I am not sure that the use case is common
> > >> enough to justify a new plotting method.  One can get the same result
> with:
> > >>
> > >>
> > >>   In [68]: x = np.linspace(0, 2 * np.pi)
> > >>
> > >>   In [69]: y_sin = np.sin(x)
> > >>
> > >>   In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
> > >>
> > >>   In [71]: plot(x, y_sin)
> > >>   Out[71]: []
> > >>
> > >>   In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> > >> facecolor='red', alpha=0.5)
> > >>   Out[72]: 
> > >>
> > >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather
> than
> > >> adding a new plotting method, perhaps we would be better off with a
> helper
> > >> method to create the xs and ys for fill_between
> > >>
> > >>   xs, ys = mlab.pad_line(x, y, 0.2)
> > >>   fill_between(xs, ys)
> > >>
> > >> JDH
> > >>
> > >
> > >
> > > I could definitely agree with a pad_line() function.  We might want to
> > > revisit the issue of how much visibility the mlab module should get in
> the
> > > documentation (it currently doesn't get much at all).  My whole take on
> > > mlab was that it was a left-over from the days of working around
> issues in
> > > NumPy and SciPy and that it was being slowly phased out.  As for other
> > > possible locations, cbook feels like it is more for the devs than for
> the
> > > users, and adding it to pyplot would render the whole purpose of
> creating
> > > this function as opposed to errorfill moot.
> > >
> > > As an additional point about such a pad_line function, it should
> probably
> > > be nice to mirror the errorbar() functionality to allow not only a
> constant
> > > error, but also a N, Nx1, or 2xN array of +/- error. (note that
> errorbar()
> > > for the 2xN array case does -row1 and +row2).
> > >
> >
> > Damon: it sounds like you're volunteering to submit a PR to add this
> > function ;)
> >
> > Here's the relevant bit (which should already handle the cases Ben
> mentions
> > above):
> >
> >
> >
> https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54
> >
> > It needs a docstring and a home (pyplot.py?). I kind of think
> `offset_line`
> > is more explicit than `pad_line` (both of these are *much* better than my
> > original `extrema_from_error_input`).
> >
> > Cheers,
> > -Tony
> >
> >
> > > Cheers!
> > > Ben Root
> > >
> > >
>
> Woohoo! Something other than my thesis to do! I have one question. It
> looks like your function `extrema_from_error_input` just adds +/- an
> error scalar (or array), but in the gallery it looks like the padding
> is thinner in the areas of the `sin` function where the magnitude of the
> gradient is larger. Is this the case, or am I missing something?
>
> --
> Damon McDougall
>


Yep, that's the way it should look because it's adding the error just in
the y-direction. To get a constant thickness, you'd have to add a constant
orthogonal to the line's slope.

Good luck procrastinating on your thesis ;)
-Tony
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

[Tony Yu]

Hi all,

I'm not sure if non-core-developers are allowed to post MEPs, but I just
did ;). MEP 12 outlines the reorganization of the example gallery and
subsequent clean up of the examples:

https://github.com/matplotlib/matplotlib/wiki/MEP12

In my opinion, there are two open questions in the MEP:

* Section names (may seem trivial to some, but I think it's really
important)
* Guidelines for cleaning up examples

I've added proposed section names and clean-up guidelines to the MEP, but
I'm sure these will evolve over time.

Best,
-Tony
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

[Tony Yu]

On Mon, Dec 10, 2012 at 5:32 PM, Chao YUE  wrote:

> The gallry will not include everything, could we also have somewhere to
> let "non-core" users freely share the code? like some features that are
> nice to have but not easily found in the galery? but hope this will not
> lead to overcrowded.
>
> Chao
>


Hi Chao,

This MEP only concerns the main gallery. I think user-contributed examples
were (are?) the intended focus of SciPy Central:

http://scipy-central.org/

(and before that, the SciPy Cookbook). I'm not sure about the status of
SciPy Central. There was talk of a redesign, but I haven't seen any
progress since then.

 Best,
-Tony


> On Mon, Dec 10, 2012 at 11:18 PM, Tony Yu  wrote:
>
>> Hi all,
>>
>> I'm not sure if non-core-developers are allowed to post MEPs, but I just
>> did ;). MEP 12 outlines the reorganization of the example gallery and
>> subsequent clean up of the examples:
>>
>> https://github.com/matplotlib/matplotlib/wiki/MEP12
>>
>> In my opinion, there are two open questions in the MEP:
>>
>> * Section names (may seem trivial to some, but I think it's really
>> important)
>> * Guidelines for cleaning up examples
>>
>> I've added proposed section names and clean-up guidelines to the MEP, but
>> I'm sure these will evolve over time.
>>
>> Best,
>> -Tony
>>
>>
>> --
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
> --
>
> ***
> Chao YUE
> Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
> UMR 1572 CEA-CNRS-UVSQ
> Batiment 712 - Pe 119
> 91191 GIF Sur YVETTE Cedex
> Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
>
> 
>
>
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

[Tony Yu]

On Mon, Dec 10, 2012 at 5:51 PM, Paul Hobson  wrote:

> On Mon, Dec 10, 2012 at 2:18 PM, Tony Yu  wrote:
>
>> Hi all,
>>
>> I'm not sure if non-core-developers are allowed to post MEPs, but I just
>> did ;). MEP 12 outlines the reorganization of the example gallery and
>> subsequent clean up of the examples:
>>
>> https://github.com/matplotlib/matplotlib/wiki/MEP12
>>
>> In my opinion, there are two open questions in the MEP:
>>
>> * Section names (may seem trivial to some, but I think it's really
>> important)
>> * Guidelines for cleaning up examples
>>
>> I've added proposed section names and clean-up guidelines to the MEP, but
>> I'm sure these will evolve over time.
>>
>> Best,
>> -Tony
>>
>>
> Here here! I've been waiting for a really nasty, cold, and rainy weekend
> here in Portland to make some PRs at least cleaning up the code contained
> within the examples. Just hasn't happened yet ;)
>
>  Tony, if you make your own branch for this, I'd be happy to contribute.
> -paul
>

Awesome! I'm hoping we can quickly converge on some clean-up guidelines and
section headings.

I was envisioning a single PR that adds new gallery sections. After that
examples would be updated over a long period of time in multiple PRs that
change a few examples at a time. Do you think that all the work should be
done on a parallel branch and merged in one big PR?

Best,
-Tony
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

[Tony Yu]

Hi Michael,

Thanks for reading the MEP! Responses below:

On Tue, Dec 11, 2012 at 1:10 PM, Michael Droettboom  wrote:

>  On 12/10/2012 05:18 PM, Tony Yu wrote:
>
> 

> MEP 12 outlines the reorganization of the example gallery and subsequent
> clean up of the examples:
>
>
>  https://github.com/matplotlib/matplotlib/wiki/MEP12
>
>  In my opinion, there are two open questions in the MEP:
>
>  * Section names (may seem trivial to some, but I think it's really
> important)
> * Guidelines for cleaning up examples
>
>  Some thoughts:
>
> You suggest keeping the old examples around in some dark corner.  Is there
> some advantage you envision for doing this?  I'd just as soon remove them.
> Note that the documentation on the website is now versioned, so the
> examples that shipped with 1.2.0 will remain live and unchanged
> indefinitely.  If a user wants the older gallery it should just be there
> under matplotlib.org/1.2.
>

I noted that old examples could either be kept in a dark corner, or
deleted. I'm actually strongly in favor of deleting, especially since the
website is versioned (nice---I didn't know this). I was afraid some people
would be resistant to deleting, but I'm happy to hear that you prefer it.
I'll make this preference clearer in the MEP.

As for the categories/structure, I think I prefer your "suggested
> alternative" -- to have narrowly defined categories rather than a big
> "plotting" directory.
>

I agree that "plotting" is too general. My only hesitation with the finer
classification of plots is that it's really hard to come up with categories
that work; my current suggestions in the MEP aren't really ideal.
Nevertheless, I'm sure we can all put our heads together to come up with
categories that make sense...



> For "cleanup guidelines", perhaps it is worth mentioning that some of the
> examples are really unit tests -- they just exercise some esoteric feature
> that's only of interest to developers.  These should be converted into unit
> tests from the framework and probably deleted altogether as gallery
> examples.
>

Agreed.

Maybe we should also add that examples should be renamed when appropriate:
> there are things like "image_demo.py" and "image_demo2.py".  The "2"
> doesn't really help to describe what's in there.
>

I definitely agree.

I'm not sure I agree with "one figure per example" as a goal -- it is
> sometimes nice to have a number of features demonstrated by a single
> example file, and cramming them all into multiple axes isn't always the
> best approach.  I think we can take that on a case-by-case basis.
>

I was hesitant to add this initially. I agree it's sometimes a good idea to
have multiple figures. I'd still like to have this as a suggestion---I'll
try to make that a little clearer in the MEP.


>  I agree with Phil that we might as well just iterate this on master.  I
> would envision one or two PRs to get the general infrastructure in place,
> and then lots of PRs from multiple authors as we work on whipping the
> examples into shape.
>

Sounds good.

Best,
-Tony
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

[Tony Yu]

On Tue, Dec 11, 2012 at 2:07 AM, Nicolas Rougier
wrote:

>
>
> Thanks a lot for this MEP and I would gladly contribute to the new gallery.
>

Thanks for adding the link to your gallery. I meant to include it (that's
where I got the idea for a "showcase" section) but it slipped through.



> From my own experience with the current gallery, I would recommend to have
> simple scripts that illustrate one feature only, it make things more clear
> IMHO.


I definitely agree. That's more clearly stated in the MEP, now.


> From my attempt at making some alternative gallery (
> http://www.loria.fr/~rougier/coding/gallery/), I would also recommend a
> standard size for figures unless a different size is strictly necessary.


I agree, but I'm not sure if this should be controlled by the example
script, or if the thumbnail generator should force a specific thumbnail
size. Regardless, most examples shouldn't be changing the default figure
size (since they should be focused on changes pertinent to a single
function).


> For section names, maybe we can use several different schemes with same
> figures ?


I think this would be better suited for a tagging system, which I think is
complementary to the gallery sections. I believe Ben started working on a
tagging system, but then life got in the way :)

Also, one important thing is to have a page with all the figures such one
> can browse visually all the examples.
>

 Agreed. I don't think the idea of the gallery should change---just the
organization of it.

Cheers,
-Tony
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

[Tony Yu]

On Tue, Dec 11, 2012 at 4:15 AM, Phil Elson  wrote:

> > I'm not sure if non-core-developers are allowed to post MEPs, but I just
> did
>
> Yes please... The more the merrier!
> Aren't you a core dev anyway Tony? :-) You've certainly contributed some
> really valuable features, and even if you don't have access to "the big
> green button" in my eyes you feedback and input are just as valuable.
>

Thanks :)



One thing I was considering doing in my implementation was allowing
> multiple tags for each example by adding some extra module level
> information (in a list called "__tags__" perhaps) rather than focussing on
> a directory structure to provide the tag as the current implementation of
> the gallery does (and as far as I can see, the MEP recommends this too).
>

I think tags would be great, but I don't want to be responsible for
implementing them :). As argued in the MEP, tags would be complementary:
Sections would help users who just want to scan the gallery. Maybe we can
"suggest" that clean ups include tags as a way of preparing for the future?


> In the past I have also worked on a gallery extension which uses the
> docstring of the example to provide a richer explanation of what is going
> on (example:
> http://scitools.org.uk/iris/docs/latest/examples/graphics/COP_1d_plot.html).
> An alternative approach which has worked well for me is the walked through
> examples found in scikits-learn (their website is down, but most of the
> examples are good in that regard) which could be done via an iPython
> notebook for the annotations.


Actually, scikit-image borrowed the scikit-learn gallery extension, and I
ended up tweaking it to provide more control over the output:


http://tonysyu.github.com/mpltools/auto_examples/sphinx/plot_plot2rst.html

I haven't looked too closely at the machinery used to generate the
matplotlib gallery, so I'm not sure how difficult it will be to integrate
something like this.

Best,
-Tony
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples

[Tony Yu]

On Wed, Dec 12, 2012 at 11:57 AM, Marcel Oliver <
m.oli...@jacobs-university.de> wrote:

> Paul Hobson writes:
>  > On Wed, Dec 12, 2012 at 5:59 AM, Michael Droettboom 
> wrote:
>  >
>  > http://matplotlib.org/examples/api/clippath_demo.html
>  >
>  > It's perfectly reasonable code, but seems strange that it's
>  > clipped off to the corner which I think makes it less useful as
>  > an example.
>  >
>  > If I understand correctly, you're proposing that that such an
>  > example would be deleted after a more practical example was
>  > available to replace it?
>  >
>  > While I'm 100% in favor of "cleaning out the closet", I used this exact
>  > example two days ago to clip a depressed groundwater surface to a
> landfill
>  > boundary :)
>
> There is one small issue with the example: If one is using imshow on
> random pixel data, there is not reason to use bilinear interpolation
> (which is what imshow defaults to).  "nearest" is the only reasonable
> choice.
>
> I know this sounds pedantic, but it irks me as a numerical analyst...
>
> --Marcel
>

Marcel: I agree examples like this should be changed. Actually, I think the
default interpolation should be changed to "nearest", but that's a whole
different can of worms ;)

For those who are interested, I just posted a pull request for this gallery
clean up . It's
definitely a work in progress. In particular, the section names are less
than ideal, but I think github's PR interface is a better place for that
discussion than the wiki or mailing list. The new section names can be
found below:

https://github.com/matplotlib/matplotlib/pull/1623/files#L0R86

Also, I moved a number of examples to the new sections in order to
demonstrate some of the clean up guidelines. BTW, one of the examples I
cleaned up is the clippath demo discussed earlier in this thread.

Best,
-Tony

Marcel: Sorry for the second email, I forgot to "reply all" the first time.
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] SciPy Sprints

[Tony Yu]

Hi all,

Since you're already discussing a SciPy BoF [1], it might be a good idea to
discuss a sprint (which was discussed briefly a couple of months ago [2]).

http://conference.scipy.org/scipy2013/sprints.php

Unfortunately, I might not be able to participate (since I may be committed
to another sprint), but it'd be a good idea to start advertising the sprint
soon in order to attract participants.

Cheers,
-Tony

[1]
http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg10017.html
[2]
http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg09951.html
--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] MEP13

[Tony Yu]

Hi matplotlib-devs,

I just added an alternate proposal to MEP13 (scroll to the bottom):

https://github.com/matplotlib/matplotlib/wiki/MEP13

which suggests that axes methods mirror the names of pyplot functions just
so it's easier to switch between the two. We could maintain the current
interface but with easier conversion.

Thoughts?

Cheers!
-Tony
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Colored lines and examples / documentation

[Tony Yu]

Hi David,

Sorry for the delay in replying. It was good meeting you last week.
Comments inline with a lot of parts cut out.


On Thu, Jul 4, 2013 at 10:13 PM, David P. Sanders wrote:
>
> I have been working, as a first step, on colored line support. This is
> not, of course, new -- it's all in LineCollection. However, as a user,
> LineCollection is intimidating and difficult to understand, and does not
> lead to easy experimentation (I speak from experience).
>

I agree that LineCollection isn't the most user-friendly thing to use.
Personally, I'd be in favor of something like your `linecolor` suggestion,
but I'd understand if the core-devs have concerns about feature creep.


> At Tony's suggestion, the first step was to rewrite the
> multicolored_line.py example.
> You can find my first attempt as an IPython notebook at
>
>
> https://github.com/dpsanders/matplotlib-examples/blob/master/linecolor.ipynb
>
> or
>
>
> http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/linecolor.ipynb
>

This looked pretty interesting when I first looked at it, but it seems to
be down now.


> Please let me have any comments before I attempt the next step of making a
> pull request.
> It seems to me that IPython notebooks are quite a natural format for such
> examples, especially with a view to having interactive examples in the
> future.
>

Using IPython notebooks as examples would be really beneficial in the long
run, as discussed during the BoF. I struggled with implementing support for
interleaved text, code, and plots for the scikit-image gallery (so that
examples could have real explanations). IPython notebooks are a more
natural format for this, but they're not quite there yet---specifically
nbconvert is still evolving (though this should be integrated into the next
release). That said, someone will need to write the code that takes the
output from nbconvert and integrates it with the current Sphinx code that
generates the gallery. Most of this will be straightforward but tedious.


> What is the situation with tagging the examples? If the examples are being
> refactored, it would seem to at least be a natural moment to start adding
> tags, even if nothing is actually done with them yet.
>

This is a great idea. I wish I had suggested this in my original MEP. I'm
not sure if there's been progress on adding an interface for tags, but we
should be adding tags during any clean ups to the examples so they're ready
in the future.

- Also during the BoF / sprint, style sheets were discussed several times.
> Tony seems to have already solved this problem in his mpltools package --
> I would suggest that this could be brought straight into Matplotlib?
>

This was my original plan. At the time I wrote the original, the rc parser
wasn't exposed to the user. That's been fixed now, but I haven't found the
time to integrate changes into Matplotlib proper. If anyone else would like
to have a go at it, they are more than welcome. Otherwise, I'll get to it
at some point ... hopefully.

Cheers!
-Tony
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Reorganizing axes plot methods

[Tony Yu]

This is an idea that's been kicking around in my head for awhile.
Basically, the Axes class is way too expansive. Nelle made a major step in
the right direction with a PR that split it up into plotting and
non-plotting methods:

https://github.com/matplotlib/matplotlib/pull/1931/files

What I'd like to see is something that further separates plotting methods
into many smaller sub-modules/-packages. Organizing the code this way would
make it easier (for me at least) to read, understand, and make changes to
the code.

I think that this could be done in an API-compatible way. In fact, a few of
the plotting methods are already implemented this way: In other words, the
bulk of the methods are implemented as functions outside of Axes, and the
Axes methods that are just thin wrappers around those functions (or
classes). See, for example, `streamplot`, `barbs`, and `quiver` methods

The examples mentioned above simply take the axes as the first parameter.
Here's the Axes-method definition of `quiver`, for example:

def quiver(self, *args, **kw):
...
q = mquiver.Quiver(self, *args, **kw)
...
return q

(might be a good idea to add a decorator to maintain the function signature
and docstring)

This should work for any of the plotting methods (I would imagine). Another
alternative is for all these plotting functions to have an `ax` (or some
other spelling) keyword argument that defaults to None and then have a line
in every function that does something like

ax = ax if ax is not None else plt.gca()

If I'm not mistaken, this would allow pyplot functions to be even thinner
wrappers around these newly extracted functions. (In some cases, it might
just be a simple import from the the new sub-package/-module into the
`pyplot` namespace).

I haven't sat down and thought through all the details of such a change,
but I wanted to throw it out there to see if anything sticks.

Cheers,
-Tony
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Reorganizing axes plot methods

[Tony Yu]

On Tue, Jul 9, 2013 at 1:24 AM, Eric Firing  wrote:



This would require pyplot to be imported by everything, wouldn't it?
> That would completely defeat the strategy of having an OO level that
> doesn't know about pyplot at all, and then having pyplot be the thin top
> layer.
>

Ahh, you're right! Like I said, I haven't really sat down and thought
through all the details :)


>
> Eric
>
> > I haven't sat down and thought through all the details of such a change,
> > but I wanted to throw it out there to see if anything sticks.
> >
> > Cheers,
> > -Tony
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Reorganizing axes plot methods

[Tony Yu]

On Tue, Jul 9, 2013 at 1:43 AM, Nelle Varoquaux
wrote:

> On 9 July 2013 08:24, Eric Firing  wrote:
> > On 2013/07/08 7:19 PM, Tony Yu wrote:
> >> This is an idea that's been kicking around in my head for awhile.
> >> Basically, the Axes class is way too expansive. Nelle made a major step
> >> in the right direction with a PR that split it up into plotting and
> >> non-plotting methods:
> >>
> >> https://github.com/matplotlib/matplotlib/pull/1931/files
> >>
> >> What I'd like to see is something that further separates plotting
> >> methods into many smaller sub-modules/-packages. Organizing the code
> >> this way would make it easier (for me at least) to read, understand, and
> >> make changes to the code.
> >>
> >> I think that this could be done in an API-compatible way. In fact, a few
> >> of the plotting methods are already implemented this way: In other
> >> words, the bulk of the methods are implemented as functions outside of
> >> Axes, and the Axes methods that are just thin wrappers around those
> >> functions (or classes). See, for example, `streamplot`, `barbs`, and
> >> `quiver` methods
> >
> > I agree.  I would like to see logical groups of plot types broken out
> > into modules.
>
> That's the second step in the refactoring of the axes module.
> We now have to discuss how to organize plots in subtypes that make
> sense. At Scipy, we discussed a bit about it, and we think it should
> follow the same organization as the gallery, but I don't know whether
> the gallery reorganization is logical enough right now to start the
> refactoring straight away.
>

I knew I should have dropped by the matplotlib sprints :) The gallery
categories really aren't that logical, but as long as the functions aren't
meant to be directly imported from their sub-modules (instead you would use
the Axes method or pyplot function), then nothing needs to be permanent,
right?

>
> Should we discuss about this here, or in a ticket?
>

It's probably easier to discuss on a new ticket.

Cheers,
-Tony
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Reorganizing axes plot methods

[Tony Yu]

Nelle, this is great! Thanks for getting the ball rolling!

Cheers,
-Tony


On Thu, Jul 11, 2013 at 6:31 AM, Nelle Varoquaux
wrote:

> FYI, I have started the refactoring we discussed at scipy. I think
> what tony is suggesting is the same thing.
>
> I've created a "work in progress" pull request:
> https://github.com/matplotlib/matplotlib/pull/2213
>
> In the refactoring we discussed at Scipy, we did not mention the
> pyplots wrapper at all. It does not impact pyplot or the axes module
> at all as it doesn't change the API at all. If we want to do something
> more in depth that impacts the API, I think it would be worth writing
> a MEP.
>
> Thanks,
> N
>
>
> On 11 July 2013 13:12, Anton Akhmerov  wrote:
> > Eric Firing  writes:
> >>
> >> Anton,
> >>
> >> Yes, I have done things like that in my own code, and basemap has a
> >> similar ability to call gca() when an Axes is not supplied.  One can
> >> even perform the pyplot import on an as-needed basis instead of raising
> >> an error. Nevetheless, it still represents what I view as a big change
> >> in mpl design, scrambling the state machine pyplot layer into the OO
> >> layer.  Sometimes this sort of thing is good, sometimes it isn't.  In
> >> the present case, I am far from convinced that it would be good.  I
> >> don't see any real benefit at all over the present design.  I think that
> >> for the sanity of the developers, if nothing else, it is important to
> >> maintain some clear layering and hierarchy.
> >>
> >> Eric
> >>
> >
> > I completely agree with that, and I just wanted to point out the
> possibility.
> > With the proposed separation of the plots to a separate module, I think,
> the
> > reasonable thing for pyplot would be to wrap the corresponding plot
> functions
> > by feeding gca into the axis argument.
> >
> > PS for what I think, pyplot right now is way too thick of a layer,
> > obstructing an API use of backends.
> >
> > Anton
> >
> >
> >
> --
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > ___
> > Matplotlib-devel mailing list
> > Matplotlib-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> --
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Tony Yu]

On Sat, Jul 20, 2013 at 4:47 PM, Chris Beaumont  wrote:

> Hi,
>
> I thought I'd chime in on this discussion -- Adrian Price-Whelan and I put
> together plotornot during the SciPy sprints.
>
> I wouldn't advocate for linking to plotornot from matplotlib -- the idea
> is semi tongue-in-cheek, and meant to gauge to what extent there is
> consensus about plot styles. It's not set up to teach about rcParams, nor
> does it systematically explore all possible styles. The votes (>10K, last I
> checked) are saved, and eventually Adrian or I will look over the feedback
> and report back to you all. I haven't had time for that yet. I hope the
> name didn't *actually* offend anyone.
>
> At the risk of sounding unappreciative of MPL (which I love, and rely upon
> daily), I must admit I was disheartened after hearing the MPL devs at SciPy
> discuss styles and defaults. I understand that you don't want to change the
> default styles without a clearly better alternative. I also understand
> that, to some extent, style preferences are subjective. However, there
> seemed to be quite a bit of resistance to the idea that MPL defaults should
> change *at all.*
>
> Even if you ignore the subjective component of this (which I think is a
> mistake, since in my experience there is broad consensus that projects like
> ggplot2, d3, tableau, and spotfire do a "better" job than MPL at styling),
> there are some well-established visual principles that matplotlib violates.
> Some of my biggest pet peeves are:
>
> 1) The default 'axes.color_cycle' values should be equally visible, with
> similar luminance values. The current defaults (bgrcmyk) do not have this
> property -- c and y are harder to see, and thus carry less visual emphasis.
> A color table like the "Dark2" color brewer table (
> http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
> colorbrewer2.org) is more uniform, and carefully designed for visibility
> and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a
> smarter default?
>
> 2) The default 'jet' colormap for images has a lot of poor properties
> (which is even mentioned on the MPL docs at
> http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
> ordering changes in hue (which is bigger -- purple or yellow?), and better
> at ordering changes in intensity or saturation. A colleague of mine
> designed a visualization tool for doctors, and found that the rainbow color
> table had a dramatic negative effect on the effectiveness of the tool (you
> can watch her TED talk about this at
> https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
> especially frustrating, since it *cannot* be modified via rcParams
>

Jet is terrible for so many reasons, but it can be modified (unless I
misunderstand):

image.cmap : gray

I'm all for changing the current defaults.

Cheers,
-Tony
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Tony Yu]

On Sat, Jul 20, 2013 at 9:10 PM, David P. Sanders <
dpsand...@ciencias.unam.mx> wrote:

>
>
>
> On Sat, Jul 20, 2013 at 8:48 PM, Chris Beaumont wrote:
>
>>
>>



>  However, default tweaking need not be painful. As has been mentioned, a
>> first step would be an easier way to change a whole set of rcParams:
>> something like mpl.set_style('style-name'). As long as one style is
>> 'classic', users can keep the current style for as long as they want. It's
>> a one line fix, and could even be rcParams-settable.
>>
>
> This is already implemented! The problem is, it's hidden away in the
> mpltools toolkit:
>
> http://tonysyu.github.io/mpltools/
>
> which nobody seems to know about or use, which is a great shame, since
> it's first class -- great job, Tony!
>
> The first example there is:
>
> >>> from mpltools import style>>> style.use('ggplot')
>
> and then the plot is suddenly jaw-droppingly beautiful!
>
> This is achieved with style files which just have lists of matplotlib
> params like this:
>
> patch.linewidth = 0.5
> patch.facecolor = '#348ABD'  # blue
> patch.edgecolor = '#EE'
> patch.antialiased = True
>
> These are parsed using the ConfigObj package (this package parses config
> files of this type).
>
> Somebody (Chris?) tweeted something about the Vega package earlier:
> http://trifacta.github.io/vega/
>
> They seem to have these kind of things solved already (disclaimer: I only
> browsed briefly their site) using JSON, but actually Tony's approach seems
> like a winner.
>
> mpltools may be installed with
>
> > pip install ConfigObj
> > pip install mpltools
>
> [For some reason the dependency on ConfigObj is not registered in
> mpltools. Tony, are you the packager?]
>

I'm not really sure why the configobj dependency doesn't resolve properly.
As they say: pull requests are welcome. ;)

This is all *crying out* to be dropped straight into matplotlib proper!
>

Here's a PR to add the style sheets from mpltools:
https://github.com/matplotlib/matplotlib/pull/2236

(using matplotlib's parser instead of ConfigObj)

Cheers!
-Tony



> David
>
>
--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Meeting...?

[Tony Yu]

Is there room for a lurker in the hangout? If so, is there a link for
joining the hangout? (I tried using the hangout calendar link from awhile
back, but I couldn't get my google calendar to recognize it.)

Cheers,
-Tony


On Wed, Jan 15, 2014 at 9:57 AM, Michael Droettboom  wrote:

>  On 01/14/2014 03:49 PM, Chris Beaumont wrote:
>
> I have another long-simmering feature request along these lines: if
> Matplotlib were to evolve a formal DOM-like figure structure like mentioned
> above, it would be cool if this structure retained more semantic
> information about the visualization itself. By this, I mean that many
> high-level commands like hist, scatter, etc. spawn a bunch of low level
> artists like rectangles and circles. After these methods exit, it's
> hard/impossible to introspect a Figure and diagnose that it, for example,
> is a histogram and not a bar chart.
>
>
> I agree, this would be very nice to have, but is (obviously) a much bigger
> step from what we currently have in matplotlib.  Along those lines, if the
> "frontend" (i.e. the pylab interface and even the OO interface) basically
> generate a tree, then you could serialize that tree (here XML would be a
> great fit, don't knock it), and even non-Python based tools could transform
> it into something else.
>
>
>
>  Retaining a better high-level description of a plot (which probably
> amounts to creating more compound artist types) would make it easier to
> build tools like mpld3 and other cool things that involve runtime editing
> or optimization of tree-like data structures.
>
>
> Agreed.
>
> No argument against this at all from me -- but knowing how much work this
> would be, the obstacle there is just finding the time to do it.  It would
> be a significant rewrite...
>
> Mike
>
>
>
>  chris
>
>
> On Tue, Jan 14, 2014 at 3:34 PM, Jacob Vanderplas <
> jake...@cs.washington.edu> wrote:
>
>>   On Tue, Jan 14, 2014 at 12:04 PM, Michael Droettboom 
>> wrote:
>>
>>>
>>> I hope all of the above makes sense...
>>>
>>
>>  Definitely makes sense: what I've built-up in mpld3 is essentially
>> something that mimics this sort of visitor pattern, though it misses some
>> things because of the draw-time difficulties you mention.
>> I think a two-stage draw() would be a _very_ helpful restructure.
>>  Currently, I'm forced to achieve this result by writing a png to a
>> throwaway byte-stream...
>>Jake
>>
>>
>>>
>>> Mike
>>>
>>>
>>> On 01/14/2014 01:30 PM, Jacob Vanderplas wrote:
>>>
>>> Thanks - we'll make it happen at some point.
>>>
>>>  Perhaps I can give the seed for a discussion: the stuff I've been
>>> doing with mpld3 is a lot of fun, but it's fundamentally limited by the
>>> fact that I have to dig around the internals of the figure object to find
>>> the relevant information to construct a plot representation.  I may be able
>>> to do the same thing by creating a backend, but the problem is that the
>>> draw() methods of most objects call the renderer with no reference to
>>> whether the points lie in the data space or figure space: that is, paths
>>> and points are usually specified in figure/pixel coordinates or some
>>> transformed version thereof, which makes it near impossible to construct
>>> interactive representations absent Python kernel callbacks.
>>>
>>>  What I'd love to see is some enhancement of the backend framework
>>> where there are some extra flags and information passed to the renderer:
>>> i.e. for each draw command, we need to know whether the drawn object should
>>> be linked to static figure coordinates or to dynamic axes/data coordinates.
>>>
>>> I've been in touch with Cyrille Rossant from the vispy team, Chris
>>> Beaumont from the Glue team, and Matt Sundwuist from the plotly team, all
>>> of whom asked if there might be a way to use what I've done with mpld3 to
>>> enable matplotlib to export into their own front-end format.  I didn't
>>> start mpld3 with that sort of extensibility in mind, but I'm starting to
>>> invest some time thinking about how to design that.
>>>
>>>  With the current matplotlib package, I think there are two ways to
>>> accomplish it: one is to create a general backend-like interface based on
>>> the figure introspection that mpld3 currently uses.  The artist elements in
>>> each figure contain enough information to be able to infer whether the
>>> elements should move & zoom with the axes or not.  The problem is, a lot of
>>> elements (like legends, axes aspects, etc.) are not fully established until
>>> the draw() command is called, so there are a few ugly hacks required to
>>> make it happen.
>>>
>>>  The other option is to use an even uglier hack, and wrap the current
>>> backend framework with an object that somehow links back into the figure
>>> and infers from the draw_*() commands whether the path/point/marker/etc.
>>> should be drawn in static figure coordinates or in dynamic axes
>>> coordinates. I've started a simple prototype backend translator which has a
>>> renderer class th

Re: [matplotlib-devel] Meeting...?

[Tony Yu]

On Thu, Jan 16, 2014 at 7:30 AM, Michael Droettboom  wrote:

>  Yes, there's room.
>
> This is the link that Google gives me for the calendar:
>
>
> https://www.google.com/calendar/feeds/79hk8jhvlks8jn8ds4ri1e6q4g%40group.calendar.google.com/public/basic
>
> Let me know whether that works...
>
> Mike
>
>
My bad: I expected clicking the link to add the calendar to my GCal
account. I didn't realize I had to copy the address to the "Add by URL"
dialog under "Other Calendars". So primitive :P

Thanks for letting me lurk during the meeting,
-Tony
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Matplotlib style gallery

[Tony Yu]

I've been playing around with learning Javascript lately. As part of the
process, I created a Flask app to build a gallery for matplotlib style
sheets:

https://github.com/tonysyu/matplotlib-style-gallery

If you run that locally, you can actually input styles, either with a URL
to a *.mplstyle file or with matplotlibrc commands. Here's a static version
without the custom inputs:

http://tonysyu.github.io/raw_content/matplotlib-style-gallery/gallery.html

Ideally, I'd get this into a form that could be submitted as a PR for the
matplotlib website, but I'll need a bit more spare time to learn some more
web development (sessions, client storage, etc).

Cheers!
-Tony
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib style gallery

[Tony Yu]

Thanks Max!

I was planning to add a more interactive interface, really similar to what
you're suggesting. I haven't gotten around to it, but hopefully, I'll have
some time to play around with that.

On Thu, Jan 8, 2015 at 4:56 PM, Maximilian Albert <
maximilian.alb...@gmail.com> wrote:

> Hi Tony,
>
> This is awesome. Great work!
>
> I was wondering, is there an easy way to cycle through all available
> styles for a given plot? For instance, clicking on the top left plot
> displays a maximized image of the "bmh" style. It would be great if one
> could press arrow-down (say)  to cycle through the other styles
> "dark_background", "fivethirtyeight", etc. for a quick comparison.
>
> Cheers,
> Max
>
>
> 2015-01-06 4:42 GMT+00:00 Tony Yu :
>
>> I've been playing around with learning Javascript lately. As part of the
>> process, I created a Flask app to build a gallery for matplotlib style
>> sheets:
>>
>> https://github.com/tonysyu/matplotlib-style-gallery
>>
>> If you run that locally, you can actually input styles, either with a URL
>> to a *.mplstyle file or with matplotlibrc commands. Here's a static version
>> without the custom inputs:
>>
>> http://tonysyu.github.io/raw_content/matplotlib-style-gallery/gallery.html
>>
>> Ideally, I'd get this into a form that could be submitted as a PR for the
>> matplotlib website, but I'll need a bit more spare time to learn some more
>> web development (sessions, client storage, etc).
>>
>> Cheers!
>> -Tony
>>
>>
>> --
>> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RFC: candidates for a new default colormap

[Tony Yu]

It doesn't sound like this is going to be decided by email votes, but just
so the arguments for C don't dominate, my vote would be:

B > A >> C

C has the least perceptual range (that's quantifiable, right?). Also, I
find A and B much more aesthetically pleasing (that's obviously debatable).
In particular, the yellows and blues in C have a slight visual vibration.
Actually, if you google "visual vibration", one of the first hits is a yellow
and violet image . B
would have this to a certain extent, but it's much more problematic if
those colors are at the limits of the colormap range. It looks like A
wouldn't have this problem at all since it's white point has a very muted
yellow tone, so maybe I'll switch my vote to A. (Personally, it's a toss up
between the two; anything but C, if I haven't made myself clear ;)

Thanks to Nathaniel and Stéfan for putting this together! Hopefully "jet"
can be banished soon :)

-Tony

On Wed, Jun 3, 2015 at 5:20 AM, OceanWolf 
wrote:

> Personally, just looking at the images I think B looks more
> professional, the others look faded.  With A and B I see more of
> "contrast" in the core of the radial image (though that might arise from
> a combination of my monitor/eyes, though I usually do quite well in
> colour perception tests).
>
> I think we really need to see a variety of real examples before we make
> a decision though, both in application a.k.a different type of datasets,
> including ones with NaNs; and different graph types, the 3d example will
> make for a good test as we get the same information twice, from height
> and colour, which gives us a reference for comparison.
>
> With the NaNs Andreas, why did you pick B over C?  My eyes see B going
> to white as well, only C as far as I can tell does not go to white.
>
> Looking forward to having a play later :).  I wonder what Parula-based
> colormap would look like if we were to make it linear... one other
> thing, mpl currently doesn't select good bounds with pure
> horizontal/vertical lines, making it very difficult (at least for me) to
> see the perceptual deltas, zoomed in to option_c the line gets
> completely hidden by the axes...
>
> On 03/06/15 09:04, Andreas Hilboll wrote:
> > On 03.06.2015 08:54, Juan Nunez-Iglesias wrote:
> >> You can always use green for NaN with any of these maps...
> > In grayscale that then wouldn't be distinguishable at all ...
> >
> >> On Wed, Jun 3, 2015 at 4:30 PM, Andreas Hilboll  >> > wrote:
> >>
> >>  > I particularly like that A ends on the white end of the spectrum
> >>
> >>  That's exactly why I don't like A that much.
> >>
> >>  In many plots, I need a color for NaN results. This color should
> not
> >>  fall within the normal range of the colormap. In case of B and C,
> it
> >>  would be possible to use white as NaN color. When using white for
> NaN
> >>  in A, it would just look like large values. So I guess I'm voting
> >>
> >>  B > C > A
> >>
> >>  -- Andreas.
> >>
> >>
> --
> >>
> >>  ___
> >>  Matplotlib-devel mailing list
> >>  Matplotlib-devel@lists.sourceforge.net
> >>  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >>
> >
>
>
>
> --
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib style gallery

[Tony Yu]

Well... this is a *really* late reply, but I finally got around to adding
easier navigation for the style gallery
<https://tonysyu.github.io/raw_content/matplotlib-style-gallery/gallery.html>.
I
also added an update for styles added in Matplotlib 1.5 and wrote a quick
post <https://tonysyu.github.io/matplotlib-style-gallery.html#.VvoAzxIrKV4>.

Cheers!
-Tony

On Thu, Jan 8, 2015 at 8:10 PM, Tony Yu  wrote:

> Thanks Max!
>
> I was planning to add a more interactive interface, really similar to what
> you're suggesting. I haven't gotten around to it, but hopefully, I'll have
> some time to play around with that.
>
> On Thu, Jan 8, 2015 at 4:56 PM, Maximilian Albert <
> maximilian.alb...@gmail.com> wrote:
>
>> Hi Tony,
>>
>> This is awesome. Great work!
>>
>> I was wondering, is there an easy way to cycle through all available
>> styles for a given plot? For instance, clicking on the top left plot
>> displays a maximized image of the "bmh" style. It would be great if one
>> could press arrow-down (say)  to cycle through the other styles
>> "dark_background", "fivethirtyeight", etc. for a quick comparison.
>>
>> Cheers,
>> Max
>>
>>
>> 2015-01-06 4:42 GMT+00:00 Tony Yu :
>>
>>> I've been playing around with learning Javascript lately. As part of the
>>> process, I created a Flask app to build a gallery for matplotlib style
>>> sheets:
>>>
>>> https://github.com/tonysyu/matplotlib-style-gallery
>>>
>>> If you run that locally, you can actually input styles, either with a
>>> URL to a *.mplstyle file or with matplotlibrc commands. Here's a static
>>> version without the custom inputs:
>>>
>>>
>>> http://tonysyu.github.io/raw_content/matplotlib-style-gallery/gallery.html
>>>
>>> Ideally, I'd get this into a form that could be submitted as a PR for
>>> the matplotlib website, but I'll need a bit more spare time to learn some
>>> more web development (sessions, client storage, etc).
>>>
>>> Cheers!
>>> -Tony
>>>
>>>
>>> --
>>> Dive into the World of Parallel Programming! The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot Media, is
>>> your
>>> hub for all things parallel software development, from weekly thought
>>> leadership blogs to news, videos, case studies, tutorials and more. Take
>>> a
>>> look and join the conversation now. http://goparallel.sourceforge.net
>>> ___
>>> Matplotlib-devel mailing list
>>> Matplotlib-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel