[matplotlib-devel] Getting started?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Howdy, I've been a matplotlib user for some time, and I've been thinking about contributing to the project. I poked around in the github issues list, particularly the low-hanging fruit tag (https://github.com/matplotlib/matplotlib/labels/low%20hanging%20fruit), but nothing immediately struck my fancy, and I don't want to step on any toes / reduplicate any significant efforts, so I thought I'd throw it out there to the devs - do you guys have anything to point me towards that I could get started and at least get into the swing of things? Thanks, Paul -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJT+kOXAAoJEM1U/OPZZL77bGkP/Rt5MXXvLJlkjgbAtlyHdriO F2s3CKG6WLeU9eQJf/RloJWHr21lGW829aaNz+jG//N7f3HJXURhSNJFWF0vlWQJ dgsAptVr3v/5Ckhb1AkrmBFqb2uSfw0RXzMgSi+g7P/MicHYpXr2k8JE+BWmeZTq iO2cEFl2YWA+To3ZWKaOwdxxuj615ccq3oZyeEpdU1YCO7pPjW7PCy1Jhb2Rw/yD V8IyRsm2Tgvr3AZwijPzJnsGPFLxRP8gkvi1M2iW+gvRC+NYA5PsAL++uLgeHNTp Y1RCp5R4X6SuLwO0IkNpxM5ffHgPQimjvYN1/AweMG2NiuAROkSOnbhzHCfQWlN5 /z1TSnU33+anldeK89V1E2Nsp7mecAVbKqUTXS4NSomWn325wFEr+Uc4lSYdEd6n t4Ce8MIYx9qSCHE0BrN2RsIT5Q6pMhLC8sf/7s26ZeQELxVUzAxU7WQcAsovtB64 GwVAdozVpIepPUe+Y+2MHH1JqohsUENDjPUtxbYlBmBgEIoxFqWsTBG5GkFtSnOu AqSF4XoAt9IOxXvuIpcy6UADnoJ+qpVb4CY1gTByCONQCDOnE+41BomV4vnVy7jL SgkenaCKA2VBwatAda0DlGZDWYdc5hmUiGUFyjTh4Q6LRUIJyuvy7gneadJiAWZw fm74noPQwH9RWtu1+QBi =ehqZ -END PGP SIGNATURE- -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Date overhaul?
Thanks for the responses. If no one minds, I'm take a look at how to best implement datetime64 this weekend and the degree to which it might be useful, then maybe I can start an MEP for it. I agree with Chris's sentiment that it's likely not a bad idea to start on it now, since there will almost certainly be a significant lag in raising the Numpy dependency version anyway, so if it can be implemented in some reasonable way now, we might as well, otherwise it may be some years before we get to it. Let's say we want a time zone aware date time converter. The basic goal is to convert some input type (datetime) to the MPL internal type (float days past Jan 0, 0001). We also need to tell MPL how to format the axis (default formatter, locator, limits, label). - The convert() method takes the input type (datetime) and the xunits (or yunits) keyword argument and converts it to the MPL type. The axis input can be used to change the results depending on the plot type (polar plots always require radians for example). For the TZ converter, would take the input value (datetime), convert it to the time zone requested by the units input, then convert that to a float using dates.date2num(). Note that the input can be a sequence or a single value so the converter has to handle both cases. - The axisinfo() method is used to provide the default axis locator and formatter objects when the user creates a plot with this type. The axis input is useful here to handle the result differently for a polar plot. For the TZ converter, this would be exactly the same as the web docs - return the default locator and formatter for dates. Most of the time this method can just return standard MPL formatters and locators (for either dates or numbers). - The default_units() method provides a default value for the xunits or yunits keyword argument if one isn't specified. The default in this case might be UTC. Hope that helps some, if you have more specific questions feel free to send them to me. Ted -- *From:* Thomas Caswell [tcasw...@gmail.com] *Sent:* Thursday, January 08, 2015 11:14 AM *To:* Drain, Theodore R (392P); matplotlib-devel@lists.sourceforge.net *Subject:* Re: [matplotlib-devel] Date overhaul? I was hoping for something a bit more extensive of the intenals. I have tried to understand the units code a couple of times now and always hit a brick wall. On Thu Jan 08 2015 at 2:07:02 PM Drain, Theodore R (392P) theodore.r.dr...@jpl.nasa.gov wrote: Google search matplotlib units yields: http://matplotlib.org/api/units_api.html So it sounds like the update is to make MPL's internal date system higher resolution which would be great. We would just need to update our converters to convert to that format instead of the current floating point format. Our custom classes are not public (and can't really be made public) but they aren't very complicated so we can certainly talk about the implementation if that helps. -- *From:* Thomas Caswell [tcasw...@gmail.com] *Sent:* Thursday, January 08, 2015 10:57 AM *To:* Drain, Theodore R (392P); matplotlib-devel@lists.sourceforge.net *Subject:* Re: [matplotlib-devel] Date overhaul? One of the other driving factors to over-haul the default date handling is that floats do not have enough precision to deal with nano-second resolution data (which is what I think drove pandas to use datetime64). It sounds like the correct solution Is the unit framework documented anywhere and are those custom classes public? Tom On Thu Jan 08 2015 at 12:59:17 PM Drain, Theodore R (392P) theodore.r.dr...@jpl.nasa.gov wrote: I agree w/ the original poster that it would help to have a MEP to clearly define what the goals of the overhaul are Something else to keep in mind: we at least don't normally plot dates in earth based time systems. ~10 years ago we contracted with John Hunter to add the arbitrary unit system to MPL. This allows users to plot in their own data types and define a converter to handle the conversion to MPL types and labeling. We have our own date time like class which handles relativistic time scales (TDB, TT, TAI, GPS, Mars time, etc) at extremely high precision. We register a unit converter w/ MPL which allows our users to plot these types natively and use the xunits keyword (or yunits) to control how the plot looks. So we can do this: plot( x, y, xunits=GPS, yunits=km/s ) plot( x, y, xunits=PST, yunits=mph ) It would also be pretty easy to add a time zone aware unit converter with the existing MPL code which would allow you to do things w/ datetime like this: plot( x, y, xunits=UTC+8 ) plot( x, y, xunits=EST ) I guess the point of this is to remind folks that not everyone plots dates in time zone based systems... Ted -- *From:* Chris Barker [chris.bar...@noaa.gov] *Sent:* Thursday, January 08,
[matplotlib-devel] Date overhaul?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Recently I took a crack at fixing some of the bugs in dates.py, and it seems like there's been some talk of overhauling how dates are handled. I don't see an MEP for that, so I'm wondering if anyone can give me some more details about what the impetus was for overhauling date handling and just in general what needs to be done. I wouldn't mind taking a crack at the date handling stuff while it's still fresh in my mind. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUramTAAoJEM1U/OPZZL77t4kP/1Gj2roe2ZzGJF3u2L71p+TD gK63EKcoqLnjCs080nDfsERSSN8tG0OQvCLNcxQBV7p22rd6lMdn5MvHxYKuZVEE rD2+92f45Ql5gAw+Q8rOJKcIt/fH0MHDO5TPCJl1Mjcp1ZsQk2DO/qdOmPWlgjbg H++WWW6kXbJpBBWelNzKCR6HIhFfcEtBCNoc0MDclLm7qlxR6vGoFNBWeNptEjQ+ 4q6ZASMfIxkRKI1KpiYW+3ezMGCyw9hd/aJvj9iSti5BXL0CZHfUg1Rt7gYpsHU4 I0gSFzSIOTQb8TjKpyeD3yjxmllxgaXxdUm5i3Snp0+Cv7yWYYwAArTm/Aq6h2+z X4qaXNxys5BKqOa+oCiYLdlE/GHA+REvw4+VFoL/oOp5wVlGjaJY2jwhjhJnjvzT f4tvampwFfl0KPAm+eoqkMhqt/jjZetKwXXK+DTETO9o80yvTaM28nd1LYLD9ywN QDfVbCzrg01cQQpWVT5JtzeHoJ/4du8I+cC0VWzMM159X44GfYbtV1QUbRgdiTPh TUwDJi48Zg3eVI45L95r1eC4Q8VFzkTf59m1wve7xuVkOgNZq15BriQC7TQWWKH6 RXjTYD09PRmTyZg4YeshqLHApyAXzFYtSckHDiEFy6BPTYHsgPQcbX0U1igZUsrA 9rHjCWUZK33cLbla2CpG =RJbm -END PGP SIGNATURE- -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] RFC: candidates for a new default colormap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm also in the B A C camp, FWIW. I agree with OceanWolf in that B looks most professional. It looks much crisper than the others as well. On 6/3/2015 08:50, Tony Yu wrote: It doesn't sound like this is going to be decided by email votes, but just so the arguments for C don't dominate, my vote would be: B A C C has the least perceptual range (that's quantifiable, right?). Also, I find A and B much more aesthetically pleasing (that's obviously debatable). In particular, the yellows and blues in C have a slight visual vibration. Actually, if you google visual vibration, one of the first hits is a yellow and violet image https://web.njit.edu/~mmp57/visual%20vibration.jpg. B would have this to a certain extent, but it's much more problematic if those colors are at the limits of the colormap range. It looks like A wouldn't have this problem at all since it's white point has a very muted yellow tone, so maybe I'll switch my vote to A. (Personally, it's a toss up between the two; anything but C, if I haven't made myself clear ;) Thanks to Nathaniel and Stéfan for putting this together! Hopefully jet can be banished soon :) -Tony On Wed, Jun 3, 2015 at 5:20 AM, OceanWolf juichenieder-n...@yahoo.co.uk mailto:juichenieder-n...@yahoo.co.uk wrote: Personally, just looking at the images I think B looks more professional, the others look faded. With A and B I see more of contrast in the core of the radial image (though that might arise from a combination of my monitor/eyes, though I usually do quite well in colour perception tests). I think we really need to see a variety of real examples before we make a decision though, both in application a.k.a different type of datasets, including ones with NaNs; and different graph types, the 3d example will make for a good test as we get the same information twice, from height and colour, which gives us a reference for comparison. With the NaNs Andreas, why did you pick B over C? My eyes see B going to white as well, only C as far as I can tell does not go to white. Looking forward to having a play later :). I wonder what Parula-based colormap would look like if we were to make it linear... one other thing, mpl currently doesn't select good bounds with pure horizontal/vertical lines, making it very difficult (at least for me) to see the perceptual deltas, zoomed in to option_c the line gets completely hidden by the axes... On 03/06/15 09:04, Andreas Hilboll wrote: On 03.06.2015 08:54, Juan Nunez-Iglesias wrote: You can always use green for NaN with any of these maps... In grayscale that then wouldn't be distinguishable at all ... On Wed, Jun 3, 2015 at 4:30 PM, Andreas Hilboll li...@hilboll.de mailto:li...@hilboll.de mailto:li...@hilboll.de mailto:li...@hilboll.de wrote: I particularly like that A ends on the white end of the spectrum That's exactly why I don't like A that much. In many plots, I need a color for NaN results. This color should not fall within the normal range of the colormap. In case of B and C, it would be possible to use white as NaN color. When using white for NaN in A, it would just look like large values. So I guess I'm voting B C A -- Andreas. -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net mailto:Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net mailto:Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJVbwc8AAoJEM1U/OPZZL77c5oP/1KSJloy7ZBVyCOb2Dv2w7fM +cQAHlSBgzff+/hYf4/vDjvo0MOomP3xq7PwjA5Jeg3eln+Y9wDwarCDWZK5+Kh7 uDil3Rdtx+yC3vUqrICHQkh6Y6b5xiv6eTAV06UA2sUM4TRnXIuLSCCnR/2ntbiY NGyl7/NPFeYmFJHtGnMmNLhVIZV5a01oc7J6xb/CqQhuYzzi3NwN2tuS27+ouG2G dOXWXn/f2DdHYONXyjFHQG5NeVxm50r27wZkdk9xhfmo7FaI2939xZQfbeFqUdAO qspHwddr0PGIQCU8nr/CCzQ93fMPkd3cM3e4Sn1Ulq2yDuQXLIISBkA7ufi45yPt q1pmFiv9La6vbZZzLLJ47c90fQ1NAe3Jdj4z1x6H4ZhZe8I2zgBhOO4m8meh+gU6
