matplotlib-devel Mailing List for matplotlib

[...]
 > > On Mon, Sep 24, 2012 at 3:33 PM, Todd <toddrjen@...> 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 m.o...@ja...
Campus Ring 1 ol...@me... 
28759 Bremen, Germany http://math.jacobs-university.de/oliver
---------------------------------------------------------------------

On 12 November 2012 20:52, Benjamin Root <ben...@ou...> wrote:
> There are other git workflows, which are all perfectly valid. If you can
> convince us to use another, feel free to propose one. However, we have
> done a couple of releases with gitwash, and it has worked quite well for us
> given how small our maintenance overhead is. Just have to remember to
> regularly merge the maintenance branch to master. That's all.
For what it's worth, what Paul describes is essentially the process we use
in IPython. All pull requests target master, and critical fixes are
backported if we decide we're going to do another maintenance release. This
is easier for contributors, because all pull requests work the same way,
but I think it does take some time for someone to go through the issues
tagged for backporting and cherry-pick the commits. Min tackled that for
our recent maintenance releases.
We use pull request testing to keep master reasonably stable, although we
don't make any promises about it.
Best wishes,
Thomas