Re: [matplotlib-devel] RFC: candidates for a new default colormap
On Wed, Jun 3, 2015 at 3:46 AM, Nathaniel Smith n...@pobox.com wrote: Hi all, As was hinted at in a previous thread, Stéfan van der Walt and I have been using some Fancy Color Technology to attempt to design a new colormap intended to become matplotlib's new default. (Down with jet!) Unfortunately, while our Fancy Color Technology includes a computational model of perceptual distance, it does not include a computational model of aesthetics. So this is where you come in. We've put up three reasonable candidates at: https://bids.github.io/colormap/ (along with some well-known colormaps for comparison), and we'd like your feedback. They are all optimal on all of the objective criteria we know how to measure. What we need judgements on is which one you like best, both aesthetically and as a way of visualizing data. (There are some sample plots to look at there, plus you can download them and play with them on your own data if you want.) We especially value input from anyone with anomalous color vision. There are some simulations there, but computational models are inherently limited here. (It's difficult to ask someone with colorblindness does this look to you, the same way this other picture looks to me?) -n I assume these are all going to be available as colormaps? I prefer C, the others seem to dark. Having too much black doesn't strike me as very aesthetically pleasing. So I would say C B A -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
On Feb 19, 2015 1:39 AM, Nathaniel Smith n...@pobox.com wrote: On Feb 16, 2015 3:39 PM, Eric Firing efir...@hawaii.edu wrote: On 2015/02/16 1:29 PM, Michael Waskom wrote: Nathaniel's January 9 message in that thread (can't figure out how to link to it in the archives) had a suggestion that I thought was very promising, to do something similar to Parula but rotate around the hue circle the other direction so that the hues would go blue - purple - red - yellow. I don't think we've seen an example of exactly what it would look like, but I reckon it would be similar to the middle colormap here http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png (from the elegant figures block series linked above), which I've always found quite attractive. Certainly it can be considered--but we have to have a real implementation. While I hate to promise vaporware, I actually was planning to have a go at implementing such a colormap in the next few weeks, based on optimizing the same set of parameters that viscm visualizes... FWIW. Are we planning to make other default appearance changes at the same time? The idea of changing the color cycle and/or dot-dash cycle has already come up in this thread, and this earlier thread proposed several more good ideas [1]: http://thread.gmane.org/gmane.comp.python.matplotlib.devel/13128/focus=13166 If the goal is still to put all the appearance-related changes in a single release (to simplify changes to downstream unit tests), but nobody has stepped up to make changes except to the colors, might it be possible to just adopt the default seaborn style (except for colors, of course)? If anybody is strongly motivated to make changes they can, but if nobody does there would still be a good, modern, pleasant-looking style used by default. -- 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] Release planning/milestones
I wasn't referring to just the default colors, but the default style in general. Things like background, line thickness, padding, ticks, etc. I thought that there was agreement that the default matplotlib style is not optimal, and that the point of the 2.0 release was to put all the stylistic changes in one release so people don't have to keep changing their unit tests. On Feb 8, 2015 11:04 PM, Thomas Caswell tcasw...@gmail.com wrote: To overhauling all of the default colors, I think that is still in the cards, but some one who is not me needs to drive that. The goal of pulling pyplot out of backend_bases is exactly that, to be able to do everything using the OO interface in a convenient way. Tom On Sun Feb 08 2015 at 4:50:51 PM Todd toddr...@gmail.com wrote: On Feb 8, 2015 1:13 AM, Thomas Caswell tcasw...@gmail.com wrote: Hey all, To start with, the 2.0 release is pending a choice of new default color map. I think that when we pick that we should cut 2.0 off of the last release and then the next minor release turns into 2.1. If we want to do other breaking changes we will just do a 3.0 when that happens. It makes sense to me to bundle default color changes as one set of breaking changes and code API changes as another. I thought there was going to be a complete overhaul of the default theme? Has that idea been abandoned? - making OO interface easier to use interactively (if interactive, auto-redraw at sensible time) - pull the pyplot state machine out of backend_bases and expose the figure_manager classes Do either of these mean that it will be possible to use the OO interface without needing to go through pyplot? -- 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 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Release planning/milestones
On Feb 8, 2015 1:13 AM, Thomas Caswell tcasw...@gmail.com wrote: Hey all, To start with, the 2.0 release is pending a choice of new default color map. I think that when we pick that we should cut 2.0 off of the last release and then the next minor release turns into 2.1. If we want to do other breaking changes we will just do a 3.0 when that happens. It makes sense to me to bundle default color changes as one set of breaking changes and code API changes as another. I thought there was going to be a complete overhaul of the default theme? Has that idea been abandoned? - making OO interface easier to use interactively (if interactive, auto-redraw at sensible time) - pull the pyplot state machine out of backend_bases and expose the figure_manager classes Do either of these mean that it will be possible to use the OO interface without needing to go through pyplot? -- 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] Better defaults all around?
On Nov 26, 2014 10:04 PM, Nathaniel Smith n...@pobox.com wrote: On Wed, Nov 26, 2014 at 9:30 AM, Todd toddr...@gmail.com wrote: On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith n...@pobox.com wrote: - Default line colors: The rgbcmyk color cycle for line plots doesn't appear to be based on any real theory about visualization -- it's just the corners of the RGB color cube, which is a highly perceptually non-uniform space. The resulting lines aren't terribly high contrast against the default white background, and the different colors have varying luminance that makes some lines pop out more than others. Seaborn's default is to use a nice isoluminant variant on matplotlib's default: http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html ggplot2 uses isoluminant colors with maximally-separated hues, which also works well. E.g.: http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png About this, I am not expert so forgive me if this is nonsensical. However, it would seem to me that these requirements are basically the same as the requirements for the new default colormap that prompted this whole discussion. So, rather than create two inconsistent set of colors that accomplish similar goals, might it be better to instead use the default colormap for the line colors? You could pick N equally-spaced colors from the colormap and use those as the line colors. The main differences in requirements are: - for the color cycle, you want isoluminant colors, to avoid the issue where one line is glaring bright red and one is barely-visible-grey. For general-purpose 2d colormaps, though, you almost always want the luminance to vary to help distinguish colors from each other. If you used isoluminance colors for the lines, wouldn't that mean a plot printed in grayscale would have all lines be the same shade of gray? -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pyplot-OO convergence
On Sun, Sep 28, 2014 at 7:52 PM, Eric Firing efir...@hawaii.edu wrote: Regarding Matlab: it is justly popular for many reasons. It is relatively easy to learn both by design and because of its consistent high-quality documentation. Matplotlib's success has resulted in large measure from its pyplot layer, which can shield learners and users from mpl's complexity, which allows learners to build on their Matlab knowledge, and which is particularly well suited to quick interactive data exploration. The problem with the Matlab/pyplot approach is that it doesn't scale well, so we see a chorus of advice along the lines of don't use pyplot except for subplots() and show(); use the nice, explicit OO interface for everything else. But at present, this doesn't work well, because the OO approach is not interactive enough, and using the getters and setters is clumsy when typing at the console--in demonstrating, teaching, learning, and exploring interactively, every keystroke counts! Matlab is actually slowly trying to transition to an OO-style interface of their own. It has taken a LONG time, though. -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP13 - python containers
I would suggest create a new branch, though. You can create a new branch from the old one, then make your changes there. That way if you mess up something you still have the original to fall back on. On Thu, Jul 31, 2014 at 5:15 PM, Thomas Caswell tcasw...@gmail.com wrote: Git lets you re-write history pretty extensively. If you use a tool on top of git (I use magit in emacs) you can selectively commit hunks one or two at a time. At a minimum split it up by file. You are going to have to do some force-pushing anyway. Making the PRs as small as reasonable makes reviewing much easier. It makes it possible to go through the entire PR in one sitting and it allows the un-controversial stuff to be merged as quickly as possible without being held up by other parts. The longer large PRs hang around the greater the chance they will accumulate conflicts with other PRs and require a re-base (re-basing a 500+ line diff is _incredibly_ painful). Tom On Thu, Jul 31, 2014 at 11:09 AM, jamesramm jamessr...@gmail.com wrote: Thomas Caswell wrote I only took a brief look at that branch, but two comments 1) can you clean up your git history, you are adding 20k new lines (of mostly freetype and random files that should not be tracked) 2) can you split the propertify work up into chunks that are easier to review? Yes. This is mostly my inability to use git (I've not particular used it before). I'll have to look up how to clean the history and 'unversion' the unneeded freetype stuff. As it is already committed to my branch, im not sure the existing stuff can be split into chunks? But I will make issues and split up the next lumps of work. I'll post back when it is (hopefully) cleaner -- View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP13-python-containers-tp40248p43732.html Sent from the matplotlib - devel mailing list archive at Nabble.com. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Thomas Caswell tcasw...@gmail.com -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] unused variables
On Mar 6, 2014 10:24 PM, Skip Montanaro s...@pobox.com wrote: On Thu, Mar 6, 2014 at 3:13 PM, Nelle Varoquaux nelle.varoqu...@gmail.com wrote: If I need to understand what exactly os.stat returns, I just read the documentation, and not rely on some possibly misleading variable names. Despite our wish that it wasn't so, it is likely that there is far more undocumented than documented code out in the wild, or behind firewalls where we can't see it. I just used os.stat as an example of a well-known function that returns multiple values. (Precisely, so people wouldn't have to run to the documentation or that I would have to provide a more-fleshed-out example.) In my experience, there's no real need to be intentionally obscure by not giving a variable a meaningful, whether or not you intend/expect to use it. Besides, open source code can serve as a living example of good coding practices. Might as well do our best in that regard. Just sayin'... Skip Whether it is necessarily the optimal choice, I think there is something to be said for following established conventions. Besides the fact that IDEs complain if you don't, it makes it easier for outside contributors to understand what it's going on. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)
On Oct 24, 2013 8:40 PM, Chris Barker chris.bar...@noaa.gov wrote: On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom md...@stsci.edu wrote: Here are the notes with action items from the meeting: thanks for posting that. I see: pylab - should it stay or should it go? Comment from the peanut gallery: Go. I agree, but that leads to another question: go where? Some of the stuff there is clearly redundant and should be removed entirely. Others I think are functionality that should be merged into numpy, although whether they would agree I don't know. Others are useful but I don't know exactly where they could end up. I think we need to go through on a case-by-case basis and figure out what to do with each class and function. I think it would probably be good to do something similar with cbook. Both are dumping grounds for largely unrelated functions. At the very least they should be organized into modules by their purpose, but I do think some should be dropped or upstreamed. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)
I think one thing that contributes a lot to the API issues is the inconsistency between pyplot API and the OO API. There isn't any reason the APIs need to be so different. To continue with this example, pyplot.subplot and Figure.add_subplot do basically the same thing, but they have different names. In practice pyplot.subplot essentially acts as a wrapper for gcf().add_subplot, but it isn't exactly the same internally, it has some checks that are not present in Figure.add_subplot but really should be. On the other hand, pyplot.subplots doesn't exist at all in Figure, all the functionality is implemented in pyplot. So the idea would be to have essentially all of the pyplot functions just be wrappers for methods from other classes, using the same name and same call signature (minus self). All of the actual functionality would be implemented in the methods, the pyplot functions should not have any logic or tests. So pyplot.subplot would be just be a wrapper for gcf().subplot, pyplot.subplots would just be a wrapper for gcf().subplots, while pyplot.plot would just be a wrapper for gcf().gca().plot. This will make it easy to transition between the two, learning to use the OO interface would just involve learning what object the pyplot function is targeting (this should be in the pyplot function docstring). On Fri, Oct 25, 2013 at 7:21 PM, Thomas A Caswell tcasw...@uchicago.eduwrote: There needs to be layers to the interface. At the bottom there is super general stuff that will cover (we hope) 100% of use cases. However, the cost is a very verbose interface with lots of knobs. To cope with this there are higher level function which can deal with 90% of the use cases and do so by hiding some of the knobs (compare making a 3x3 grid `subplots(3, 3)` with using `GridSpec` to figuring out where the axes edges should go and using `add_subplot([t, l, w, h])` ). I want to make an analogy to projecting from a higher dimensional parameter space to a lower one. The 'proper' api to use is the simplest one that achieves your goal. If you just need a grid of evenly spaced equal size axes use `subplots`, if you need a grid but with some axes that span columns/rows use `GridSpec`, if you need 5 axes that partially overlap in the shape of your school logo, use `add_subplot`. The point of the high-level APIs is to be easy to use. If that means matching the MATLAB api to make it easier for people to switch, then fine. I am sympathetic to the notion that the state-machine interface is confusing (because it maintains hidden state), but it is in fact very convenient. On Fri, Oct 25, 2013 at 10:26 AM, Daniele Nicolodi dani...@grinta.netwrote: On 25/10/2013 15:34, Benjamin Root wrote: This has already been done. We have the GridSpec API that everything else maps to, for compatibility. But most people still like add_subplot() and subplots() for some odd reason... I think the primary issue is one of documentation, and we are currently in the process of upgrading that. We always welcome contributions to that effort! Hello Benjamin, thanks for your comments. I'm aware of the solutions you propose, but I maintain that the status quo is confusing for new users. The fact that there are multiple ways of doing the same thing, through apparently unrelated interfaces makes the API more difficult to learn and less discoverable that it needs to be. This is probably a conseqence of the organic growth of the library with time. I agree that the primary issue is the documentation, but at the root of that I also feel there is the lack of well established best practices for the use of Matplotlib. For example you write that people still like add_subplot() and subplots() for odd reasons, which are the methods others in the lists pointed to. What would be the proper API to use in your opinion? I believe convergence on best practices is paramount to the update of the documentation. I also don't really buy the argument that it is desirable to keep and promote APIs that try to emulate the Matlab interface. Matplotlib is different enough to make a 1:1 translation difficult and the Matlab design is anyhow broken, IMHO. Best, Daniele PS: with a new job also came the possibility to finally drop Matlab and embrace Python as the main data analysis tool. This means that I can dedicate some (at the moment very few) spare cycles to contribute to Matplotlib. I would be happy to do so! -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list
Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)
I think another problem is having pyplot and axes as dumping grounds for all plot types. This probably made sense back when there were only a few types of plots, but now there is a massive number of them. They all end up in one large class with one large documentation page, making it very hard to find exactly what you are looking for. In order to make the plots really useful, I definitely think a reorganization is in order. I think matplotlib needs an general module, perhaps plots, that contains sub-modules for different types of plots (like bar plots), and those sub-modules contain functions, all of which have an axes object as their first argument. These could still be attached to axes as methods at least as a transition, but it would leave the axes class with methods that really have to do with axes, and not plotting per se. This would also make it possible to put code shared between plot types with those plot types in their module. On Thu, Oct 24, 2013 at 8:39 PM, Chris Barker chris.bar...@noaa.gov wrote: On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom md...@stsci.edu wrote: Here are the notes with action items from the meeting: thanks for posting that. I see: pylab - should it stay or should it go? Comment from the peanut gallery: Go. But beyond that, matplotlib.pyplot is a big mess of both the matlab-style state-machine current figure, current axis stuff, and what you need to do (at least reasonably on the command line) OO interface. This makes it really hard to teach to newbies -- I just did this last night, and made a point to use tutorials that emphasize the OO interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm sure others that helped put the materials together that I stole from...). However, there were still a number of examples in there that just called plot() or whatever, and even if there were not, the namespace is really cluttered with stuff! Anyone like the idea of an matplotlib.ooplot namespace that would have just what you need to use the oo style? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
On Fri, Oct 25, 2013 at 3:06 PM, Pierre Haessig pierre.haes...@crans.orgwrote: Hi, Le 21/10/2013 15:58, Todd a écrit : 2) Should there be two separate functions for these two, or just one function, with a switch argument `unwrap` ? (I guess it would be True by default) I originally was going to do that, but decided against it. The problem is with specgram. Here, I thought it would be needlessly complicated to add an unwrap parameter that is only useful for one mode. To make it obvious to users, I wanted to keep specgram as similar as possible to the other plot types, and that involved keeping the parameter. Further, this approach is simpler to code and easier to maintain. Having to deal with the unwrap parameter would have been more difficult to program. Dealing with both an unwrap parameter in some cases and a separate mode in others would have been even more complicated. Further, _spectral_helper and specgram already have a huge number of arguments. This way I was able to get away with just adding one new argument rather than two. You've convinced me. I didn't have the big picture of your PR when writing my previous messages. I like the approach you took for specgram, which put magnitude, phase, angle on the same level. This indeed reduce the number of keywords. Coming back to the readability, what do you think of replacing phase, angle by unwrapped phase, phase. Beyond readability, it also emphasizes for the reader the idea of postprocessing to get the unwrapped phase, i.e. a something that can have it's issue. I considering that. The problem is that people have to type all that. magnitude_spectrum is long enough as it is, but unwrapped_phase_spectrum is just a huge function name (24 characters). I wanted something more concise. I think the documentation makes it clear enough. I don't think we lose that much, the users only have to read the docstring once, and they will avoid a lot of annoyance typing out such a huge function name over and over. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
On Fri, Oct 25, 2013 at 2:57 PM, Pierre Haessig pierre.haes...@crans.orgwrote: Hello, Now that that PR #2522 is merged, I don't know how much futher commenting is useful, but I think there are two API details that I feel could be better : 1) API dissymetry The new pyplot/axes API is now: * 1 function *spectgram* now uses a mode argument to tune this behavior : *mode*: [ 'default' | 'psd' | 'magnitude' | 'angle' | 'phase' ] What sort of spectrum to use. Default is 'psd'. which takes the power spectral density. 'complex' returns the complex-valued frequency spectrum. 'magnitude' returns the magnitude spectrum. 'angle' returns the phase spectrum without unwrapping. 'phase' returns the phase spectrum with unwrapping. * 3 new functions *phase_spectrum, angle_spectrum, magnitude_spectrum*which complement the exising psd/csd - I think this contributes to overcrowding axes/pyplot API. I like much better what is done with specgram so I would propose to add just one new function, for example *spectrum*(...mode='magnitude/angle/phase'). Using the same *mode *keyword as for specgram would increase the coherence of the API Although it may reduce the number of functions, I don't think it increases the coherence of the API. Quite the opposite, in fact. Besides the inconsistency with psd and csd, I think having the plot types separate makes sense because they really are not the same plots, they plot different things in different ways and different units and using parameters. Specgram, on the other hand, plots things in the same way with similar units and mostly the same paramaters. So I think specgram plots group together much more cleanly than the other spectrum-related plots. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
On Fri, Oct 25, 2013 at 2:34 PM, Pierre Haessig pierre.haes...@crans.orgwrote: Hi, Le 22/10/2013 19:14, Todd a écrit : Thanks for the feedback. I agree that your documentation does make clear the distinction between phase and angle and that it has a consistency. I just feel that this distinction does not exist outside ... But beyond this question of phase vs. angle, I must say I don't see that big a use case for phase/angle spectrums[*] (as opposed to magnitude which are much used). I personally use phase and angle spectrums a huge amount. In signal processing it is extremely important. It is a critical component in acoustics. It is also used a lot to separate out signals that have been mixed together. Knowing the phases of signals can also be very important in certain optics applications and for radio signals and RADAR. Changes in the phase spectrum over time (like you would get from a phase spectrogram) is important for doppler analysis both with optical and acoustic signals. Also, from an educational perspective, anyone taking a digital signal processing course will need to produce magnitude/phase plots, probably both with and without wrapping (since any decent digital signal processing course will teach you about the pitfalls that occur due to phase wrapping). So this will make matplotlib much more useful for such courses. Also, in many cases, spectrum is synonymous with spectral density, which implies magnitude. In the end I wonder whether the notion of phase even makes sense for a spectrogram ? Yes, particularly electrical engineering. But there are many other fields where spectral density is rarely used, and where more ordinary magnitude and phase plots are the norm, as I explained in the previous paragraphs. Thanks for dealing with my ignorance. It's true that I have a biased view on these frequency functions, because I mostly deal with random signals these days. In fact I'd like to understand a bit more how phase spectorgram works. Since the signal must be cut into chunks to make the plot along time, how is the phase computations synchronised, that is, how does it use a common time reference. (because I would imagine that otherwise the phase would make jumps between each window frame). Do you have a pointer for how this is solved ? (or is this problem just non-existing?). best, Pierre This could certainly be an issue, and no it isn't dealt with (nor am I aware of a way it could be dealt with). There are really several different questions here. First, is it worthwhile having 1-D phase and angle spectrums (phase_spectrum and angle_spectrum). I would argue that this is definitely the case, as I already explained. Second, is it worthwhile adding these to specgram? Frankly. probably not. They have some robustness issues. Third, given that implementing phase_spectrum and angle_spectrum automatically gets us phase and angle specgrams, and that it would actually take more code to turn them off than to leave them in, is there any reason to explicitly disable these plot type? I would say no. It is a tool. It may not be useful to very many people, and the people who do use it may need to be careful to use it properly. But since we get it for free anyway, I don't see a good reason to put in the extra code to remove functionality that may be useful to someone but hurts no one. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)
Was anyone looking at the questions? I posted a bunch of questions but nobody seemed to notice them. On Thu, Oct 24, 2013 at 3:41 PM, Michael Droettboom md...@stsci.edu wrote: Just a reminder, we are having a general matplotlib development hangout today. Everyone that responded to the Doodle poll from a few weeks ago will get an invite, along with Matthew Terry and Matthew Brett if they can make it to discuss their work with testing and builds. We have a few extra spots, so let me know if you'd like an invite (first come, first served). I'll post a public URL to watch along once it begins as well. Mike -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)
Here are the questions I asked during the hangouts session (paraphrased): - Regarding continuous integration: Has looked into OBS? (open build server, https://build.opensuse.org/) It can be installed on a local machine or server, supports automatically creating and deleting fresh images with each build, and supposedly works with osX as well as Linux although I haven't tested it (it does need a Mac OsX VM). - Regarding bug handling: It might be possible to do something with this with Google Code-in ( https://developers.google.com/open-source/gci/), although I am not 100% sure this would be acceptable there. Another possibility would be to allow volunteer triagers who may not be developers but can at least handle basic stuff like finding duplicates and following up with the reporters of old bugs. - Regarding embedding: Perhaps there could be a generic figure widget for each backend. The widget would automatically handle all the backend-specific stuff necessary to create a figure object and display it in the widget (including resizing and such). It would provide access to the low-level backend-specific parts to make it possible to subclass it or change the details of how it works. The figure windows would have this widget as their central widget, and would probably access it using these low-level components. However, for basic usage each widget would also have a figure attribute, which would contain a single generic figure object. Basic users who just want to embed a regular plot could access that figure object and use it in the normal way. These could probably all be accessed from a single module, although they probably would all live in their own backend-specific modules. It wouldn't allow people to use pyplot, but if this was the documented way to do embedding and the documentation made it clear you needed to use the OO interface when embedding I think it would greatly reduce the amount of trouble people have. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Problem compiling master
As of last night, I can no longer compile master. I get the following error: building 'matplotlib.ttconv' extension creating build/temp.linux-x86_64-2.7/extern/ttconv gcc -pthread -fno-strict-aliasing -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ttconv_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.7 -c src/_ttconv.cpp -o build/temp.linux-x86_64-2.7/src/_ttconv.o src/_ttconv.cpp:12:27: fatal error: ttconv/pprdrv.h: No such file or directory compilation terminated. error: command 'gcc' failed with exit status 1 This happens even when building from a newly-cloned directory. I am building on Linux (openSUSE 12.3). There shouldn't be ttconv/pprdrv.h, it has been moved to extern/ttconv/pprdrv.h. I can't figure out why it is still looking there. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem compiling master
On Tue, Oct 22, 2013 at 9:30 AM, Ian Thomas ianthoma...@gmail.com wrote:
On 22 October 2013 07:53, Todd toddr...@gmail.com wrote:
As of last night, I can no longer compile master. I get the following
error:
building 'matplotlib.ttconv' extension
creating build/temp.linux-x86_64-2.7/extern/ttconv
gcc -pthread -fno-strict-aliasing -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -fPIC
-DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ttconv_ARRAY_API
-DPYCXX_ISO_CPP_LIB=1
-I/usr/lib64/python2.7/site-packages/numpy/core/include
-I/usr/local/include -I/usr/include -I. -I/usr/include/python2.7 -c
src/_ttconv.cpp -o build/temp.linux-x86_64-2.7/src/_ttconv.o
src/_ttconv.cpp:12:27: fatal error: ttconv/pprdrv.h: No such file or
directory
compilation terminated.
error: command 'gcc' failed with exit status 1
This happens even when building from a newly-cloned directory. I am
building on Linux (openSUSE 12.3). There shouldn't be ttconv/pprdrv.h, it
has been moved to extern/ttconv/pprdrv.h. I can't figure out why it is
still looking there.
Todd,
This is my fault, I would expect to see a '-Iextern' in the compilation
options. Usually this is obtained from CXX().add_flags(), but obviously
not in your case which implies that your CXX is available via pkg-config.
I think either of the following changes will fix the problem:
1) Either adding the following after line 947 in setupext.py:
ext.include_dirs.append('extern')
2) Or changing line 12 of src/_ttconv.cpp from
#include ttconv/pprdrv.h
to
#include extern/ttconv/pprdrv.h
I'll need to think about which is the better solution. If you can let me
know which of these fix the problem, I'll have a PR out later today.
Ian
Thanks, both seem to work.
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
On Sun, Oct 20, 2013 at 9:45 AM, Todd toddr...@gmail.com wrote: Hello, I submitted a pull request #2522 [1]. It includes support for more basic spectrum plots like magnitude and phase spectrums. These are extremely commonly used in signal processing, acoustics, and many other fields, but are also very important for educational usage since pretty much anyone going through one of several engineering degrees like electrical engineering has to learn these types of plots. I have heard a number of colleagues complaining about the lack of these plots in matlab. It has been up for 5 days, but I haven't received any comments on its content or structure. I understand that it is a pretty substantial patch, but I think the features are very useful. I am also a bit concerned that patches covering the same code might be submitted and accepted while I am waiting for this, since such changes would be hard to merge into my branch. So does anyone have any thoughts on the patch? [1] https://github.com/matplotlib/matplotlib/pull/2522 I do have one question about my pull request. Currently, both axes.psd and axes.csd return the same thing as mlab.psd and mlab.csd, namely the spectrum and frequency points. They do NOT return the line object that was plotted. This is different than specgram, which returns the AxesImage object that was plotted in addition to the mlab.specgram return values. I think having access to the line object is important, so axes.magnitude_spectrum, axes.angle_spectrum, and axes.phase_spectrum do return the line object. I know this is inconsistent, but I think it is very important and would strongly objefct to removing this. The question, then, is whether this would be a good opportunity to add the line object to the returned values for axes.psd and axes.csd. This would be an API break, but would be very easy to fix, and it may be beneficial enough to warrant it. What does everyone think? -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig pierre.haes...@crans.orgwrote: Hi, Le 20/10/2013 09:45, Todd a écrit : I submitted a pull request #2522 [1]. It includes support for more basic spectrum plots like magnitude and phase spectrums. These are extremely commonly used in signal processing, acoustics, and many other fields, but are also very important for educational usage since pretty much anyone going through one of several engineering degrees like electrical engineering has to learn these types of plots. I have heard a number of colleagues complaining about the lack of these plots in matlab. Having specific signal processing functions is indeed important. I hust have a question about phase vs. angle spectrum. From browsing quickly through you doc, it seems that the difference is just about *unwrapping the phase*. If that's indeed the case, I've two questions/remarks: 1) is the terminology phase vs. angle spectrum standardized ? I must say I've never heard of one meaning wrapped and the other unwrapped. I didn't find similar terms in Matlab docs, but I didn't search that thoroughly. The angle function in numpy returns the wrapped angle, while the unwrap function documentation talks about phase, so it is consistent with the usage in numpy. Further, in signal processing, phases can have any value, while angle often refers to the angle between two lines, which must be wrapped. There may be some ambiguity, but I made sure to explain it in the documentation and provide links between the two functions so people know what they should do if they want to use the other approach. 2) Should there be two separate functions for these two, or just one function, with a switch argument `unwrap` ? (I guess it would be True by default) I originally was going to do that, but decided against it. The problem is with specgram. Here, I thought it would be needlessly complicated to add an unwrap parameter that is only useful for one mode. To make it obvious to users, I wanted to keep specgram as similar as possible to the other plot types, and that involved keeping the parameter. Further, this approach is simpler to code and easier to maintain. Having to deal with the unwrap parameter would have been more difficult to program. Dealing with both an unwrap parameter in some cases and a separate mode in others would have been even more complicated. Further, _spectral_helper and specgram already have a huge number of arguments. This way I was able to get away with just adding one new argument rather than two. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] ggplot for matplotlib
Seems like a lot of what they are doing could be upstreamed into matplotlib. Then they could just wrap it in their own ggplot syntax. That would improve matplotlib and simplify the maintainance for them. On Mon, Oct 21, 2013 at 5:58 PM, Michael Droettboom md...@stsci.edu wrote: I just learned about this today, and thought I'd share. It's an implementation of the ggplot interface on top of matplotlib: http://blog.yhathq.com/posts/ggplot-for-python.html -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Directories for C/C++ extensions
On Mon, Oct 21, 2013 at 7:36 PM, Chris Barker chris.bar...@noaa.gov wrote: To expand slightly, with the current situation the onus is on us to ensure that mpl builds OK and passes all of our tests with and without each of the external libraries. If you only have internal libs, then there is less to do -- it only need to work with the version you bundle. And making sure it works with any-old-version-that-may-not-exist-yet is a pretty formidable challenge! We have sonums for this very reason. And this could apply just as well to python itself. There is a reason not many distros ship SAGE packages. Linux distro packagers will choose to set up qhull as a required dependency for their mpl package, and once they have done this can simply delete our directory containing the qhull source code in their mpl source package, If they are going to insist on doing this, then, yes you should certainly do it this way. Yes, they are. This is the whole point of having packages in the first place, as opposed to something like windows where every program just bundles everything.. we can all be confident that it will work correctly. only if you've tested against the version (maybe patched) of the external lib they are using... It is only matplotlib's responsibility to test against the unpatched versions specified, just like it is only matplotlib's responsibility to test against the unpatched python versions specified. Doing this isn't a particularly difficult task, there are easily tens of thousands of apps that have no problem with this. If we always used our internal version then distro packagers would have to change our setup scripts to build using the external libraries. This would be more time-consuming and error prone leading to less timely mpl distro releases. We need to make their job as easy as possible. it's easiest for them if they don't try to pull out an included dependency -- but maybe you're right that that REALLY want to do that! It would be easiest if matplotlib detected whether the library is present at build-time. That is what most packages do. The needs of the distro packagers, which are primarily security and stability, are sometimes at odds with the needs of scientific software, where the premium is on reproducibility. The output of matplotlib depends on the versions of some of its dependencies, not the version of matplotlib alone, and that's problematic for some... exactly -- if we know exactly which version of a lib is in use, we know that it works the way we expect in the use cases we expect to use it in. But I'm not maintaining this code, so have at it in the way that makes sense to you. NOTE: it would be a different story if this were a netwroking protocol lib, or something where security patches would be critical. Maybe I'm naive, but this doesn't seem likely in this case. You would be surprised what sort of packages can lead to security vulnerabilities. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Pull request
Hello, I submitted a pull request #2522 [1]. It includes support for more basic spectrum plots like magnitude and phase spectrums. These are extremely commonly used in signal processing, acoustics, and many other fields, but are also very important for educational usage since pretty much anyone going through one of several engineering degrees like electrical engineering has to learn these types of plots. I have heard a number of colleagues complaining about the lack of these plots in matlab. It has been up for 5 days, but I haven't received any comments on its content or structure. I understand that it is a pretty substantial patch, but I think the features are very useful. I am also a bit concerned that patches covering the same code might be submitted and accepted while I am waiting for this, since such changes would be hard to merge into my branch. So does anyone have any thoughts on the patch? [1] https://github.com/matplotlib/matplotlib/pull/2522 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Directories for C/C++ extensions
On Oct 18, 2013 8:20 PM, Chris Barker chris.bar...@noaa.gov wrote: Ian, I am working on a PR to replace the use of matplotlib.delaunay with the Qhull library. nice! -- ( though I sure wish Qhull did constrained delaunay...) Installation will be similar to the existing packages LibAgg and CXX in that if the system already has a sufficiently recent version of Qhull installed then matplotlib will use that, otherwise it will build the required library from the source code shipped with matplotlib. Why bother, why not just always build the internal version? (for that matter, same with agg) Wouldn't it be a lot easier and more robust to be sure that everyone is running the exact same code? What are the odds that folks are using qhull for something else, and even more to the point, what are the odds that the duplication of this lib would matter one wit? This isn't like LAPACK, where folks have a compellling reason to run a particular version. -- just my thoughts on how to keep things simpler. -Chris From a Linux distro packaging perspective bundled external libs are a big no-no. If a patch is needed for whatever reason packagers don't want to have to go and hunt down dozens of copies of the same library. In some cases there is no alternative but it should be avoided whenever possible. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] New tests failing when run together
I have been implementing some new plot types, with tests. This code passes all existing tests. I have also expanded the tests on some existing plot types and mlab functions. These tests run fine on their own. The problem is that, when I run the code with the new tests, I get a lot of out of memory errors. Further, the errors do not occur in the new tests, but rather in other, unrelated tests. Further, the tests that fail work fine when run on their own, they only fail when run as part of the complete test suite. Even stranger, when I run the tests in parallel (even with only one process) and enable --process-restartworker, the tests run fine (with a large enough timeout). But --process-restartworker doesn't help if parallel tests are not turned on. So I am not sure exactly what to do here. Even if I leave out my own tests, I may be running into some limit or memory leak that may very well result in problems for other people down the road. A solution might be to force tests to run in parallel with --process-restartworker, but of course it would be better to find out where the leak is. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New tests failing when run together
The branch is matplotlib/toddrjen spectral: https://github.com/toddrjen/matplotlib/tree/spectral Specifically the tests that are causing the problem are in test_mlab.py. I tried reorganizing the tests into subclasses and implementing a cleanup class (that is the current HEAD), but the problem exists even without that commit. You can cherry-pick 50c90102a929af5d534e551fd624abffeb9470b8 and 7c1b4db8b2d04826e267781c0de1bcc622f0fdb5. On Thu, Oct 10, 2013 at 3:22 PM, Michael Droettboom md...@stsci.edu wrote: Are your tests including the @cleanup decorator? (The @cleanup decorator is run implicitly with the @image_comparison decorator, so you really only need one or the other). Beyond that wild guess, I'm not sure what could be going on. You could file a pull request with your new code, even if it's not fully ready, so we could try it out and poke at it. Or just point us to your git branch so we could check it out. Mike On 10/10/2013 07:33 AM, Todd wrote: I have been implementing some new plot types, with tests. This code passes all existing tests. I have also expanded the tests on some existing plot types and mlab functions. These tests run fine on their own. The problem is that, when I run the code with the new tests, I get a lot of out of memory errors. Further, the errors do not occur in the new tests, but rather in other, unrelated tests. Further, the tests that fail work fine when run on their own, they only fail when run as part of the complete test suite. Even stranger, when I run the tests in parallel (even with only one process) and enable --process-restartworker, the tests run fine (with a large enough timeout). But --process-restartworker doesn't help if parallel tests are not turned on. So I am not sure exactly what to do here. Even if I leave out my own tests, I may be running into some limit or memory leak that may very well result in problems for other people down the road. A solution might be to force tests to run in parallel with --process-restartworker, but of course it would be better to find out where the leak is. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing listMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] RFC: Moving plots out of axes
Currently, many of the plot types reside in axes. This makes sense from a structural standpoint, since the plots are generally a part of an axes. However, it makes things more difficult from a practical standpoint. First, it means that the axes class is huge, with both core axes-related methods and plotting-related methods. Second, it means that boilerplate.py has to be told explicitly which methods to use, rather than just grabbing everything from a module. Third, it makes it impossible to break the plot types into smaller groups of related plots. The solution, I think, is to move the plots into one or more modules and implement them as functions. They would have the same call signature as now, we would just replace self with ax or something like that. This would allow you to, theoretically, import and call them without axes, but this would probably not be common. Within the axes constructor, the constructor would run through each of these modules and store them as attributes with the same name as the function and the function itself being the contents. At least if me understanding is correct, this would make them behave as methods (since they are already set up to take an axes instance as their first argument). The axes would just be left with the methods related to manipulating the axes themselves. This would also simplify boilerplate.py, since it would simply need to know the names of the modules rather than the name of every plot type. It would then just run through the functions in the modules (or even just run through all modules in a particular directory). We would probably even be able to do away with that portion of boilerplate.py completely, creating the plotting functions in on-the-fly in pyplot at runtime, but that is a separate issue. What does everyone think of this approach? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] my $0.02 on MEP13
On Feb 8, 2013 11:14 PM, Benjamin Root ben.r...@ou.edu wrote: Just a crazy thought, but why are we trying to treat title and such as properties? When I think of properties for matplotlib, I think of edgecolors, fontsize, and linestyles. Why don't we solve that problem first? In my mind there are several reasons. First, I personally see things like title as properties as well. I can see why not everyone would, but that would seem to me a reason to keep the setter functions at least in some cases rather than a reason to not implement properties. Second, it is more consistent. Users wouldn't need to remember on a case-by-basis whether to use a setter or a property. Third, it would require making sure the API is clan and consistent behind the scenes. The more complex setters like title would just be wrappers around the properties or property functions, so there would need to be ways to access the individual arguments on their own. That being said, it would be possible to implement properties in stages, with simpler ones done first and more complex ones done later. However, there are three reasons I did not include this in my proposed plan. First, it would mean we lose consistency, perhaps for a few releases. Second, it could lead to the API breakage being split over several releases rather than happening all at once. Third, if we do the behind-the-scenes cleanups first then this isn't an issue to begin with since complexities will already be dealt with. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] my $0.02 on MEP13
On Fri, Feb 8, 2013 at 3:38 AM, Jason Grout jason-s...@creativetrax.comwrote: On 2/7/13 8:08 PM, Erik Bray wrote: A couple easier solutions: Allow the `.title` (and other such attributes) to be assigned to with a (value, options) tuple where the value is the title itself, and the options is a dictionary or tuple of supported options for the title. Interesting. Just brainstorming here...then ax.title += (None, moreoptions) could set more options (without changing the title text or already set options), or ax.title -= (None, deleteoptions) could reset just certain options to default values. Thanks, Jason I am not a fan of this approach. It seems to be trying to force a property to behave like a function when it isn't meant to behave like a function. In my mind a property is just that, a single aspect of an object. If you want to change another aspect, you need to change another property. So these moreoptions need to have their own properties, either in the axes object or, better yet, since they are properties of the title text, have them as properties of a text object. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] my $0.02 on MEP13
On Fri, Feb 8, 2013 at 2:40 AM, Antony Lee antony@berkeley.edu wrote: Hi, I saw that a discussion started on transitioning to the use of properties instead of explicit getters and setters, which seems like a very good idea to me... so I thought this would be a good idea to get involved in matplotlib-devel :) Right now an issue raised is what to do with set_* that take multiple arguments. Taking set_title, which takes both positional and keyword arguments, as an example, my idea would be to do ax.title = A title ax.title.fontdict = fontdict Basically, a property foo (in the matplotlib meaning of the word) becomes a descriptor with __get__ = get_foo and __set__ = set_foo, and keyword arguments to the old property setter become themselves descriptors on that descriptor. Antony I think this makes it over-complicated. It is much simpler, more explicit, and more consistent to have two properties here, one that only deals with a string, and a second that only deals with a text object. Then you can do something like (where titletext returns the text object): ax.titletext.fontdict That way we automatically get what you want without any additional work or fancy tricks in a much cleaner, more explicit, and more predictable manner. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Getting pull requests merged
Is there a process that someone needs to go through to get a pull request merged into master? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP13 - python containers
On Thu, Jan 17, 2013 at 10:43 AM, Phil Elson pelson@gmail.com wrote: Hi Todd, I agree with the principle of properties - it will make much of the mpl codebase (and user code) more pythonic, so thanks for proposing this. Would you be able to give an example of how you propose setters such as Axes.set_xlim might make use of properties. The particular example I have picked uses keywords to determine the behaviours of the method itself: def set_xlim(self, left=None, right=None, emit=True, auto=False, **kw): ... For me, the backwards compatibility issue is the key blocker to this MEP. Would you mind providing some concrete examples (perhaps using the set_xlim method as a focus point)? Cheers, Phil Methods like that will be a problem. I see two possible approaches (which are not mutually exclusive): 1. keep the set_xlim method for more sophisticated cases. 2. split the set_xlim method into several methods Frankly I am not sure deprecating the existing setter and getter methods is really called for. It may not be worth the trouble for users. That is why I said everything in the MEP is very tentative. For approach 1, we would keep the current method, but also have another method: @xlim.setter def xlim(self, lims): ... so for the basic case, just setting the lims, you would do: axesobj.xlims = (leftval, rightval) For approach 2, you would have additionally have (there is already an autoscale_x_on method): @autoscale_x.setter def autoscale_x(self, auto): ... @emit_xlim.setter def emit_xlim(self, emit): ... @xlim_left.setter def xlim_left(self, left): ... @xlim_right.setter def xlim_right(self, rigth): ... (or you could do some python-fu to allow you to assign values to the xlim[0] and xlim[1]) This would require setting three separate attributes. However, we would already have the autoscale_x property. In my opinion breaking up the API into separate calls would be a cleaner approach anyway. Setters and getters should be setters and getters, they shouldn't be modifying other unrelated values. But that does not mean we have to remove the existing approach. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Usefulness of Travis-CI
On Jan 16, 2013 9:30 AM, Fernando Perez fperez@gmail.com wrote: On Wed, Jan 16, 2013 at 12:10 AM, Nelle Varoquaux nelle.varoqu...@gmail.com wrote: Last but not least, maybe we can see what numfocus has to offer. Absolutely! I'll be offline for two weeks, but others on the list can certainly propose this to numfocus on the list and we can look into what can be done, esp. in a way that could also help other projects as well. Also, there's snakebite: http://www.snakebite.net. The project seemed very dormant for a long time, but there's been some activity since: http://www.snakebite.net/network. I'd ping Titus Brown on Twitter (@ctitusbrown) for info... Cheers, There is also the open build service, which is more of a build farm but can be set up pull, build, test, and publish git snapshots for most common Linux distributions to your own online software repository simultaneously with one click on a website or one commandline call. https://build.opensuse.org/ They provide hosting, building, and distribution for free. You can probably set up a script to automatically rebuild master on a change, or daily. However, setting it up to test individual commits would be overly difficult and probably be seen as an abuse of the system. Using it to always build, test, and release offer the latest master to most linux distros, on the other hand, would be fine. If someone contacts them they can probably set up a repository just for you, or if this sort of thing is useful a more general repository you can share with others (there is already devel:languages:python, maybe devel:languages:python:unstable). You can also use it to build release rpms and debs for various distros. It is already being used to build the packages discussed so far for openSUSE, but if someone is willing to maintain them they can be built for other distros as well. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Matplotlib property support
Currently matplotlib uses set_ and get_ functions for reading and writing values. However, since 2.6 python supports properties, which allow access to such values as attributes in addition to using the functions directly. Would it be worthwhile implementing property support in matplotlib? -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib property support
On Wed, Jan 16, 2013 at 2:55 PM, Benjamin Root ben.r...@ou.edu wrote: On Wed, Jan 16, 2013 at 2:42 PM, Todd toddr...@gmail.com wrote: Currently matplotlib uses set_ and get_ functions for reading and writing values. However, since 2.6 python supports properties, which allow access to such values as attributes in addition to using the functions directly. Would it be worthwhile implementing property support in matplotlib? This was actually discussed during a Birds of a Feather (BOF) meeting back in SciPy2012 (which John Hunter attended). I am definitely for the idea, but it is going to be a very painful and long deprecation process. Is there a reason we have to deprecate the current method? They are not mutually-exclusive. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] MEP13 - python containers
I have created a very preliminary MEP for the possible move to properties: https://github.com/matplotlib/matplotlib/wiki/MEP13 Please take a look at it and discuss. As I said, this is very preliminary. Everything is subject to change. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib property support
On Wed, Jan 16, 2013 at 2:52 PM, Michael Droettboom md...@stsci.edu wrote: This seems like a good candidate for a MEP. We'd want to take a graceful approach to transitioning to properties. See here for information about MEPs: https://github.com/matplotlib/matplotlib/wiki Mike I have created a MEP on the subject, MEP13, and a new mailing list thread to discuss it. -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Mon, Jan 14, 2013 at 1:28 AM, Todd toddr...@gmail.com wrote: On Mon, Nov 12, 2012 at 6:35 PM, Damon McDougall damon.mcdoug...@gmail.com wrote: On Mon, Nov 12, 2012 at 2:17 PM, Paul Ivanov pivanov...@gmail.com wrote: On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom md...@stsci.edu wrote: On 11/11/2012 11:51 PM, Todd wrote: Now that 1.2 is out, can we revisit this? I would like to get it implemented for the next feature release. Absolutely. I think the next step, once you have an implementation, would be to submit a pull request and we can all help with a review. This hasn't been mentioned yet, but Todd will hopefully find our developer docs useful: http://matplotlib.org/devel/index.html In particular, there's a section on writing a new pyplot function: http://matplotlib.org/devel/coding_guide.html#writing-a-new-pyplot-function Thanks for that, Paul. Todd, there's also a section on writing tests for matplotlib on the page Paul pointed out. For a new feature there should be a couple of tests to go with it to make sure everything passes sanity checks. Thanks for spending your time contributing! I have completed the plot type, including unit tests and examples (I am not an artist so someone else can probably make the examples prettier). I've confirmed pep8 compliance and run the code through pyflakes and pylint in addition to the unit tests. It is divided into two parts: an EventCollection class, which is a subclass of LineCollection in collections.py, and an eventplot method in axes.py (and pyplot, through boilerplate.py) which returns a list of EventCollection objects. I am ready to submit a git pull request now. However, it depends on another git pull request I submitted, titled add get_segments method to collections.LineCollectionhttps://github.com/matplotlib/matplotlib/pull/1655. I can confirm the changes in this pull request work properly, I have been using the new method extensively in my new plot type. Would it be possible to get this accepted so I can submit the new plot type for review? I am sure there will be lots of changes and cleanups that will be required before the new plots can be accepted, while the get_segments method is a relatively minor and non-intrusive change. If you wish to look at the code before the pull request it is in the toddrjen/matplotlib github fork, in the eventplot branch. The main changes are to collections.py and axes.py. The tests are in test_axes.py and a new test file test_collections.py. The examples are in eventcollection_demo.py and eventplot_demo.py Thanks a lot for your time. Thanks for getting get_segments in so quickly. The pull request has been submitted, see Add EventCollection and eventplothttps://github.com/matplotlib/matplotlib/pull/1657 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Mon, Nov 12, 2012 at 6:35 PM, Damon McDougall damon.mcdoug...@gmail.comwrote: On Mon, Nov 12, 2012 at 2:17 PM, Paul Ivanov pivanov...@gmail.com wrote: On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom md...@stsci.edu wrote: On 11/11/2012 11:51 PM, Todd wrote: Now that 1.2 is out, can we revisit this? I would like to get it implemented for the next feature release. Absolutely. I think the next step, once you have an implementation, would be to submit a pull request and we can all help with a review. This hasn't been mentioned yet, but Todd will hopefully find our developer docs useful: http://matplotlib.org/devel/index.html In particular, there's a section on writing a new pyplot function: http://matplotlib.org/devel/coding_guide.html#writing-a-new-pyplot-function Thanks for that, Paul. Todd, there's also a section on writing tests for matplotlib on the page Paul pointed out. For a new feature there should be a couple of tests to go with it to make sure everything passes sanity checks. Thanks for spending your time contributing! I have completed the plot type, including unit tests and examples (I am not an artist so someone else can probably make the examples prettier). I've confirmed pep8 compliance and run the code through pyflakes and pylint in addition to the unit tests. It is divided into two parts: an EventCollection class, which is a subclass of LineCollection in collections.py, and an eventplot method in axes.py (and pyplot, through boilerplate.py) which returns a list of EventCollection objects. I am ready to submit a git pull request now. However, it depends on another git pull request I submitted, titled add get_segments method to collections.LineCollectionhttps://github.com/matplotlib/matplotlib/pull/1655. I can confirm the changes in this pull request work properly, I have been using the new method extensively in my new plot type. Would it be possible to get this accepted so I can submit the new plot type for review? I am sure there will be lots of changes and cleanups that will be required before the new plots can be accepted, while the get_segments method is a relatively minor and non-intrusive change. If you wish to look at the code before the pull request it is in the toddrjen/matplotlib github fork, in the eventplot branch. The main changes are to collections.py and axes.py. The tests are in test_axes.py and a new test file test_collections.py. The examples are in eventcollection_demo.py and eventplot_demo.py Thanks a lot for your time. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Github Downloads going away...
On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall damon.mcdoug...@gmail.comwrote: On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout jason-s...@creativetrax.com wrote: On 12/14/12 10:55 AM, Nathaniel Smith wrote: sourceforge's horror of an interface. I'll second that. Every time I go to Sourceforge, I have to figure out how in the world to download what I want (and I have to figure out which things *not* to click on too). Ok sounds like there is a reasonable amount of resistance towards Sourceforge. Eric, when you suggest that NumFocus could 'provide hosting directly', do you mean they would have the physical hardware to host the files, or are you suggesting they provide the finances to seek hosting elsewhere? In the GitHub blog post, they suggest using S3. We could try that. It's fairly inexpensive and the first year is free (within monthly bandwidth limits). We could try it for a year and see how that pans out? I'm not entirely sure how the Amazon stuff works but I've heard good things about it. Are you sure the monthly bandwidth limits are sufficient? Also, have you talked to the pypi people about making exceptions for really popular projects? If critical packages like numpy, scipy, and matplotlib cannot use pypi, that seems like a major failing of the system. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Github Downloads going away...
On Dec 14, 2012 5:59 PM, Michael Droettboom md...@stsci.edu wrote: Github has removed the ability to host binaries. They've removed this feature without any apparent notification except on their blog saying it's gone today. And the suggested alternative is to use paid services. https://github.com/blog/1302-goodbye-uploads I had planned to complete our set of 1.2.0 binaries with a Python 3.2 from Russell Owen in the near future. So much for that. Any thoughts? Do we go back to Sourceforge for our download hosting? Is anyone familiar with any other services? Do we try to piggy-back on what other scipy projects are doing? Mike Is there a reason pypi is not usable? -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 8:18 PM, Todd toddr...@gmail.com wrote: On Thu, Sep 27, 2012 at 1:44 PM, Todd toddr...@gmail.com wrote: On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall damon.mcdoug...@gmail.com wrote: Hi Todd, Firstly, thanks for taking the time to crystallise your thoughts in words first. This is one of my bad habits; I tend to rush into things. I have some feedback for you, hopefully we can all work together to get this right. It's difficult when something new gets implemented and someone expects it to do something and the only way to resolve it is to break the calling API. Where is API broken? Anyway, I hope you'll find my comments helpful at the least. I also encourage others to weigh in with opinions and ideas. Okay, I will discuss the rationale. I will snip out anything you agree on for brevity. Assuming we go with the name, here is my proposed call signature: EventRaster(x, offset=0, height=1, **kargs) CamelCase is discouraged for method names. Perhaps 'eventraster'? Fair enough. Also, we could also let **kwargs swallow the 'offset' and 'height' keyword arguments. Then the user isn't constrained by which order to put them in. The downside of this approach is that introspection is more difficult. I don't understand the advantage of this approach. If you use keyword arguments, then the order doesn't matter. So with the approach above you can use keyword arguments, in which case you can use whatever order they want, or you can use positional arguments. On the other hand putting it in **kwargs, we lose the ability to use positional arguments. So we lose nothing by allowing both positional and keyword arguments. It is also easier to implement. offset determines the positions of the rows. By default, the first row is placed with the line center y=0, and subsequent rows are placed with the line centers at increasing 1-unit increments. If offset is defined and is a scalar, the first row is placed at the offset, and subsequent rows are placed at increasing 1-unit increments. If offset is an array, it must be a 1D array of the same length as the second dimension of x. In this case each element in offset determines the center of the corresponding row in the plot. How about letting offset be either: a) a scalar, determining the offset of all rows equally; or b) an array, determining the offset of each row individually. Because people are almost never going to want to have all the lines stacked right on top of each other. The plot would be indecipherable that way. The defaults are chosen to handle the most common use-cases most easily. In fact, why plot each row at integer y coordinates? Could we allow for an optional y-coordinate array, each element of which would be the y-coordinate at which to plot a row of lines. Then you wouldn't need offset. That is exactly what offset does if you pass an array. If this is going to be used to implement rug plots, it would need some way to handle columns of horizontal lines in addition to rows of vertical lines. I see two ways to implement this. First is to have to plot types, perhaps HEventRaster and VEventRaster. The first would be as described above, while the second would be similar but everything rotated 90 degrees. Another possibility is to change the call signature to this: EventRaster(x, y=None, offset=0, height=1, **kargs) I think accepting an 'orientation' kwarg, which can take either 'horizontal' or 'vertical', determining the orientation of the lines and reversing the roles of the x and y arrays. That would work as well. Probably cleaner that way The function will return a list of a new collection type I am tentatively calling EventCollection. My thinking would be this would be a subclass of a new collection type called GenericLineCollection, which the current LineCollection would also subclass. They would share things like the color handling and segment handling, however the segment handling will be a private method that LineCollection will have a public wrapper for. On the other hand methods to set or add segments will remain private in EventCollection, although there will be a method to return the segments if an artist really wants to manipulate individual segments. Why can't we just use LineCollection? I don't see a good reason to create a new collection class here; the plot is simple. Explained below. The reason for doing it this way is that manipulating individual rows of events should be very common, such as changing their position, color, marker, width, and so on. On the other hand manipulating lines individually should not be as common, although still supported. Fair enough, then maybe a better idea is to create your own EventRaster class (note camel case) to hold all the relevant data in arrays. Then make a 'construct_raster' method could return a LineCollection. Then again, weren't you passing extra kwargs
[matplotlib-devel] 1.3+ Release schedule (was: strategy for 1.2.x, master, PEP8 changes)
On Mon, Oct 15, 2012 at 2:11 PM, Phil Elson pelson@gmail.com wrote: if we leave PEP8 out of v1.2.x, and decide that once it is released, v1.2.x will be changed only if critical bugs are found, requiring a v1.2.1 release I agree. I think it is important here to be very clear about what constitutes a critical bug. In my opinion, releasing a v1.2.1 would be a very last resort and I would sooner see us move forward by fixing bugs in a new feature release (1.3). In order to do this we should have a schedule for our next release *now*, and ideally it shouldn't be that far away (i.e. no longer than 8-9 months). Some of my reasons for this assertion include: We have an amazing community of people who help us build our release bundles - so the actual release deployment mechanisms are no longer a limiting factor We have a long period between identification of features, their implementation and then seeing those features available in the latest release to our users. I would love to see that time shorten to share some of the cool new features that are being developed with non-developers sooner so that we can get feedback and go through the development cycle quicker. Currently making a release is a massive task which takes many developers out of actually being able to focus on new features or bugfixes. Having a quicker release cycle should mean we have fewer large changes per release and reduce the need we currently have to squeeze as much as we can into the next release - ultimately I think it will mean that we need to expend fewer developer hours focused on release management and last minute code reviewing. [snip] Phil Why 8 to 9 months? This still seems like a very long time for a project of this size. Much larger and more complicated projects (gnome, KDE, Ubuntu) manage a 6 month release cycle, and for projects this size I follow 2 to 3 months seems more typical. It's there a reason the release cycle needs to be so long? With a few month release schedule you can probably manage just 2 betas and an rc, judging by other projects. Also, have you considered a master is always stable approach, where branches are only merged when they are complete? This could make arbitrary release points much easier. So basically, rather than waiting until you have a lot done for a new release, you could have an approach more like Firefox now where each release just had a couple new features, or maybe even just one big feature. Then a very quick beta cycle, and bugfix releases when needed, but with that quick of a release cycle bugfix releases should not be as important as they are now. Other features would be worked on in parallel in their own branch, ignoring the release entirely. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] PyGTK vs PyGObject
I am trying to do some experimental packages with python 3 and the latest RC, and I am trying to figure out the situation with some of the backends. Some are obvious, like wxwidgets and PyQt (Qt3 version). The issue I am running into is with the gtk backend PyGTK is deprecated. According to the website, all development halted a year and a half ago and they say to use PyGObject instead. PyGTK, as far as I can tell, does not support Python 3 or GTK 3. PyGObject, however, supports both. So I was wondering what I should be doing with this backend. Does matplotlib support PyGObject, or should the GTK backends just be disabled on Python 3 builds? Thanks for your help. -Todd -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue
On Wed, Oct 3, 2012 at 6:20 PM, Michael Droettboom md...@stsci.edu wrote: I invite comments for a new MEP about improving the situation with respect to our bundling of third-party Python dependencies. In particular, I'd love feedback from the various stakeholders -- those producing binary installers and packages for the various platforms. https://github.com/matplotlib/matplotlib/wiki/MEP11 Mike I help with the openSUSE packaging of mpl. At least as openSUSE policies go, bundling dependencies is considered a big no-no. RPM has its own dependency handling, so as long as the dependencies are documented (ideally with version numbers) then there is no issue, either at build-time or at run-time. I think that would likely be the case for any official linux packages. Anyone on Linux who is trying to install matplotlib from source should be prepared to handle dependency resolution manually. If they aren't, then they shouldn't be messing with package installation in the first place. I think the documentation should clearly state this, although more diplomatically of course :) So from a Linux standpoint I think bundling is a bad idea. Further, any solution should be prepared to handle the situation where the dependencies are already available, and not try to download them under this situation. It should also be able to handle installation with no internet connection as long as the dependencies are available, so it can be compatible with automated build systems and hpc environments which may not support internet access for security reasons. For windows, rather than creating independent matplotlib installers, can't the documentation just point people in the direction of a pre-existing bundle like python(x,y)? Since there are groups dedicated to making it easy to install python packages on windows, I don't see the point of going through all the trouble of making your own version. If you really wanted to you might even be able to use their sources to create your own variant that just installs what you need. -Todd -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Wed, Sep 26, 2012 at 3:14 PM, Michael Droettboom md...@stsci.edu wrote: On 09/26/2012 04:35 AM, Todd wrote: On Mon, Sep 24, 2012 at 3:33 PM, Todd toddr...@gmail.com wrote: I would like to add a new plot type to matplotlib. Of course I am willing to implement it myself, but I want to confirm that it is acceptable and iron out the implementation details and API first so there are no major surprises when I submit it. I tentatively am calling the plot type an EventRaster plot (name suggestions, along with any other suggestions, are welcome). The plot is made up if horizontal rows of identical vertical lines and/or markers. Each line or marker represents a discrete event, and each row represents a single sequence of events (such as a trial). The x-axis position of the line or marker identifies the location of the event by some measure. An example of what such a plot often looks like is below. http://hebb.mit.edu/courses/9.29/2003/athena/dylanh/quad-rast.gif This sort of plot is used ubiquitously in neuroscience. It is used to show the time of discrete neural (brain cell) events (called spikes) over time in repeated trials, and is generally called a spike raster, raster plot, or raster graph. However, it can be used in any situation where you are only concerned with the position of events but not their amplitude, especially if you want to look for patterns in those events or look for differences between multiple sequences of events. Plotting the timing of events is an obvious use case, such as photons hitting photodetectors, radioactive decay events, arrival of patients to hospitals, calls to hotlines, or car accidents in cities. However, the events do not have to be relative to time. It could be position, for example, such as tree rings along bore holes, road crossings along railroad tracks, layers in sediment cores, or particular sequences along a DNA strands. I'll cover possible implementation details in the next email if everyone thinks this is a good idea. So does anyone think this would be a useful plot type? If so I can explain how I plan to implement it and we can discuss changes or improvements to that. Sorry to not get back to you sooner -- a number of us are busy here getting the 1.2.0 release ready at the moment. I think this is definitely a worthwhile plot type to add. Similar plots are used in Computer Science, for example, to visualize the execution of multi-threaded applications, or other scheduling problems. I'd personally use it for that. So, yes, let's start talking implementation. Or, if easier, you could just submit a pull request and we can go from there. Whatever method seems most appropriate to you. I would prefer to get the details worked out before I start coding since there are a few different approaches. First thing is to figure out a good name, I am not sure this is the best name for it. Assuming we go with the name, here is my proposed call signature: EventRaster(x, offset=0, height=1, **kargs) x is a 1D or 2D array. If a 1D array, it create a single row of lines. If it is a 2D array, it creates one row of lines for each row in the array. offset determines the positions of the rows. By default, the first row is placed with the line center y=0, and subsequent rows are placed with the line centers at increasing 1-unit increments. If offset is defined and is a scalar, the first row is placed at the offset, and subsequent rows are placed at increasing 1-unit increments. If offset is an array, it must be a 1D array of the same length as the second dimension of x. In this case each element in offset determines the center of the corresponding row in the plot. height determines the length of the lines. By default the line stretches from offset-.5 to offset+.5. If height is defined the line stretches from offset-.5*height to offset+.5*height. **kargs are the same as those of plot(). An important thing to note is that the marker will only appear the center point of each line, not at the ends. If this is going to be used to implement rug plots, it would need some way to handle columns of horizontal lines in addition to rows of vertical lines. I see two ways to implement this. First is to have to plot types, perhaps HEventRaster and VEventRaster. The first would be as described above, while the second would be similar but everything rotated 90 degrees. Another possibility is to change the call signature to this: EventRaster(x, y=None, offset=0, height=1, **kargs) In this case y behaves the same as x, except it creates columns of lines instead of rows. If y is specified x cannot be specified, and vice versus. If keyword arguments are not used, it assumes x is what is wanted. I don't know which approach is better. The function will return a list of a new collection type I am tentatively calling EventCollection. My thinking would be this would be a subclass of a new collection type called
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 12:58 PM, Thomas Kluyver tho...@kluyver.me.uk wrote: On 27 September 2012 11:41, Todd toddr...@gmail.com wrote: I would prefer to get the details worked out before I start coding since there are a few different approaches. First thing is to figure out a good name, I am not sure this is the best name for it. As someone from a field that doesn't regularly use that sort of plot, 'raster' seems an odd name - it doesn't seem to relate to raster vs. vector graphics. That was exactly my concern. From the examples linked earlier in the thread, I'd call it something like EventStrip. The problem is it isn't really a strip either, since it can have many rows of events. It could be EventStrips, though. Some other possibilities that occured to me: EventPlot EventsPlot SequencePlot SequencesPlot Events1D Sequences1D -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall damon.mcdoug...@gmail.com wrote: Hi Todd, Firstly, thanks for taking the time to crystallise your thoughts in words first. This is one of my bad habits; I tend to rush into things. I have some feedback for you, hopefully we can all work together to get this right. It's difficult when something new gets implemented and someone expects it to do something and the only way to resolve it is to break the calling API. Where is API broken? Anyway, I hope you'll find my comments helpful at the least. I also encourage others to weigh in with opinions and ideas. Okay, I will discuss the rationale. I will snip out anything you agree on for brevity. Assuming we go with the name, here is my proposed call signature: EventRaster(x, offset=0, height=1, **kargs) CamelCase is discouraged for method names. Perhaps 'eventraster'? Fair enough. Also, we could also let **kwargs swallow the 'offset' and 'height' keyword arguments. Then the user isn't constrained by which order to put them in. The downside of this approach is that introspection is more difficult. I don't understand the advantage of this approach. If you use keyword arguments, then the order doesn't matter. So with the approach above you can use keyword arguments, in which case you can use whatever order they want, or you can use positional arguments. On the other hand putting it in **kwargs, we lose the ability to use positional arguments. So we lose nothing by allowing both positional and keyword arguments. It is also easier to implement. offset determines the positions of the rows. By default, the first row is placed with the line center y=0, and subsequent rows are placed with the line centers at increasing 1-unit increments. If offset is defined and is a scalar, the first row is placed at the offset, and subsequent rows are placed at increasing 1-unit increments. If offset is an array, it must be a 1D array of the same length as the second dimension of x. In this case each element in offset determines the center of the corresponding row in the plot. How about letting offset be either: a) a scalar, determining the offset of all rows equally; or b) an array, determining the offset of each row individually. Because people are almost never going to want to have all the lines stacked right on top of each other. The plot would be indecipherable that way. The defaults are chosen to handle the most common use-cases most easily. In fact, why plot each row at integer y coordinates? Could we allow for an optional y-coordinate array, each element of which would be the y-coordinate at which to plot a row of lines. Then you wouldn't need offset. That is exactly what offset does if you pass an array. If this is going to be used to implement rug plots, it would need some way to handle columns of horizontal lines in addition to rows of vertical lines. I see two ways to implement this. First is to have to plot types, perhaps HEventRaster and VEventRaster. The first would be as described above, while the second would be similar but everything rotated 90 degrees. Another possibility is to change the call signature to this: EventRaster(x, y=None, offset=0, height=1, **kargs) I think accepting an 'orientation' kwarg, which can take either 'horizontal' or 'vertical', determining the orientation of the lines and reversing the roles of the x and y arrays. That would work as well. Probably cleaner that way The function will return a list of a new collection type I am tentatively calling EventCollection. My thinking would be this would be a subclass of a new collection type called GenericLineCollection, which the current LineCollection would also subclass. They would share things like the color handling and segment handling, however the segment handling will be a private method that LineCollection will have a public wrapper for. On the other hand methods to set or add segments will remain private in EventCollection, although there will be a method to return the segments if an artist really wants to manipulate individual segments. Why can't we just use LineCollection? I don't see a good reason to create a new collection class here; the plot is simple. Explained below. The reason for doing it this way is that manipulating individual rows of events should be very common, such as changing their position, color, marker, width, and so on. On the other hand manipulating lines individually should not be as common, although still supported. Fair enough, then maybe a better idea is to create your own EventRaster class (note camel case) to hold all the relevant data in arrays. Then make a 'construct_raster' method could return a LineCollection. Then again, weren't you passing extra kwargs to 'plot'? This approach would surely use ax.add_lines or ax.add_linecollection something (I can't remember what it's called). The whole point
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 2:17 PM, Damon McDougall damon.mcdoug...@gmail.com wrote: On Thu, Sep 27, 2012 at 12:44 PM, Todd toddr...@gmail.com wrote: On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall damon.mcdoug...@gmail.com wrote: Hi Todd, Firstly, thanks for taking the time to crystallise your thoughts in words first. This is one of my bad habits; I tend to rush into things. I have some feedback for you, hopefully we can all work together to get this right. It's difficult when something new gets implemented and someone expects it to do something and the only way to resolve it is to break the calling API. Where is API broken? Nowhere. I wasn't implying you were breaking something. My point was that it's easy to add functionality but hard to remove it, therefore it's important to get it right from the outset. I'm sorry for the misunderstanding; I wasn't clear. No problem. I put a lot of other comments inline in my reply to your email, but your mail reader might have cut them off. -Todd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 1:44 PM, Todd toddr...@gmail.com wrote: On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall damon.mcdoug...@gmail.com wrote: Hi Todd, Firstly, thanks for taking the time to crystallise your thoughts in words first. This is one of my bad habits; I tend to rush into things. I have some feedback for you, hopefully we can all work together to get this right. It's difficult when something new gets implemented and someone expects it to do something and the only way to resolve it is to break the calling API. Where is API broken? Anyway, I hope you'll find my comments helpful at the least. I also encourage others to weigh in with opinions and ideas. Okay, I will discuss the rationale. I will snip out anything you agree on for brevity. Assuming we go with the name, here is my proposed call signature: EventRaster(x, offset=0, height=1, **kargs) CamelCase is discouraged for method names. Perhaps 'eventraster'? Fair enough. Also, we could also let **kwargs swallow the 'offset' and 'height' keyword arguments. Then the user isn't constrained by which order to put them in. The downside of this approach is that introspection is more difficult. I don't understand the advantage of this approach. If you use keyword arguments, then the order doesn't matter. So with the approach above you can use keyword arguments, in which case you can use whatever order they want, or you can use positional arguments. On the other hand putting it in **kwargs, we lose the ability to use positional arguments. So we lose nothing by allowing both positional and keyword arguments. It is also easier to implement. offset determines the positions of the rows. By default, the first row is placed with the line center y=0, and subsequent rows are placed with the line centers at increasing 1-unit increments. If offset is defined and is a scalar, the first row is placed at the offset, and subsequent rows are placed at increasing 1-unit increments. If offset is an array, it must be a 1D array of the same length as the second dimension of x. In this case each element in offset determines the center of the corresponding row in the plot. How about letting offset be either: a) a scalar, determining the offset of all rows equally; or b) an array, determining the offset of each row individually. Because people are almost never going to want to have all the lines stacked right on top of each other. The plot would be indecipherable that way. The defaults are chosen to handle the most common use-cases most easily. In fact, why plot each row at integer y coordinates? Could we allow for an optional y-coordinate array, each element of which would be the y-coordinate at which to plot a row of lines. Then you wouldn't need offset. That is exactly what offset does if you pass an array. If this is going to be used to implement rug plots, it would need some way to handle columns of horizontal lines in addition to rows of vertical lines. I see two ways to implement this. First is to have to plot types, perhaps HEventRaster and VEventRaster. The first would be as described above, while the second would be similar but everything rotated 90 degrees. Another possibility is to change the call signature to this: EventRaster(x, y=None, offset=0, height=1, **kargs) I think accepting an 'orientation' kwarg, which can take either 'horizontal' or 'vertical', determining the orientation of the lines and reversing the roles of the x and y arrays. That would work as well. Probably cleaner that way The function will return a list of a new collection type I am tentatively calling EventCollection. My thinking would be this would be a subclass of a new collection type called GenericLineCollection, which the current LineCollection would also subclass. They would share things like the color handling and segment handling, however the segment handling will be a private method that LineCollection will have a public wrapper for. On the other hand methods to set or add segments will remain private in EventCollection, although there will be a method to return the segments if an artist really wants to manipulate individual segments. Why can't we just use LineCollection? I don't see a good reason to create a new collection class here; the plot is simple. Explained below. The reason for doing it this way is that manipulating individual rows of events should be very common, such as changing their position, color, marker, width, and so on. On the other hand manipulating lines individually should not be as common, although still supported. Fair enough, then maybe a better idea is to create your own EventRaster class (note camel case) to hold all the relevant data in arrays. Then make a 'construct_raster' method could return a LineCollection. Then again, weren't you passing extra kwargs to 'plot'? This approach would surely use ax.add_lines
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Mon, Sep 24, 2012 at 3:33 PM, Todd toddr...@gmail.com wrote: I would like to add a new plot type to matplotlib. Of course I am willing to implement it myself, but I want to confirm that it is acceptable and iron out the implementation details and API first so there are no major surprises when I submit it. I tentatively am calling the plot type an EventRaster plot (name suggestions, along with any other suggestions, are welcome). The plot is made up if horizontal rows of identical vertical lines and/or markers. Each line or marker represents a discrete event, and each row represents a single sequence of events (such as a trial). The x-axis position of the line or marker identifies the location of the event by some measure. An example of what such a plot often looks like is below. http://hebb.mit.edu/courses/9.29/2003/athena/dylanh/quad-rast.gif This sort of plot is used ubiquitously in neuroscience. It is used to show the time of discrete neural (brain cell) events (called spikes) over time in repeated trials, and is generally called a spike raster, raster plot, or raster graph. However, it can be used in any situation where you are only concerned with the position of events but not their amplitude, especially if you want to look for patterns in those events or look for differences between multiple sequences of events. Plotting the timing of events is an obvious use case, such as photons hitting photodetectors, radioactive decay events, arrival of patients to hospitals, calls to hotlines, or car accidents in cities. However, the events do not have to be relative to time. It could be position, for example, such as tree rings along bore holes, road crossings along railroad tracks, layers in sediment cores, or particular sequences along a DNA strands. I'll cover possible implementation details in the next email if everyone thinks this is a good idea. So does anyone think this would be a useful plot type? If so I can explain how I plan to implement it and we can discuss changes or improvements to that. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] process for getting a new plot type added
Hi, I am interested in implementing a new plot type for matplotlib. Is there a specific process I should go through, or is just discussing it on the mailing list sufficient? I see matplotlib has a MEP system similar to PEP, but there don't appear to be that many MEPs so I don't know whether it is used in this sort of situation or only for more fundamental changes. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] New plot type idea -- EventRaster
I would like to add a new plot type to matplotlib. Of course I am willing to implement it myself, but I want to confirm that it is acceptable and iron out the implementation details and API first so there are no major surprises when I submit it. I tentatively am calling the plot type an EventRaster plot (name suggestions, along with any other suggestions, are welcome). The plot is made up if horizontal rows of identical vertical lines and/or markers. Each line or marker represents a discrete event, and each row represents a single sequence of events (such as a trial). The x-axis position of the line or marker identifies the location of the event by some measure. An example of what such a plot often looks like is below. http://hebb.mit.edu/courses/9.29/2003/athena/dylanh/quad-rast.gif This sort of plot is used ubiquitously in neuroscience. It is used to show the time of discrete neural (brain cell) events (called spikes) over time in repeated trials, and is generally called a spike raster, raster plot, or raster graph. However, it can be used in any situation where you are only concerned with the position of events but not their amplitude, especially if you want to look for patterns in those events or look for differences between multiple sequences of events. Plotting the timing of events is an obvious use case, such as photons hitting photodetectors, radioactive decay events, arrival of patients to hospitals, calls to hotlines, or car accidents in cities. However, the events do not have to be relative to time. It could be position, for example, such as tree rings along bore holes, road crossings along railroad tracks, layers in sediment cores, or particular sequences along a DNA strands. I'll cover possible implementation details in the next email if everyone thinks this is a good idea. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Mon, Sep 24, 2012 at 3:51 PM, Nathaniel Smith n...@pobox.com wrote: On Mon, Sep 24, 2012 at 2:33 PM, Todd toddr...@gmail.com wrote: This sort of plot is used ubiquitously in neuroscience. It is used to show the time of discrete neural (brain cell) events (called spikes) over time in repeated trials, and is generally called a spike raster, raster plot, or raster graph. However, it can be used in any situation where you are only concerned with the position of events but not their amplitude, especially if you want to look for patterns in those events or look for differences between multiple sequences of events. This is very closely related to rug plots, which are often used as an axis annotation or elsewhere where it's nice to have a small 1-d density plot. Examples: https://www.cl.cam.ac.uk/~sjm217/projects/graphics/ http://rforge.org/2009/08/10/fancy-rugs-in-regression-plots/ The implementation I am thinking of for this plot type would also be able to handle these sorts of plots, although it would probably require creating horizontal and vertical variants. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release
On Wed, Jul 11, 2012 at 5:23 PM, John Hunter jdh2...@gmail.com wrote: On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall damon.mcdoug...@gmail.com wrote: Well, as Ben said, that error fill plot is neato! It doesn't look too complicated, either. I'd be more than happy to port it over later today when I get bored of typing up my thesis. It'll probably only take me about 30 minutes. If nobody is opposed to this idea, I'll go ahead and submit a PR this evening (British Summer (hah!) Time). While it is a nice graph, I am not sure that the use case is common enough to justify a new plotting method. One can get the same result with: In [68]: x = np.linspace(0, 2 * np.pi) In [69]: y_sin = np.sin(x) In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2]) In [71]: plot(x, y_sin) Out[71]: [matplotlib.lines.Line2D object at 0x96959ec] In [72]: fill_between(np.concatenate([x, x[::-1]]), err, facecolor='red', alpha=0.5) Out[72]: matplotlib.collections.PolyCollection object at 0x962758c Admittedly the [::-1] thing is a bit counter-intuitive, but rather than adding a new plotting method, perhaps we would be better off with a helper method to create the xs and ys for fill_between xs, ys = mlab.pad_line(x, y, 0.2) fill_between(xs, ys) JDH What about adding a property to the existing errorbar to let someone change it to the filled version? This could also, potentially, be extended with other types of error bars if the need arises. -Todd -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Upstream Matplotlib Qt Designer Plugin
On Mon, Mar 19, 2012 at 10:08 PM, Pierre Raybaut pierre.rayb...@gmail.com wrote: Hi all, Is anyone interested in including the Matplotlib QtDesigner plugin which I wrote for Python(x,y)? The code is quite simple and hasn't evolved for a while now (3 years) but apparently it is still appreciated by users even outside Python(x,y). Here are the two files which are necessary to make this plugin work: http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/matplotlibwidget.py http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/PyQt4/plugins/designer/python/matplotlibplugin.py The directory struture also has its importance: http://code.google.com/p/pythonxy/source/browse/#hg%2Fsrc%2Fpython%2Fmatplotlib%2FQtDesigner_Plugins Cheers, Pierre I have been looking at the matplotlib widget code. It is very helpful for putting a widget inside PyQt4 windows. However, it is lacking any signals and slots to let you easily connect other Qt4 widgets with the matplotlib one. Particularly in Qt Designer, using signals and slots to connect widgets together is very convenient. I am willing to implement signals and slots, but I need some advice on the best approach. So far I see three different approaches that may work: 1. The simplest is just to manually add slots for common commands in the widget. I would also probably add some signals for things like mouse clicks. However, this requires manually creating the signals and slots, and will break if matplotlib changes any of its api. I would also need to decide whether to use the matplotlib function naming rules or the Qt4 ones (or both, since I can give the same signal multiple names). 2. Integrate the signals and slots directly into matplotlib. This would probably involve somehow having matplotlib functions exposed as signals and/or slots, probably somewhere in the PyQt4/pyside backend. It would probably entail separating the PyQt4/pyside backend into a PyQt4/pyside widget and a PyQt4/pyside window that contains that widget. All the interaction between settings, buttons, etc would use signals and slots internally. Users could then use the widget in other contexts besides the window, and use the same signals and slots the window uses. This would also eliminate the need for a separate widget to be used for Qt Designer. It would still require manually specifying the signals and slots. I haven't looked in much detail, but this is probably not that much more difficult than 1. 3. Make PyQt4 backend use widgets for everything. Each object would have all of its functions exposed as signals and slots, and all would be usable in Qt Designer. If I understand it correctly, the PyQt4 backend uses Agg for the actual painting, so this would require implementing an entire new backend, so is probably not a good choice initially. Either approach would be -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Upstream Matplotlib Qt Designer Plugin
I've included this in openSUSE's matplotlib packages, it seems to work great. -Todd On Mon, Mar 19, 2012 at 10:08 PM, Pierre Raybaut pierre.rayb...@gmail.com wrote: Hi all, Is anyone interested in including the Matplotlib QtDesigner plugin which I wrote for Python(x,y)? The code is quite simple and hasn't evolved for a while now (3 years) but apparently it is still appreciated by users even outside Python(x,y). Here are the two files which are necessary to make this plugin work: http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/matplotlibwidget.py http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/PyQt4/plugins/designer/python/matplotlibplugin.py The directory struture also has its importance: http://code.google.com/p/pythonxy/source/browse/#hg%2Fsrc%2Fpython%2Fmatplotlib%2FQtDesigner_Plugins Cheers, Pierre -- Message transféré -- De : todd rme toddrme2...@gmail.com Date : 11 mars 2012 12:14 Objet : [python(x,y)] Upstream Matplotlib Qt Designer Plugin À : python(x,y) pytho...@googlegroups.com I notice that python(x,y) has a matplotlib plugin for Qt Designer. I think this would be very helpful for general users of matplotlib outside of python(x,y). Is there any possibility of submitting this plugin upstream for inclusion with the official matplotlib release? That way people who aren't using python(x,y) (for instance Linux users who are using their official distribution python packages) could benefit from the plugin as well. Thank you very much. -Todd -- You received this message because you are subscribed to the Google Groups python(x,y) group. To post to this group, send email to pytho...@googlegroups.com. To unsubscribe from this group, send email to pythonxy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pythonxy?hl=en. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
