matplotlib

On Fri, May 29, 2009 at 10:50 AM, Xavier Gnata <xavier.gnata@...> wrote:

>> I had the same problem and fixed it by changing just two lines of code in the axes.py (line 1812 and 1814). Just change the formatter in 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the same for y).

You don't need to modify the internals of axes.py -- just set the
formatter on the axes instance itself.

  http://matplotlib.sourceforge.net/search.html?q=codex+set_major_formatter

> Indeed, but it should really be fixed in the svn.

We could perhaps be a little smarter about this, but consider that one
can easily plot lines over images

In [30]: imshow(np.random.rand(512,512))
Out[30]: <matplotlib.image.AxesImage object at 0x151c4f4c>

In [31]: plot(np.arange(512), np.arange(512))

Since the plot can be a mix of images, polygons, lines, etc, it is not
obvious that the formatter should be int.  We could trap the case
where you have only an image, no other data, and haven't set the
extent, but it would be complicated because you may add data to the
plot later and we would have to track that we had attempted to be
clever but we should now undo our cleverness.  Our general philosophy
is to make is easy for you to customize when the default behavior
doesn't suit you, so try

  import matplotlib.ticker as ticker
  ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d'))
  .. and ditto for yaxis ..

in addition to the ticks, you can customize how the coords appear in
the toolbar by setting

  ax.fmt_xdata = ticker.FormatStrFormatter('%d')
  ... and ditto for fmt_ydata

There are a variety of formatters available

  http://matplotlib.sourceforge.net/api/ticker_api.html

JDH

John Hunter wrote:
> On Fri, May 29, 2009 at 10:50 AM, Xavier Gnata <xavier.gnata@...> wrote:
>
>   
>>> I had the same problem and fixed it by changing just two lines of code in the axes.py (line 1812 and 1814). Just change the formatter in 'self.xaxis.major.formatter.set_scientific(sb)' to whatever you want (the same for y).
>>>       
>
> You don't need to modify the internals of axes.py -- just set the
> formatter on the axes instance itself.
>
>   http://matplotlib.sourceforge.net/search.html?q=codex+set_major_formatter
>
>   
>> Indeed, but it should really be fixed in the svn.
>>     
>
> We could perhaps be a little smarter about this, but consider that one
> can easily plot lines over images
>
> In [30]: imshow(np.random.rand(512,512))
> Out[30]: <matplotlib.image.AxesImage object at 0x151c4f4c>
>
> In [31]: plot(np.arange(512), np.arange(512))
>
> Since the plot can be a mix of images, polygons, lines, etc, it is not
> obvious that the formatter should be int.  We could trap the case
> where you have only an image, no other data, and haven't set the
> extent, but it would be complicated because you may add data to the
> plot later and we would have to track that we had attempted to be
> clever but we should now undo our cleverness.  Our general philosophy
> is to make is easy for you to customize when the default behavior
> doesn't suit you, so try
>
>   import matplotlib.ticker as ticker
>   ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d'))
>   .. and ditto for yaxis ..
>
> in addition to the ticks, you can customize how the coords appear in
> the toolbar by setting
>
>   ax.fmt_xdata = ticker.FormatStrFormatter('%d')
>   ... and ditto for fmt_ydata
>
> There are a variety of formatters available
>
>   http://matplotlib.sourceforge.net/api/ticker_api.html
>
> JDH
>   
Hi John,

Ok, well; the way I use pylab may be a corner case ;)

However, everyone would be happy if the default format would be consistent :

As it is, *by default*, when <1000 it displays an int and after 1000 it 
displays 1.42e3.
Why? What do you think this scientific format is a good for?

I understand some users would like to see floats by default.
Some other users would like to see integers by default.

I'm fine with integers or floats by default (I don't cadre) but I don't 
get the logic of the scientific format.
I only would like to see all the digits of the integer parts.
I would be fine if I would get 1.422e3 instead of 1.42e3 (we could for 
instance assume that images larger than (100 000, 100 000) are really a 
corner case ;)).

Why should be the *default* logic so strange?
Ok, it is easy to change but the default should at least make sense.
As it is, I don't think it does...but there could be a good rational I'm 
missing.

pylab is so easy and fun to use because the default settings are always 
the best one.
IMHO, there is one exception :(

Xavier

Xavier Gnata wrote:

> 
> However, everyone would be happy if the default format would be consistent :
> 
> As it is, *by default*, when <1000 it displays an int and after 1000 it 
> displays 1.42e3.
> Why? What do you think this scientific format is a good for?
> 
> I understand some users would like to see floats by default.
> Some other users would like to see integers by default.

It is not just a matter of integer versus float; the formatting 
algorithm must accomodate both.

> 
> I'm fine with integers or floats by default (I don't cadre) but I don't 
> get the logic of the scientific format.
> I only would like to see all the digits of the integer parts.
> I would be fine if I would get 1.422e3 instead of 1.42e3 (we could for 
> instance assume that images larger than (100 000, 100 000) are really a 
> corner case ;)).
> 
> Why should be the *default* logic so strange?
> Ok, it is easy to change but the default should at least make sense.
> As it is, I don't think it does...but there could be a good rational I'm 
> missing.


Right now, the default is very simple:

     def format_data_short(self,value):
         'return a short formatted string representation of a number'
         return '%1.3g'%value

It looks like changing it to something like "%-12g" would facilitate 
considerable improvement in reducing the jumping around of the numbers, 
as well as in providing much more precision.  I think that 12 is the max 
number of characters in g conversion.  Or maybe it is 13; I might not 
have tested negative numbers.

The problem is that then it crowds out the other part of the message, 
the pan/zoom status notification etc.

Breaking the message into two lines almost works (so far only checking 
with gtkagg), but the plot gets resized depending on whether there is a 
status or not.

I think that with some more fiddling around with that part of the 
toolbar--probably including breaking the message up into separate 
messages for status and readout, and maybe making the readout use two 
lines and always be present--we could make the readout and status 
display much nicer.  I have never liked the way it jumps around.

Eric

> 
> pylab is so easy and fun to use because the default settings are always 
> the best one.
> IMHO, there is one exception :(
> 
> Xavier
> 
> 
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

>
>>
>> However, everyone would be happy if the default format would be 
>> consistent :
>>
>> As it is, *by default*, when <1000 it displays an int and after 1000 
>> it displays 1.42e3.
>> Why? What do you think this scientific format is a good for?
>>
>> I understand some users would like to see floats by default.
>> Some other users would like to see integers by default.
>
> It is not just a matter of integer versus float; the formatting 
> algorithm must accomodate both.
>
I agree.

>>
>> I'm fine with integers or floats by default (I don't cadre) but I 
>> don't get the logic of the scientific format.
>> I only would like to see all the digits of the integer parts.
>> I would be fine if I would get 1.422e3 instead of 1.42e3 (we could 
>> for instance assume that images larger than (100 000, 100 000) are 
>> really a corner case ;)).
>>
>> Why should be the *default* logic so strange?
>> Ok, it is easy to change but the default should at least make sense.
>> As it is, I don't think it does...but there could be a good rational 
>> I'm missing.
>
>
> Right now, the default is very simple:
>
>     def format_data_short(self,value):
>         'return a short formatted string representation of a number'
>         return '%1.3g'%value
>
> It looks like changing it to something like "%-12g" would facilitate 
> considerable improvement in reducing the jumping around of the 
> numbers, as well as in providing much more precision.  I think that 12 
> is the max number of characters in g conversion.  Or maybe it is 13; I 
> might not have tested negative numbers.
>
> The problem is that then it crowds out the other part of the message, 
> the pan/zoom status notification etc.
>
> Breaking the message into two lines almost works (so far only checking 
> with gtkagg), but the plot gets resized depending on whether there is 
> a status or not.
>
> I think that with some more fiddling around with that part of the 
> toolbar--probably including breaking the message up into separate 
> messages for status and readout, and maybe making the readout use two 
> lines and always be present--we could make the readout and status 
> display much nicer.  I have never liked the way it jumps around.
>
I also agree.
However, I would like to be sure I understand one point correctly:
As long as x<1000, the default format *is* an integer (at least when 
imshow(M) is used).
Fine for me. Why do we need to move to another *default* format for 
numbers larger than 1000?

Anyhow, I think that we should at least always display all the digits of 
the integer part of the coordinates.

BTW, ax.xaxis.set_major_formatter(ticker.FormatStrFormatter('%d')) is 
fine but it prevents you to do a simple imshow(M) to look at your data. 
You have to create ax. Easy...yes...but not as simple/nice as the 
one-liner imhow(M)

Xavier


> Eric
>
>>
>> pylab is so easy and fun to use because the default settings are 
>> always the best one.
>> IMHO, there is one exception :(
>>
>> Xavier
>>
>>
>>
>> ------------------------------------------------------------------------------ 
>>
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
>> is a gathering of tech-side developers & brand creativity 
>> professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, 
>> & iPhoneDevCamp as they present alongside digital heavyweights like 
>> Barbarian Group, R/GA, & Big Spaceship. 
>> http://p.sf.net/sfu/creativitycat-com 
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users@...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Xavier Gnata wrote:
> 
>>
>>>

>> Right now, the default is very simple:
>>
>>     def format_data_short(self,value):
>>         'return a short formatted string representation of a number'
>>         return '%1.3g'%value
>>
>> It looks like changing it to something like "%-12g" would facilitate 
>> considerable improvement in reducing the jumping around of the 
>> numbers, as well as in providing much more precision.  I think that 12 
>> is the max number of characters in g conversion.  Or maybe it is 13; I 
>> might not have tested negative numbers.
>>
>> The problem is that then it crowds out the other part of the message, 
>> the pan/zoom status notification etc.
>>
>> Breaking the message into two lines almost works (so far only checking 
>> with gtkagg), but the plot gets resized depending on whether there is 
>> a status or not.
>>
>> I think that with some more fiddling around with that part of the 
>> toolbar--probably including breaking the message up into separate 
>> messages for status and readout, and maybe making the readout use two 
>> lines and always be present--we could make the readout and status 
>> display much nicer.  I have never liked the way it jumps around.
>>
> I also agree.
> However, I would like to be sure I understand one point correctly:
> As long as x<1000, the default format *is* an integer (at least when 
> imshow(M) is used).

No. Try

imshow(rand(4,4))

There is nothing special about imshow that makes the cursor readout an 
integer, nor should there be.

Again, the present default is "%1.3g". I think we can and will do 
better, but it is not necessarily trivial.

Eric

Thanks, it works well.

However, I forgot that computer modern does not include accented 
characters (unlike latin modern), so I eventually used Stix :

mpl.rc('font', family = 'serif', serif = 'STIXGeneral')

By the way, is there any way to use Stix for sans-serif as well, or even 
cursive and monospace ? I don't know how to do that, since Stix seems to 
contain all of them in a single file (STIXGeneral.ttf) ?

Nicolas


Michael Droettboom a écrit :
> The name of the Computer Modern Roman font that ships with matplotlib 
> is "cmr10", so
>
>   mpl.rc('font', family = 'serif', serif = 'cmr10')
>
> should work.
>
> Mike
>
> Nicolas Pourcelot wrote:
>> Hi,
>>
>> is there any way to use Computer Modern in any text in matplotlib ?
>>
>> In http://matplotlib.sourceforge.net/users/customizing.html, I read 
>> the following :
>>
>> #font.serif          : Bitstream Vera Serif, New Century Schoolbook, 
>> Century Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 
>> L, Times New Roman, Times, Palatino, Charter, serif
>> #font.sans-serif     : Bitstream Vera Sans, Lucida Grande, Verdana, 
>> Geneva, Lucid, Arial, Helvetica, Avant Garde, sans-serif
>> #font.cursive        : Apple Chancery, Textile, Zapf Chancery, Sand, 
>> cursive
>> #font.fantasy        : Comic Sans MS, Chicago, Charcoal, Impact, 
>> Western, fantasy
>> #font.monospace      : Bitstream Vera Sans Mono, Andale Mono, Nimbus 
>> Mono L, Courier New, Courier, Fixed, Terminal, monospace
>>   So, Computer Modern is not listed there.
>>
>> However, Computer Modern is used in mathtext, so I suppose there is a 
>> way to use it also in plain text, but I can't figure it...
>>
>> I tried :
>> /mpl.rc('font', family = 'serif', serif = 'computer modern roman')/
>> but it did not work.
>>
>> Thanks a lot,
>>
>> Nicolas P.
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------ 
>>
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
>> is a gathering of tech-side developers & brand creativity 
>> professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, 
>> & iPhoneDevCamp as they present alongside digital heavyweights like 
>> Barbarian Group, R/GA, & Big Spaceship. 
>> http://p.sf.net/sfu/creativitycat-com 
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Matplotlib-users@...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>   
>

Yannick Copin wrote:
> Hi,
> 
> I have an error while trying to use mpl.axes.set_default_color_cycle to 
> define my own color cycle based on the set1 colormap:
> 
> In [1]: set1 = array([[228,55, 77, 152,255,255,166,247,153],
>     ...:               [26, 126,175,78, 127,255,86, 129,153],
>     ...:               [28, 184,74, 163,0,  51, 40, 191,153]],'d').T / 255.
> 
> In [2]: mpl.axes.set_default_color_cycle(set1)
> ---------------------------------------------------------------------------
> AttributeError                            Traceback (most recent call last)

I just committed a change that should fix this bug.

Eric

> 
> /autofs/home/ycopin/<ipython console> in <module>()
> 
> /usr/lib/python2.5/site-packages/matplotlib/axes.py in 
> set_default_color_cycle(clist)
>      113     """
>      114     _process_plot_var_args.defaultColors = clist[:]
> --> 115     rcParams['lines.color'] = clist[0]
>      116
>      117 class _process_plot_var_args:
> 
> /usr/lib/python2.5/site-packages/matplotlib/__init__.pyc in 
> __setitem__(self, key, val)
>      588 instead.'% (key, alt))
>      589                 key = alt
> --> 590             cval = self.validate[key](val)
>      591             dict.__setitem__(self, key, cval)
>      592         except KeyError:
> 
> /usr/lib/python2.5/site-packages/matplotlib/rcsetup.pyc in validate_color(s)
>      156 def validate_color(s):
>      157     'return a valid color arg'
> --> 158     if s.lower() == 'none':
>      159         return 'None'
>      160     if is_color_like(s):
> 
> AttributeError: 'numpy.ndarray' object has no attribute 'lower'
> 
> I'm using matplotlib 0.98.3 but I checked on the SVN repository that the 
> offending lines ("rcParams['lines.color'] = clist[0]","if s.lower() == 
> 'none'") are still there.
> 
> Cheers.

On Fri, May 29, 2009 at 19:09, Neal Becker <ndbecker2@...> wrote:
>
> from pylab import semilogy, show, grid
> grid()
> semilogy (result[0])
>
> This gave me just a vertical grid.  What do I do to get both horiz and vert
> grids?

(without looking at a screenshot or to the dataset is hard to tell
but) is it possible that you have Y values contained in a single
logarithmic inteval (or even closer)? if so, there is no line on Y to
draw and only vertival lines (relative to X values) are displayed.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi,

I usually fix the size of the figure when I produce it. I use rcparams
below for a single column plot. This usually solves the problem. What
you see is what you get in the final document if you use the same size
of the figure as used to produce it.

def paper_single():
    plt.rc('figure', figsize=(3.375,3.375))
    plt.rc('figure.subplot', left=0.15, right=0.97, bottom=0.1, top=0.95)
    plt.rc('lines', linewidth=1.5)
    plt.rc('font', size=10.0)
    plt.rc('xtick', labelsize='small')
    plt.rc('ytick', labelsize='small')
    plt.rc('legend', fontsize='medium')

Cheers,
Chaitanya


On Fri, May 29, 2009 at 5:25 PM, Paul Anton Letnes
<paul.anton.letnes@...> wrote:
> Howdy y'all!
>
> I'm trying to make a publication quality plot for a two-column latex
> article. I'm using latex for text processing, so the plot quality
> itself is impeccable. However, as I scale the plot size down, the
> legend becomes extremely large compared to the plot itself.  Has
> anyone solved this problem in a good manner? I'm not willing to make
> do without the legend.
>
> cheers,
> Paul.
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Matplotlib-users mailing list
> Matplotlib-users@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Fri, May 29, 2009 at 10:25 AM, Paul Anton Letnes
<paul.anton.letnes@...> wrote:

> I'm trying to make a publication quality plot for a two-column latex
> article. I'm using latex for text processing, so the plot quality
> itself is impeccable. However, as I scale the plot size down, the
> legend becomes extremely large compared to the plot itself.  Has
> anyone solved this problem in a good manner? I'm not willing to make
> do without the legend.

The major determinant of the legend is the fontsize, so if you want to
make a small figure in inches, you may want to make the legend font
smaller

  import matplotlib.font_manager as font_manager
  leg = ax.legend(loc='upper left', prop=font_manager.FontProperties(size=10))

JDH

Hi again,

Ole Streicher <ole-usenet-spam@...> writes:
> Darren Dale <dsdale24@...> writes:
>> I am really busy with other things, and can't offer suggestions unless
>> you post a short, simple, standalone script that demonstrates the
>> problem.
> Sure:
> w.show()
> a.exec_()

I forgot to say: execute this code, and then try to resize the window
width with the mouse -- this leads to a wrong scrollbar width. Trying to
resize the window height with the mouse leads to a wrong scrollbar
position.

Best regards

Ole

Hallo Theodore,

"Drain, Theodore R"
<theodore.r.drain@...> writes:
> Remember, this is not a multi-threaded system.  You can't receive a
> second repaint event while the drawing code is happening because the
> event loop is not in a separate thread.  

This is not my choice. If the user resizes the window, the events are created
in that manner. 

And I cannot prevent the user from resizing the window.

Best regards

Ole

On Thu, May 28, 2009 at 6:01 PM, Sandro Tosi <morph@...> wrote:

> Hi Darren,
>
> On Thu, May 28, 2009 at 19:16, Darren Dale <dsdale24@...> wrote:
> > Try the attached script.
>
> Oh it works very great! thanks you very much!
>
> One thing I've done is also remove
>
> import matplotlib
> matplotlib.use('Qt4Agg')
>
> since we're already importing the qt4agg backend directly right after.
>
> One only thing it's left a bit obscure (also because doc is a little
> missing) is this piece of code:
>
>        # update the data
>        self.line.set_ydata(np.sin(self.x+self.cnt/10.0))
>        # just draw the animated artist
>        self.ax.draw_artist(self.line)
>        # just redraw the axes rectangle
>        self.blit(self.ax.bbox)
>
> first, I've not clear wat draw_artist and blit does, so if you can
> shine some light on me :)
>
> Secondly, the "effect" I'd like to achieve is to update the current
> line values and "replace" the current line with a new one. In this
> code, instead, the line is plotted keeping the previous instances
> around. So the effect is to fil the canvas with sin function plots
> instead of updating only one instance.
>
> Do you know how to "fix" this?
>

Not off the top of my head. Maybe someone else on the list can offer a
suggestion.

Darren

Hi Darren,

On Fri, May 29, 2009 at 01:50, Darren Dale <dsdale24@...> wrote:
> On Thu, May 28, 2009 at 6:01 PM, Sandro Tosi <morph@...> wrote:
>>
>> Hi Darren,
>>
>> On Thu, May 28, 2009 at 19:16, Darren Dale <dsdale24@...> wrote:
>> > Try the attached script.
>>
>> Oh it works very great! thanks you very much!
>>
>> One thing I've done is also remove
>>
>> import matplotlib
>> matplotlib.use('Qt4Agg')
>>
>> since we're already importing the qt4agg backend directly right after.
>>
>> One only thing it's left a bit obscure (also because doc is a little
>> missing) is this piece of code:
>>
>>        # update the data
>>        self.line.set_ydata(np.sin(self.x+self.cnt/10.0))
>>        # just draw the animated artist
>>        self.ax.draw_artist(self.line)
>>        # just redraw the axes rectangle
>>        self.blit(self.ax.bbox)
>>
>> first, I've not clear wat draw_artist and blit does, so if you can
>> shine some light on me :)
>>
>> Secondly, the "effect" I'd like to achieve is to update the current
>> line values and "replace" the current line with a new one. In this
>> code, instead, the line is plotted keeping the previous instances
>> around. So the effect is to fil the canvas with sin function plots
>> instead of updating only one instance.
>>
>> Do you know how to "fix" this?
>
> Not off the top of my head. Maybe someone else on the list can offer a
> suggestion.

Thanks a lot for your help! Early morning coding did help! :)

I'm attaching a script to do what I wanted to. The solution was to
remove the animated=True when calling self.ax.plot and then call an
explicit self.fig.canvas.draw() - and here it is an animate sin and
cos function! :)

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Nicolas Pourcelot wrote:
> Thanks for your answer.
>
>
> Michael Droettboom a écrit :
>> Handling this like an accent is trivial, and handled with the patch 
>> below (which I will commit to SVN).
> It is however not so much useful, since \vec does already the job.
The rightarrow is longer than vec.  Much more suitable for multiple 
letters underneath.
>
>> Handling this in such a way that the length of the arrow changes 
>> based on the size of the underlying text is less straightforward and 
>> will take some time to implement.
> This is what I meant, yes.
> Hope you will success, I miss it quite a lot for now.
I'll get to this when I have the time.

Cheers,
Mike
>
>> Cheers,
>> Mike
>>
>> Index: lib/matplotlib/mathtext.py
>> ===================================================================
>> --- lib/matplotlib/mathtext.py    (revision 7148)
>> +++ lib/matplotlib/mathtext.py    (working copy)
>> @@ -2445,7 +2445,9 @@
>>         r"'"     : r'\combiningacuteaccent',
>>         r'~'     : r'\combiningtilde',
>>         r'.'     : r'\combiningdotabove',
>> -        r'^'     : r'\circumflexaccent'
>> +        r'^'     : r'\circumflexaccent',
>> +        r'overrightarrow' : r'\rightarrow',
>> +        r'overleftarrow'  : r'\leftarrow'
>>         }
>>
>>     _wide_accents = set(r"widehat widetilde".split())
>>
>> Nicolas Pourcelot wrote:
>>> Hi,
>>>
>>> is there any way to display a big arrow on a vector using mathtext, 
>>> like "$\overrightarrow{AB}$" ?
>>>
>>> If not, is there any plan to implement it in a next release ?
>>>
>>> Thanks a lot,
>>>
>>> Nicolas P.
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
>>> is a gathering of tech-side developers & brand creativity 
>>> professionals. Meet
>>> the minds behind Google Creative Lab, Visual Complexity, Processing, 
>>> & iPhoneDevCamp as they present alongside digital heavyweights like 
>>> Barbarian Group, R/GA, & Big Spaceship. 
>>> http://p.sf.net/sfu/creativitycat-com 
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Matplotlib-users@...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>   
>>