matplotlib-devel Mailing List for matplotlib

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