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