Re: [matplotlib-devel] New plot type idea -- EventRaster
[...] > > On Mon, Sep 24, 2012 at 3:33 PM, Todd wrote: [...] > >> 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. [...] > 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. Dear Todd, I saw your posts on this idea with interest. I recently had similar, but more intricate plotting needs and came up with a brute-force solution calling "barh" for each of the vertical bars. It is attached. It is not "nice" code because it mixes program logic, visual tweaks, and plotting, but maybe you can take it as an example of what can already be done and should probably be wrapped in a clean API. This is already a simplified stand-along version, there is a more involved production code behind. It is a timing graph (that's what I think of, maybe "timing" could be an appropriate name as I too agree that "raster" is a bit confusing) of events with the following requirements: - An event has a start and a finish (or, equivalently, a start and a duration), so the vertical bars must be drawn with varying widths. - The bars may be colored differently (in the concrete application, the color scheme was green/yellow/red with green for tasks which are processed in their allocated time slice, yellow for the overrun into the next slice, and red (not show in example below) if allowable delay tolerances are violated; it is easy to imagine very different applications and coloring schemes). - The bars may have different vertical heights (in the application representing channel capacities; in the attached example they are all the same, but in general they might be different); it is easy to imagine applications (maybe like the "rug plots" mentioned in the thread) where the vertical height of individual bars needs to be specified. - There are discrete clock ticks which are indicated by vertical grid lines. I am not sure if this gets too general, but maybe it makes sense to fold some or all of the above into the API of what you are working on. With best regards, Marcel PS.: I initially sent a post like this one from a wrong email address, so it got stuck in moderation. It appears that sadly John Hunter is still moderating the list, so it will probably never get approved. If someone else has access to moderation, please just cancel that post, it's the same in different words. I blew my one chance to cancel it and now am stuck with an invalid confirmation URL for the list server. - Marcel Oliver Phone: +49-421-200-3212 School of Engineering and Science Fax: +49-421-200-3103 Jacobs University [email protected] Campus Ring 1 [email protected] 28759 Bremen, Germany http://math.jacobs-university.de/oliver - <> timing.py Description: Binary data -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples
Tony Yu writes: > MEP 12 outlines the reorganization of the example gallery and > subsequent clean up of the examples: > > https://github.com/matplotlib/matplotlib/wiki/MEP12 Dear all, thanks for this initiative. As a user who has done a fair amount of tweaking for publication-quality graphics, but who cannot claim to have a deep understanding of the overall architecture of matplotlib, the gallery has long been on my radar as something in need of improvement. I believe that the MEP goes in the right direction, but I could see some more radical changes as well. Independent of ordering by topic, I see three categories of examples: 1. API documentation/illustration of basic functionality 2. HOWTO: task driven examples (how to create a certain type of graph, how to perform a certain useful tweak) 3. Showcases (complete projects of typically higher complexity than the above, code could also contain substantial sections which are related to data-generation, preparation, or simulation) For the category 1 examples, the examples are really part of the API documentation and the gallery is just a thumbnail view which makes it easier to use eye-ball navigation through the matplotlib documentation. I believe this is already how it works today, but it's not really clear from the structure of the gallery. The category 1 examples should be clearly recognizable as views into a more comprehensive document and also given some structure (by stating function/methods to whose documentation they are attached, for example, and/or by the categories outlined in the MEP). For the category 2 examples, one needs to think in terms of the workflow. This will likely need to grow as new tasks and problems come to peoples attention, so just a very superficial selection of topics which have come across in my own work: - How do I change the text size of the legend (or of labels, etc.) - How do I make matplotlib use only one marker symbol in the legend (because each symbols refers not to a graph of something, but to a unique point in the graph) - How to I plot labels and ticks on both sides (or top and bottom) of the coordinate system? - How do I use (and properly label) a logarithmically scaled color scale? - How can I label the axes in imshow logarithmically? - How do I produce a QQ-plot? - How do I produce figures such that the font size, when included into a TeX document, matches the font size of the text? - How do I mask invalid regions in imshow()? Here, I believe it would be important that the examples are accompanied by explanatory text. Sometimes these tricks are obvious from the code itself, but sometimes a more high-level explanation would really help a lot. For category 3, I would only take examples of exceptional quality, and also, if possible, with explanation of the task, of solution strategies, and possibly references to publications where the output has appeared (on wikipedia, there seem to be a good number of high quality plots which appear to come from matplotlib but which do not have source code attached, so some cross-linking could be worthwhile). The last item of concern to me is the quality of gallery pictures. While there are excellent examples, most have more or less glaring deficiencies. Some issues appear to point to bugs or at least limitations of matplotlib itself. What is absolutely necessary is a very critical review. Let me just pick a more or less randomly chosen gallery item, sankey_demo_basics.py: - Annotations run into each other, into the flow graph, and into the coordinate frame - Distance of annotations to flow graph inconsistent and often too small - About half way between the label "0.6" and "0.15", the boundary of the flow graph appears to be double-printed with a slightly thicker line. - On the third plot, the flow graph seems down-shifted and the legend is cramped I could easily come up with similar lists of very many of the other graphs (in fact, I might even volunteer to do this systematically if there is a process on how to file and document such observations so that the effort could not get lost). Another effort should be to remove redundancy, the question should always be "is this the best way to demonstrate this feature", if there is a better way, the inferior one should be removed. The gallery has already reached a size where finding things is difficult, so the overall growth should be in quality, not in quantity. Just my 2 cents... As I said, I would be willing to help out mainly with reviewing. Regards, Marcel --------- Marcel Oliver Phone: +49-421-200-3212 School of Engineering and Science Fax: +49-421-200-3103 Jacobs University [email protected] Campus Ring 1 oli...@mem
Re: [matplotlib-devel] MEP12: Reorganize example gallery and clean up examples
Paul Hobson writes: > On Wed, Dec 12, 2012 at 5:59 AM, Michael Droettboom wrote: > > http://matplotlib.org/examples/api/clippath_demo.html > > It's perfectly reasonable code, but seems strange that it's > clipped off to the corner which I think makes it less useful as > an example. > > If I understand correctly, you're proposing that that such an > example would be deleted after a more practical example was > available to replace it? > > While I'm 100% in favor of "cleaning out the closet", I used this exact > example two days ago to clip a depressed groundwater surface to a landfill > boundary :) There is one small issue with the example: If one is using imshow on random pixel data, there is not reason to use bilinear interpolation (which is what imshow defaults to). "nearest" is the only reasonable choice. I know this sounds pedantic, but it irks me as a numerical analyst... --Marcel -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SciPy 2013
Benjamin Root writes: > On Mon, Mar 25, 2013 at 12:46 PM, Phil Elson wrote: > > >I am putting together a beginners tutorial proposal that I will submit > soon > > That's great to hear! Are you planning on making the tutorial material > part of mpl's docs or using the content that is already out there? > > It is all new stuff, but I have been taking inspirations from other tutorials > I have seen and said to myself "You are all teaching it wrong!" :-P > > I am ignoring pylab (risky, I know), starting with a *very* basic NumPy > primer, and then moving on to teach matplotlib from the perspective of "here > are what the parts of a plot are called and what they are for, and see what > happens when we put those parts together". It is an ingredients approach, > essentially. Just for the record: over the last few years I have assembled a document which is more a collection of facts and tricks on Numpy/Scipy/Matplotlib which seems orthogonal to your goals. I am trying to get students in numerical analysis or similar courses operational as quickly as possible. So I am taking pylab as a baseline. (So really a Matlab replacement, although most students will not have had any close contact with Matlab...) Any comments are welcome. Some more nice matplotlib examples are on my wish list, but I have not found time yet... PDF: http://math.jacobs-university.de/oliver/teaching/numpy-intro/numpy-intro.pdf HTML: http://math.jacobs-university.de/oliver/teaching/numpy-intro/numpy-intro/index.html Sources: http://math.jacobs-university.de/oliver/teaching/numpy-intro/ I have been argued back and forth with myself whether I should make it more pythonic (as most of the "official" matplotlib examples are), but then on the ground where class time is precious, I came to appreciate the simplicity of pylab-style code. Regards, Marcel - Marcel Oliver Phone: +49-421-200-3212 School of Engineering and Science Fax: +49-421-200-3103 Jacobs University [email protected] Campus Ring 1 [email protected] 28759 Bremen, Germany http://math.jacobs-university.de/oliver - -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
