matplotlib-devel Mailing List for matplotlib

Howdy,
do we have the ubuntu packaging team on this list, or any way to contact them?
Today Stefan and I burned a few hours tracking this bug down, again,
which I'd already debugged a couple of months ago and totally
forgotten about:
https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/871176
It would be great if anyone here has any contacts with the ubuntu mpl
team and this could get fixed. On launchpad there's been zero
response, so I'm trying this way now...
Cheers,
f

Hi Chris and others,
On 11/23/11 12:39 PM, Chris Barker wrote:
> On 11/23/11 10:38 AM, Benjamin Root wrote:
> 
> 
> > There is an HTML5 backend, supposedly. Don't know how well documented it is, though.
> > 
> 
> Hmm -- coll idea -- I'll look into that at some point. However, as I
> don't need the MPL machinerey, but just the renderer, I'm not sure it
> would buy me much.
> 
> And I'm not sure I can:
> 
> a) count on html 5 on all browsers we need to support
> 
> or
> 
> b) get the drawing performance I want if I have to push all the data to
> the client to draw.
> 
> But something to keep an eye on, thanks.
Ben is referring to mplh5canvas, available at http://code.google.com/p/mplh5canvas/. The main advantage of this approach is interactive zooming of plots within the browser. If this is not important to you, it will probably be faster to generate static PNGs or SVGs.
The HTML5 backend should be easy to try out, as it is a pure Python package with no onerous dependencies.
I'll try to address your concerns mentioned above:
a) The Canvas element is quite well supported in modern browsers, but the WebSocket component (used to communicate between the matplotlib backend "server" code in Python and the "client" code on the browser in JavaScript) is a bit trickier to support.
b) Here the matplotlib machinery actually helps, by reducing the primitives to draw via path simplification before sending them to the client browser.
We have also used flot (http://code.google.com/p/flot/) for simple time-series plots without matplotlib. I'm not sure how well it performs on large data sets, though.
Regards,
Ludwig

On Sunday, November 27, 2011, Roberto Colistete Jr. <
rob...@gm...> wrote:
> Hi,
>
> In MatPlotLib 1.0.0 the example 'mplot3d/surface3d_demo.py' has the
> line :
> ax.set_zlim3d(-1.01, 1.01)
> while the same file in MatPlotLib 1.1.0 has :
> ax.set_zlim(-1.01, 1.01)
>
> If I try to use ax.set_zlim(-1.01, 1.01) with MatPlotLib 1.0.0 I get :
> "$ python surface3d_demo.py
> Traceback (most recent call last):
> File "surface3d_demo.py", line 16, in <module>
> ax.set_zlim(-1.01, 1.01)
> AttributeError: 'Axes3DSubplot' object has no attribute 'set_zlim'"
>
> So what is the recommended way for maximum compatibility
> (1.0.0/1.1.0) ? Use 'set_zlim' or 'set_zlim3d ?
>
> Thanks in advance,
>
> Roberto
>
What is recommended is to upgrade to v1.1.0 where the behavior is much more
intuitive and follows expected conventions. If that is not possible, then
use set_*lim3d().
Ben Root

 Hi,
 In MatPlotLib 1.0.0 the example 'mplot3d/surface3d_demo.py' has the 
line :
ax.set_zlim3d(-1.01, 1.01)
while the same file in MatPlotLib 1.1.0 has :
ax.set_zlim(-1.01, 1.01)
 If I try to use ax.set_zlim(-1.01, 1.01) with MatPlotLib 1.0.0 I get :
"$ python surface3d_demo.py
Traceback (most recent call last):
 File "surface3d_demo.py", line 16, in <module>
 ax.set_zlim(-1.01, 1.01)
AttributeError: 'Axes3DSubplot' object has no attribute 'set_zlim'"
 So what is the recommended way for maximum compatibility 
(1.0.0/1.1.0) ? Use 'set_zlim' or 'set_zlim3d ?
 Thanks in advance,
 Roberto

On 11/23/11 10:13 AM, Friedrich Romstedt wrote:
> 2011年11月23日 Chris.Barker<Chr...@no...>:
>> I've got some drawing to do (for a web app). I don't need all the MPL
>> machinery, but I do need a high quality, fast, renderer.
>
> http://www.effbot.org/zone/aggdraw-index.htm
I've been wondering about that -- it doesn't look terribly maintained -- 
no updates for a long time, and I'm concerned about performance 99 if 
you are drawing something simple, but with lot's of points, all that 
conversion from numpy types to python type to C types is going to be an 
issue.
> http://www.effbot.org/imagingbook/imagedraw.htm
this is definitely slow for what I'm doing.
Thanks,
 -Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

 Hi,
 It is my first post to matplotlib-dev. I am a theoretical physicist 
interested a lot in Python/IPython/SymPy/NumPy/MatPlotLib/etc. Both for 
desktop OS and mobile OS.
 About mobile OS (for smartphones/tablets), MatPlotLib is packaged 
and works well in :
- MeeGo 1.2 Harmattan OS on Nokia N9/N950, released in 2011, with Nokia 
N9 selling since September/October. MatPlotLib 1.0.0 was released 
yesterday by me (as a maintainer) :
http://forum.meego.com/showthread.php?t=5231
http://talk.maemo.org/showthread.php?p=1128672
- Maemo 5 (Fremantle) OS on Nokia N900, released in 11/2009 and 
currently difficult to buy brand new. Install using "# apt-get install 
python-matplotlib" :
http://maemo.org/packages/view/python-matplotlib/
NumPy, SymPy and IPython are also available for both OS. I have searched 
and found that there is no MatPlotLib for Android OS, iOS and Symbian.
 So it seems that the only smartphone selling today with MatPlotLib 
support is Nokia N9 (MeeGo 1.2 Harmattan OS). The repositories for Nokia 
N9 :
http://harmattan-dev.nokia.com/unstable/beta3/Fremantle_Update7_vs_Harmattan_Beta3_content_comparison.html 
show about 170 Python packages.
 MeeGo Harmattan is also a developer's paradise, with more than 10 
programming languages available now (via "apt-get install" or already 
installed) : gcc/g++ (3.4, 4.2, 4.4), gfortran 4.4, gpc (GNU Pascal 
2.2), Lua 5.1, Perl 5.8, Prolog, Python 2.5/2.6/3.1, Ruby 1.8, TCL 
8.4/8.5, Vala 0.12, etc. Also Qt/C++, Qt/Qt Quick, Qt/Python (PySide).
 Best regards from Brazil,
 Roberto

On 11/23/11 10:38 AM, Benjamin Root wrote:
> On Wednesday, November 23, 2011, Chris.Barker <Chr...@no...
> <mailto:Chr...@no...>> wrote:
> > Hi Folks,
> >
> > I've got some drawing to do (for a web app). I don't need all the MPL
> > machinery, but I do need a high quality, fast, renderer.
> There is an HTML5 backend, supposedly. Don't know how well documented
> it is, though.
Hmm -- coll idea -- I'll look into that at some point. However, as I 
don't need the MPL machinerey, but just the renderer, I'm not sure it 
would buy me much.
And I'm not sure I can:
a) count on html 5 on all browsers we need to support
or
b) get the drawing performance I want if I have to push all the data to 
the client to draw.
But something to keep an eye on, thanks.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Wednesday, November 23, 2011, Chris.Barker <Chr...@no...> wrote:
> Hi Folks,
>
> I've got some drawing to do (for a web app). I don't need all the MPL
> machinery, but I do need a high quality, fast, renderer.
>
> Other options:
>
> - The python bindings to GD seem to not really being maintained
>
> - PyCairo is a pain to install, and not fast for Python (doesn't know
> about numpy arrays of points, for instance)
>
> - Kiva appears to be quite enmeshed with ETS, and thus a bit of trick
> to install (at least without EPD or PythonXY or something)
>
>
> So I thought I'd give MPL's AGG wrappers a try. I've managed to get
> things working, but I do have a couple questions:
>
> 1) are there docs somewhere? What I've found is very sparse, and doc
> strings are minimal -- though I've got the source, so only so much or a
> complaint.
>
> 2) It looks like the AGG renderers take floats for almost everything --
> makes sense, with anti-aliasing and sub-pixel rendering. But is it
> float32 or float64 internally? It seems either will work, but I'm going
> for maximum performance, so I'd like to use the native format.
>
>
> Testing drawing a polygon, I'm a bit confused about GraphicsContext vs
> the renderer. If I do:
>
> gc = GraphicsContextBase()
> transform = Affine2D() # default unit transform
>
> ## draw the polygon:
> ## create a path for a polygon:
> points =
np.array(((10,10),(10,190),(150,100),(290,10),(10,10)),np.float64)
>
> p = Path(points)
>
> gc.set_linewidth(4)
> gc.set_alpha(0.75)
>
> fill_color = (0.0, 1.0, 0.0)
> line_color = (1.0, 0.0, 0.0)
>
> #gc._rgb = line_color
> gc.set_foreground(line_color)
>
> Canvas.draw_path(gc, p, transform, fill_color)
>
> I get a green polygon with a red border, like I'd expect. However:
>
> Why is the outline color set in the GraphicsContext, but the fill color
> passed in to the draw_path call? Or am I doing that wrong?
>
>
> Thanks for input,
>
> -Chris
>
>
There is an HTML5 backend, supposedly. Don't know how well documented it
is, though.
Ben Root

2011年11月23日 Chris.Barker <Chr...@no...>:
> I've got some drawing to do (for a web app). I don't need all the MPL
> machinery, but I do need a high quality, fast, renderer.
http://www.effbot.org/zone/aggdraw-index.htm
http://www.effbot.org/imagingbook/imagedraw.htm
Don't know if this suffices your needs.
Friedrich

On 11/23/11 9:52 AM, Chris.Barker wrote:
> I've got some drawing to do (for a web app). I don't need all the MPL
> machinery, but I do need a high quality, fast, renderer.
One more question. I see:
 def draw_markers(self, *kl, **kw):
 # for filtering to work with rastrization, methods needs to be 
wrapped.
 # maybe there is better way to do it.
 return self._renderer.draw_markers(*kl, **kw)
What do I pass in to this function?
Thanks,
 -Chris
> Other options:
>
> - The python bindings to GD seem to not really being maintained
>
> - PyCairo is a pain to install, and not fast for Python (doesn't know
> about numpy arrays of points, for instance)
>
> - Kiva appears to be quite enmeshed with ETS, and thus a bit of trick
> to install (at least without EPD or PythonXY or something)
>
>
> So I thought I'd give MPL's AGG wrappers a try. I've managed to get
> things working, but I do have a couple questions:
>
> 1) are there docs somewhere? What I've found is very sparse, and doc
> strings are minimal -- though I've got the source, so only so much or a
> complaint.
>
> 2) It looks like the AGG renderers take floats for almost everything --
> makes sense, with anti-aliasing and sub-pixel rendering. But is it
> float32 or float64 internally? It seems either will work, but I'm going
> for maximum performance, so I'd like to use the native format.
>
>
> Testing drawing a polygon, I'm a bit confused about GraphicsContext vs
> the renderer. If I do:
>
> gc = GraphicsContextBase()
> transform = Affine2D() # default unit transform
>
> ## draw the polygon:
> ## create a path for a polygon:
> points = np.array(((10,10),(10,190),(150,100),(290,10),(10,10)),np.float64)
>
> p = Path(points)
>
> gc.set_linewidth(4)
> gc.set_alpha(0.75)
>
> fill_color = (0.0, 1.0, 0.0)
> line_color = (1.0, 0.0, 0.0)
>
> #gc._rgb = line_color
> gc.set_foreground(line_color)
>
> Canvas.draw_path(gc, p, transform, fill_color)
>
> I get a green polygon with a red border, like I'd expect. However:
>
> Why is the outline color set in the GraphicsContext, but the fill color
> passed in to the draw_path call? Or am I doing that wrong?
>
>
> Thanks for input,
>
> -Chris
>
>
>
>
>
>
>
>
>
>
>
>
>
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi Folks,
I've got some drawing to do (for a web app). I don't need all the MPL 
machinery, but I do need a high quality, fast, renderer.
Other options:
 - The python bindings to GD seem to not really being maintained
 - PyCairo is a pain to install, and not fast for Python (doesn't know 
about numpy arrays of points, for instance)
 - Kiva appears to be quite enmeshed with ETS, and thus a bit of trick 
to install (at least without EPD or PythonXY or something)
So I thought I'd give MPL's AGG wrappers a try. I've managed to get 
things working, but I do have a couple questions:
1) are there docs somewhere? What I've found is very sparse, and doc 
strings are minimal -- though I've got the source, so only so much or a 
complaint.
2) It looks like the AGG renderers take floats for almost everything -- 
makes sense, with anti-aliasing and sub-pixel rendering. But is it 
float32 or float64 internally? It seems either will work, but I'm going 
for maximum performance, so I'd like to use the native format.
Testing drawing a polygon, I'm a bit confused about GraphicsContext vs 
the renderer. If I do:
gc = GraphicsContextBase()
transform = Affine2D() # default unit transform
## draw the polygon:
## create a path for a polygon:
points = np.array(((10,10),(10,190),(150,100),(290,10),(10,10)),np.float64)
p = Path(points)
gc.set_linewidth(4)
gc.set_alpha(0.75)
fill_color = (0.0, 1.0, 0.0)
line_color = (1.0, 0.0, 0.0)
#gc._rgb = line_color
gc.set_foreground(line_color)
Canvas.draw_path(gc, p, transform, fill_color)
I get a green polygon with a red border, like I'd expect. However:
Why is the outline color set in the GraphicsContext, but the fill color 
passed in to the draw_path call? Or am I doing that wrong?
Thanks for input,
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I'm sorry this fell through the cracks. It was removed from the build 
because it does not currently build on Python 3.x, and then when I saw 
the functionality was redundant, I think it necessary to invest effort 
porting it. None of the test suite uses this code. The source should 
have been removed at the same time, as well as updating the mlab usage. 
You'll see I did add a "TODO" above it that should have been addressed 
before merging into master.
This shows a hole in the test coverage -- we should add a test that uses 
mlab.inside_poly as part of fixing this.
Mike
On 11/18/2011 10:48 AM, James Evans wrote:
>
> I was just shocked to find the source code still present, just not 
> compiled during the build step and at least one completely broken 
> function call still referencing the un-built module and no apparent 
> reason for removal.
>
> I have updated mlab.inside_poly to use Path instead and will submit it 
> later today.
>
> --James
>
> *From:*Michael Droettboom [mailto:md...@st...]
> *Sent:* Friday, November 18, 2011 6:23 AM
> *To:* mat...@li...
> *Subject:* Re: [matplotlib-devel] nxutils
>
> Perhaps another alternative is to just include a small compatibility 
> module that would call the new functionality under the hood.
>
> Mike
>
> On 11/18/2011 09:07 AM, Michael Droettboom wrote:
>
> nxutils has been removed from master because it is completely 
> redundant to the Path functionality that has been in matplotlib since 
> 0.98. In the process of porting to Python 3, I felt it was important 
> to reduce code duplication, because every additional line requires 
> additional testing.
>
> That said, there seems to be a lot of push back on this. We can 
> reinstate it, but I would suggest raising DeprecationWarnings for one 
> release and then removing it entirely in the next.
>
> Mike
>
> On 11/18/2011 12:21 AM, Benjamin Root wrote:
>
> Huh? Nxutils removed? Then how am I still using points_inside_poly? 
> And, if I remember right, Path uses that to calculate contains().
>
> Ben Root
>
> On Thursday, November 17, 2011, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> > On 11/17/2011 10:19 AM, Michael Droettboom wrote:
> >> Most of what was in nxutils has been superseded by things in Numpy, and
> >> it makes more sense for it to be over there.
> >>
> >> In the case of points_inside_poly, you can use the Path object in
> >> path.py and the "contains_point" method.
> >>
> >> Mike
> >
> > Mike,
> >
> > This, however, brings us back to the plea by Volker Blum:
> >
> > 
> http://www.mail-archive.com/mat...@li.../msg22669.html
> >
> > There is a real tension between the need to clean things up and simplify
> > them, and users' desire for minimal loss of backwards compatibility.
> > Personally, my instincts are in the "clean it up" camp, but a good
> > balance has to be found.
> >
> > nxutils was definitely a vestige of an earlier era; but I don't think it
> > went through any official, publicized, deprecation process, did it?
> > Maybe it didn't need to; I don't know. Perhaps we need to formulate and
> > write down a deprecation policy.
> >
> > Eric
> >
> >>
> >> On 11/17/2011 12:03 PM, James Evans wrote:
> >>>
> >>> All,
> >>>
> >>> I have not touched the code for several months, so it has taken me up
> >>> until just now to realize that nxutils has been removed from the 
> build.
> >>>
> >>> I there any real reason for this? Particularly when you consider that
> >>> there are still functions present that use it and now they just fail.
> >>>
> >>> In particular I am referring to 'mlab.inside_poly'. In my case I was
> >>> using 'nxutils.points_inside_poly' directly, but the end result is the
> >>> same.
> >>>
> >>> Thanks,
> >>>
> >>> --James Evans
> >>>
> >>>
> >>>
> >>> 
> ------------------------------------------------------------------------------
> >>> 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
> >>> Mat...@li... 
> <mailto:Mat...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >>
> >>
> >> 
> ------------------------------------------------------------------------------
> >> 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
> >> Mat...@li... 
> <mailto:Mat...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> > 
> ------------------------------------------------------------------------------
> > 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
> > Mat...@li... 
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li... <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li... <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Dear Tony,
I tried the example with several colormaps (have you checked out
cubehelix which nicely resembles the grey scale visual intensity
distribution in color) and I definitely agree that it would be good
for matplotlib to switch to a more sensible default color map. My
personal vote goes to coolwarm which has well defined behaviour and is
suitable (e.g. looks nice) for a wide range of applications.
Kind regards,
Pim Schellart
P.S. Although cubehelix also has well defined behaviour it is less
optimal as a default since it does not look nice in all use cases (but
is very good in some, particularly for cases where the percieved
intensity distribution needs to be the same when viewed on screen and
printed in black and white).

I was just shocked to find the source code still present, just not compiled
during the build step and at least one completely broken function call still
referencing the un-built module and no apparent reason for removal. 
 
I have updated mlab.inside_poly to use Path instead and will submit it later
today.
 
--James
 
 
From: Michael Droettboom [mailto:md...@st...] 
Sent: Friday, November 18, 2011 6:23 AM
To: mat...@li...
Subject: Re: [matplotlib-devel] nxutils
 
Perhaps another alternative is to just include a small compatibility module
that would call the new functionality under the hood.
Mike
On 11/18/2011 09:07 AM, Michael Droettboom wrote: 
nxutils has been removed from master because it is completely redundant to
the Path functionality that has been in matplotlib since 0.98. In the
process of porting to Python 3, I felt it was important to reduce code
duplication, because every additional line requires additional testing.
That said, there seems to be a lot of push back on this. We can reinstate
it, but I would suggest raising DeprecationWarnings for one release and then
removing it entirely in the next.
Mike
On 11/18/2011 12:21 AM, Benjamin Root wrote: 
Huh? Nxutils removed? Then how am I still using points_inside_poly? And, if
I remember right, Path uses that to calculate contains().
Ben Root
On Thursday, November 17, 2011, Eric Firing <ef...@ha...> wrote:
> On 11/17/2011 10:19 AM, Michael Droettboom wrote:
>> Most of what was in nxutils has been superseded by things in Numpy, and
>> it makes more sense for it to be over there.
>>
>> In the case of points_inside_poly, you can use the Path object in
>> path.py and the "contains_point" method.
>>
>> Mike
>
> Mike,
>
> This, however, brings us back to the plea by Volker Blum:
>
>
http://www.mail-archive.com/mat...@li.../msg22669.
html
>
> There is a real tension between the need to clean things up and simplify
> them, and users' desire for minimal loss of backwards compatibility.
> Personally, my instincts are in the "clean it up" camp, but a good
> balance has to be found.
>
> nxutils was definitely a vestige of an earlier era; but I don't think it
> went through any official, publicized, deprecation process, did it?
> Maybe it didn't need to; I don't know. Perhaps we need to formulate and
> write down a deprecation policy.
>
> Eric
>
>>
>> On 11/17/2011 12:03 PM, James Evans wrote:
>>>
>>> All,
>>>
>>> I have not touched the code for several months, so it has taken me up
>>> until just now to realize that nxutils has been removed from the build.
>>>
>>> I there any real reason for this? Particularly when you consider that
>>> there are still functions present that use it and now they just fail.
>>>
>>> In particular I am referring to 'mlab.inside_poly'. In my case I was
>>> using 'nxutils.points_inside_poly' directly, but the end result is the
>>> same.
>>>
>>> Thanks,
>>>
>>> --James Evans
>>>
>>>
>>>
>>>
----------------------------------------------------------------------------
--
>>> 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
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>>
----------------------------------------------------------------------------
--
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
----------------------------------------------------------------------------
--
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
----------------------------------------------------------------------------
--
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
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
----------------------------------------------------------------------------
--
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
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 

Perhaps another alternative is to just include a small compatibility 
module that would call the new functionality under the hood.
Mike
On 11/18/2011 09:07 AM, Michael Droettboom wrote:
> nxutils has been removed from master because it is completely 
> redundant to the Path functionality that has been in matplotlib since 
> 0.98. In the process of porting to Python 3, I felt it was important 
> to reduce code duplication, because every additional line requires 
> additional testing.
>
> That said, there seems to be a lot of push back on this. We can 
> reinstate it, but I would suggest raising DeprecationWarnings for one 
> release and then removing it entirely in the next.
>
> Mike
>
> On 11/18/2011 12:21 AM, Benjamin Root wrote:
>> Huh? Nxutils removed? Then how am I still using points_inside_poly? 
>> And, if I remember right, Path uses that to calculate contains().
>>
>> Ben Root
>>
>> On Thursday, November 17, 2011, Eric Firing <ef...@ha... 
>> <mailto:ef...@ha...>> wrote:
>> > On 11/17/2011 10:19 AM, Michael Droettboom wrote:
>> >> Most of what was in nxutils has been superseded by things in 
>> Numpy, and
>> >> it makes more sense for it to be over there.
>> >>
>> >> In the case of points_inside_poly, you can use the Path object in
>> >> path.py and the "contains_point" method.
>> >>
>> >> Mike
>> >
>> > Mike,
>> >
>> > This, however, brings us back to the plea by Volker Blum:
>> >
>> > 
>> http://www.mail-archive.com/mat...@li.../msg22669.html
>> >
>> > There is a real tension between the need to clean things up and 
>> simplify
>> > them, and users' desire for minimal loss of backwards compatibility.
>> > Personally, my instincts are in the "clean it up" camp, but a good
>> > balance has to be found.
>> >
>> > nxutils was definitely a vestige of an earlier era; but I don't 
>> think it
>> > went through any official, publicized, deprecation process, did it?
>> > Maybe it didn't need to; I don't know. Perhaps we need to 
>> formulate and
>> > write down a deprecation policy.
>> >
>> > Eric
>> >
>> >>
>> >> On 11/17/2011 12:03 PM, James Evans wrote:
>> >>>
>> >>> All,
>> >>>
>> >>> I have not touched the code for several months, so it has taken me up
>> >>> until just now to realize that nxutils has been removed from the 
>> build.
>> >>>
>> >>> I there any real reason for this? Particularly when you consider that
>> >>> there are still functions present that use it and now they just fail.
>> >>>
>> >>> In particular I am referring to 'mlab.inside_poly'. In my case I was
>> >>> using 'nxutils.points_inside_poly' directly, but the end result 
>> is the
>> >>> same.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> --James Evans
>> >>>
>> >>>
>> >>>
>> >>> 
>> ------------------------------------------------------------------------------
>> >>> 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
>> >>> Mat...@li... 
>> <mailto:Mat...@li...>
>> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>
>> >>
>> >>
>> >> 
>> ------------------------------------------------------------------------------
>> >> 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
>> >> Mat...@li... 
>> <mailto:Mat...@li...>
>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>> >
>> >
>> > 
>> ------------------------------------------------------------------------------
>> > 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
>> > Mat...@li... 
>> <mailto:Mat...@li...>
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

nxutils has been removed from master because it is completely redundant 
to the Path functionality that has been in matplotlib since 0.98. In 
the process of porting to Python 3, I felt it was important to reduce 
code duplication, because every additional line requires additional testing.
That said, there seems to be a lot of push back on this. We can 
reinstate it, but I would suggest raising DeprecationWarnings for one 
release and then removing it entirely in the next.
Mike
On 11/18/2011 12:21 AM, Benjamin Root wrote:
> Huh? Nxutils removed? Then how am I still using points_inside_poly? 
> And, if I remember right, Path uses that to calculate contains().
>
> Ben Root
>
> On Thursday, November 17, 2011, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> > On 11/17/2011 10:19 AM, Michael Droettboom wrote:
> >> Most of what was in nxutils has been superseded by things in Numpy, and
> >> it makes more sense for it to be over there.
> >>
> >> In the case of points_inside_poly, you can use the Path object in
> >> path.py and the "contains_point" method.
> >>
> >> Mike
> >
> > Mike,
> >
> > This, however, brings us back to the plea by Volker Blum:
> >
> > 
> http://www.mail-archive.com/mat...@li.../msg22669.html
> >
> > There is a real tension between the need to clean things up and simplify
> > them, and users' desire for minimal loss of backwards compatibility.
> > Personally, my instincts are in the "clean it up" camp, but a good
> > balance has to be found.
> >
> > nxutils was definitely a vestige of an earlier era; but I don't think it
> > went through any official, publicized, deprecation process, did it?
> > Maybe it didn't need to; I don't know. Perhaps we need to formulate and
> > write down a deprecation policy.
> >
> > Eric
> >
> >>
> >> On 11/17/2011 12:03 PM, James Evans wrote:
> >>>
> >>> All,
> >>>
> >>> I have not touched the code for several months, so it has taken me up
> >>> until just now to realize that nxutils has been removed from the 
> build.
> >>>
> >>> I there any real reason for this? Particularly when you consider that
> >>> there are still functions present that use it and now they just fail.
> >>>
> >>> In particular I am referring to 'mlab.inside_poly'. In my case I was
> >>> using 'nxutils.points_inside_poly' directly, but the end result is the
> >>> same.
> >>>
> >>> Thanks,
> >>>
> >>> --James Evans
> >>>
> >>>
> >>>
> >>> 
> ------------------------------------------------------------------------------
> >>> 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
> >>> Mat...@li... 
> <mailto:Mat...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >>
> >>
> >> 
> ------------------------------------------------------------------------------
> >> 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
> >> Mat...@li... 
> <mailto:Mat...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> > 
> ------------------------------------------------------------------------------
> > 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
> > Mat...@li... 
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Huh? Nxutils removed? Then how am I still using points_inside_poly? And, if
I remember right, Path uses that to calculate contains().
Ben Root
On Thursday, November 17, 2011, Eric Firing <ef...@ha...> wrote:
> On 11/17/2011 10:19 AM, Michael Droettboom wrote:
>> Most of what was in nxutils has been superseded by things in Numpy, and
>> it makes more sense for it to be over there.
>>
>> In the case of points_inside_poly, you can use the Path object in
>> path.py and the "contains_point" method.
>>
>> Mike
>
> Mike,
>
> This, however, brings us back to the plea by Volker Blum:
>
>
http://www.mail-archive.com/mat...@li.../msg22669.html
>
> There is a real tension between the need to clean things up and simplify
> them, and users' desire for minimal loss of backwards compatibility.
> Personally, my instincts are in the "clean it up" camp, but a good
> balance has to be found.
>
> nxutils was definitely a vestige of an earlier era; but I don't think it
> went through any official, publicized, deprecation process, did it?
> Maybe it didn't need to; I don't know. Perhaps we need to formulate and
> write down a deprecation policy.
>
> Eric
>
>>
>> On 11/17/2011 12:03 PM, James Evans wrote:
>>>
>>> All,
>>>
>>> I have not touched the code for several months, so it has taken me up
>>> until just now to realize that nxutils has been removed from the build.
>>>
>>> I there any real reason for this? Particularly when you consider that
>>> there are still functions present that use it and now they just fail.
>>>
>>> In particular I am referring to ‘mlab.inside_poly’. In my case I was
>>> using ‘nxutils.points_inside_poly’ directly, but the end result is the
>>> same.
>>>
>>> Thanks,
>>>
>>> --James Evans
>>>
>>>
>>>
>>>
------------------------------------------------------------------------------
>>> 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
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>>
------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 11/17/2011 10:19 AM, Michael Droettboom wrote:
> Most of what was in nxutils has been superseded by things in Numpy, and
> it makes more sense for it to be over there.
>
> In the case of points_inside_poly, you can use the Path object in
> path.py and the "contains_point" method.
>
> Mike
Mike,
This, however, brings us back to the plea by Volker Blum:
http://www.mail-archive.com/mat...@li.../msg22669.html
There is a real tension between the need to clean things up and simplify 
them, and users' desire for minimal loss of backwards compatibility. 
Personally, my instincts are in the "clean it up" camp, but a good 
balance has to be found.
nxutils was definitely a vestige of an earlier era; but I don't think it 
went through any official, publicized, deprecation process, did it? 
Maybe it didn't need to; I don't know. Perhaps we need to formulate and 
write down a deprecation policy.
Eric
>
> On 11/17/2011 12:03 PM, James Evans wrote:
>>
>> All,
>>
>> I have not touched the code for several months, so it has taken me up
>> until just now to realize that nxutils has been removed from the build.
>>
>> I there any real reason for this? Particularly when you consider that
>> there are still functions present that use it and now they just fail.
>>
>> In particular I am referring to ‘mlab.inside_poly’. In my case I was
>> using ‘nxutils.points_inside_poly’ directly, but the end result is the
>> same.
>>
>> Thanks,
>>
>> --James Evans
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Most of what was in nxutils has been superseded by things in Numpy, and 
it makes more sense for it to be over there.
In the case of points_inside_poly, you can use the Path object in 
path.py and the "contains_point" method.
Mike
On 11/17/2011 12:03 PM, James Evans wrote:
>
> All,
>
> I have not touched the code for several months, so it has taken me up 
> until just now to realize that nxutils has been removed from the build.
>
> I there any real reason for this? Particularly when you consider that 
> there are still functions present that use it and now they just fail.
>
> In particular I am referring to 'mlab.inside_poly'. In my case I was 
> using 'nxutils.points_inside_poly' directly, but the end result is the 
> same.
>
> Thanks,
>
> --James Evans
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

All,
 
I have not touched the code for several months, so it has taken me up until
just now to realize that nxutils has been removed from the build.
 
I there any real reason for this? Particularly when you consider that there
are still functions present that use it and now they just fail.
 
In particular I am referring to 'mlab.inside_poly'. In my case I was using
'nxutils.points_inside_poly' directly, but the end result is the same.
 
Thanks,
--James Evans
 

On Fri, Sep 23, 2011 at 1:27 AM, Nathaniel Smith <nj...@po...> wrote:
> On Thu, Sep 22, 2011 at 7:00 PM, Benjamin Root <ben...@ou...> wrote:
> > On Thursday, September 22, 2011, Tony Yu <ts...@gm...> wrote:
> >> On Thu, Sep 22, 2011 at 5:16 PM, Nathaniel Smith <nj...@po...> 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 <ben...@ou...> 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 even better supported
> than this one. I just think that jet has sufficiently manifest flaws
> that it would be a great favor to science if we could switch to
> *something* better as our default.
>
> -- Nathaniel
>
Continuing with Nathaniel's arguments, I think the article [1] you posted
to the user list [2] recently makes a pretty good argument against using
jet. (Although this isn't really the main point of the article.)
Basically, it suggests that the jet colormap leads to bands of data (i.e.
"incorrectly gives the impression that there are just a few values in the
data"). This reduces visual contrast of data within those bands and
inflates the contrast of data in adjacent bands.
[1] https://www.research.ibm.com/people/l/lloydt/color/color.HTM
[2]
http://old.nabble.com/Visualizing-data-for-scientists-and-engineers-td32852270.html
As a personal pet peeve, it's just not an intuitive color sequence to me.
Sure, I know that the colors in "jet" more-or-less match the color wheel,
but I have to stop and think about the fact that yellow is larger than
green, for example. Plus it's not at all intuitive that green is halfway in
between blue and red (which are the extremes of the colormap).
I'm curious if there are any arguments for using jet/rainbow. I guess
inertia/familiarity would be one. (But even though people are familiar with
it, I doubt most would even know that green is midway between blue and
red.) I guess it also magnifies the intensity range (since it uses 5-ish
distinct colors instead of 2 or 3), but I doubt the noticeable range is
that different than the coolwarm colormap, for example.
Best,
-Tony
P.S. Below is some simple code (mostly ripped from a gallery example) to
compare colormaps. It's pretty easy to the banding effect in the jet plot.
#----
mport numpy as np
import matplotlib.pyplot as plt
X,Y=np.mgrid[-5:5:0.05,-5:5:0.05]
Z=np.sqrt(X**2+Y**2)+np.sin(X**2+Y**2)
for cmap in (plt.cm.jet, plt.cm.coolwarm, plt.cm.BuPu, plt.cm.OrRd,
plt.cm.gray):
 plt.figure()
 plt.imshow(Z, cmap=cmap)
plt.show()

This should now be fixed.
Mike
On 11/17/2011 02:40 AM, Jens Nielsen wrote:
> It works in python3
>
> The python statement in python2.7 (and 2.6) does not support the end argument.
> Adding a "from __future__ import print_function" to the beginning of
> setup.py seems to fix it.
>
> Greetings Jens
>
> On Thu, Nov 17, 2011 at 5:03 AM, Fernando Perez<fpe...@gm...> wrote:
>> (master)longs[matplotlib]> python setup.py
>> File "setup.py", line 281
>> (float(i) / len(filtered) * 100.0), end='\r')
>> ^
>> SyntaxError: invalid syntax
>>
>>
>> Sorry, can't debug it right now...
>>
>> f
>>
>> ------------------------------------------------------------------------------
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I forgot to include the link to the Github compare page in my last message:
http://github.com/ajdawson/matplotlib/compare/master...colorbar-extensions
Andrew
On 16 November 2011 12:19, Andrew Dawson <aj...@gm...> wrote:
> I would like some feedback on a new feature I have developed to control
> the length of colorbar extension triangles. This is a feature I have
> desired for some time, so that the plots I produce with matplotlib can be
> more consistent with those produced from other popular plotting software
> (e.g., IDL). I have added a new keyword argument, extendfrac, to the
> ColorbarBase class. This may be set to a scalar, a two-tuple, the string
> 'auto', or the string 'default'. The behaviour of this keyword depends on
> the setting of the existing spacing keyword argument.
>
> For spacing='uniform' or spacing='proportional':
> extendfrac=None - sets the lengths of both the minimum and maximum
> colorbar extension triangles to 0.05 times the interior colorbar length
> (the existing hard-coded setting).
> extendfrac='default' - same as None.
> extendfrac=FRACTION - sets the lengths of both the minimum and maximum
> colorbar extension triangles to the given fraction of the interior colorbar
> length.
>
> For spacing='uniform':
> extendfrac='auto' - sets the lengths of both the minimum and maximum
> colorbar extension triangles to be the same as the length of the interior
> boxes.
>
> For spacing='proportional':
> extendfrac='auto' - sets the length of the minimum colorbar extension
> triangle to the length of the left/bottom-most interior box, and the length
> of the maximum colorbar extension triangle to the length of the
> right/top-most interior box.
> extendfrac=(FRACTION1, FRACTION2) - as for FRACTION above but the
> minimum and maximum extension triangles may be different lengths.
>
> This is quite a small modification actually, but it does change the API
> for colorbars. I am wondering if this could be included in matplotlib? I
> have set up a fork of matplotlib on Github to implement this feature, if
> anyone thinks it is worth it...
>
> Andrew
>
>

It works in python3
The python statement in python2.7 (and 2.6) does not support the end argument.
Adding a "from __future__ import print_function" to the beginning of
setup.py seems to fix it.
Greetings Jens
On Thu, Nov 17, 2011 at 5:03 AM, Fernando Perez <fpe...@gm...> wrote:
> (master)longs[matplotlib]> python setup.py
> File "setup.py", line 281
>  (float(i) / len(filtered) * 100.0), end='\r')
>                      ^
> SyntaxError: invalid syntax
>
>
> Sorry, can't debug it right now...
>
> f
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

(master)longs[matplotlib]> python setup.py
 File "setup.py", line 281
 (float(i) / len(filtered) * 100.0), end='\r')
 ^
SyntaxError: invalid syntax
Sorry, can't debug it right now...
f