matplotlib-devel Mailing List for matplotlib

On 2012年09月30日 7:14 AM, Michael Droettboom wrote:
> On 09/29/2012 08:07 PM, Eric Firing wrote:
>> Mike,
>>
>> I'm getting confused about branch merge strategy. Usually, it seems
>> that it has been to periodically merge the maintenance branch into
>> master. Something like this:
>>
>> git fetch upstream
>> git checkout master
>> git merge --ff-only upstream/master
>> git merge upstream/v1.2.x
>> # test, commit changes if necessary
>> git push upstream master
>>
>> Is that correct?
>>
>> At present, however, we seem to be developing fairly long separate
>> threads on the two branches, with duplicate changesets, presumably
>> from cherry-picking. Is this intentional? Do you plan to go back to
>> the merge strategy?
>
> A few things were cherry-picked over to 1.2.x, since the PR was
> initially set up against master and github doesn't provide a way to
> change the destination of a PR after creating it. But that was meant to
> be the exception... the "preferred" way hasn't changed.
>
>>
>> I can see that a problem with branch merging is that there are
>> occasionally changesets in v1.2.x, such as the rc version tagging,
>> that are not appropriate for master.
> Tags don't merge across branches because tags are just pointers to
> particular commit hashes. When doing a merge, you always get a new
> commit hash (since the parents are different). As for updating the
> version number, however, yes, those changes need to be manually
> addressed -- though it usually shows up as a merge conflict, so it's
> obvious that it needs to be done.
Mike,
Thanks. I have performed the merge of v1.2.x into master, and I think 
everything is OK; the changes reflect only the commits that were not 
cherry-picked. I also reverted what I think was an inadvertent version 
change in master, so now it is back to 1.3.x.
Eric
>
> Mike

On 09/29/2012 08:07 PM, Eric Firing wrote:
> Mike,
>
> I'm getting confused about branch merge strategy. Usually, it seems 
> that it has been to periodically merge the maintenance branch into 
> master. Something like this:
>
> git fetch upstream
> git checkout master
> git merge --ff-only upstream/master
> git merge upstream/v1.2.x
> # test, commit changes if necessary
> git push upstream master
>
> Is that correct?
>
> At present, however, we seem to be developing fairly long separate 
> threads on the two branches, with duplicate changesets, presumably 
> from cherry-picking. Is this intentional? Do you plan to go back to 
> the merge strategy?
A few things were cherry-picked over to 1.2.x, since the PR was 
initially set up against master and github doesn't provide a way to 
change the destination of a PR after creating it. But that was meant to 
be the exception... the "preferred" way hasn't changed.
>
> I can see that a problem with branch merging is that there are 
> occasionally changesets in v1.2.x, such as the rc version tagging, 
> that are not appropriate for master.
Tags don't merge across branches because tags are just pointers to 
particular commit hashes. When doing a merge, you always get a new 
commit hash (since the parents are different). As for updating the 
version number, however, yes, those changes need to be manually 
addressed -- though it usually shows up as a merge conflict, so it's 
obvious that it needs to be done.
Mike

Mike,
I'm getting confused about branch merge strategy. Usually, it seems 
that it has been to periodically merge the maintenance branch into 
master. Something like this:
git fetch upstream
git checkout master
git merge --ff-only upstream/master
git merge upstream/v1.2.x
# test, commit changes if necessary
git push upstream master
Is that correct?
At present, however, we seem to be developing fairly long separate 
threads on the two branches, with duplicate changesets, presumably from 
cherry-picking. Is this intentional? Do you plan to go back to the 
merge strategy?
I can see that a problem with branch merging is that there are 
occasionally changesets in v1.2.x, such as the rc version tagging, that 
are not appropriate for master.
Eric

Forgot to reply all.
---------- Forwarded message ----------
From: Damon McDougall <dam...@gm...>
Date: Sat, Sep 29, 2012 at 8:51 PM
Subject: Re: [matplotlib-devel] Python 3.3 released
To: Benjamin Root <ben...@ou...>
On Sat, Sep 29, 2012 at 6:46 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Saturday, September 29, 2012, Christoph Gohlke wrote:
>>
>> On 9/29/2012 9:48 AM, Damon McDougall wrote:
>> > I've just read that Python 3.3 has been
>> > released<http://python.org/download/releases/3.3.0/> and thought I
>> > would initiate a discussion oriented around adoption and possible
>> > benefits/problems. It appears that, at least for the Mac, there are
>> > issues with certain versions of
>> > ActiveTcl<http://www.python.org/download/mac/tcltk/>. I have no
>> > experience with this, so I can't really comment further.
>> >
>>
>> All tests pass with matplotlib-1.2.0rc2.win-amd64-py3.3.
>>
>> Christoph
>>
>
> I wouldnt expect less. The question is if the TkAgg still works with
> ActiveTcl on the Mac?
>
> Ben Root
I almost never use the GUI stuff in mpl. When I do, it's almost always
the Qt4 backend or the OS X backend. I have never gotten the Tk
backend to work. It always errors out with after popping up a window
(with no plot in it) and fails very gracefully with a TclError, giving
no indication of what Tcl didn't like.
I think Phil is a Tk-er.
--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Saturday, September 29, 2012, Christoph Gohlke wrote:
> On 9/29/2012 9:48 AM, Damon McDougall wrote:
> > I've just read that Python 3.3 has been
> > released<http://python.org/download/releases/3.3.0/> and thought I
> > would initiate a discussion oriented around adoption and possible
> > benefits/problems. It appears that, at least for the Mac, there are
> > issues with certain versions of
> > ActiveTcl<http://www.python.org/download/mac/tcltk/>. I have no
> > experience with this, so I can't really comment further.
> >
>
> All tests pass with matplotlib-1.2.0rc2.win-amd64-py3.3.
>
> Christoph
>
>
I wouldnt expect less. The question is if the TkAgg still works with
ActiveTcl on the Mac?
Ben Root

On 9/29/2012 9:48 AM, Damon McDougall wrote:
> I've just read that Python 3.3 has been
> released<http://python.org/download/releases/3.3.0/> and thought I
> would initiate a discussion oriented around adoption and possible
> benefits/problems. It appears that, at least for the Mac, there are
> issues with certain versions of
> ActiveTcl<http://www.python.org/download/mac/tcltk/>. I have no
> experience with this, so I can't really comment further.
>
All tests pass with matplotlib-1.2.0rc2.win-amd64-py3.3.
Christoph

I've just read that Python 3.3 has been
released<http://python.org/download/releases/3.3.0/> and thought I
would initiate a discussion oriented around adoption and possible
benefits/problems. It appears that, at least for the Mac, there are
issues with certain versions of
ActiveTcl<http://www.python.org/download/mac/tcltk/>. I have no
experience with this, so I can't really comment further.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On 2012年09月27日 7:13 PM, Alexander Heger wrote:
> I am not sure what I need to do to get any bug fixes included into mpl.
The most efficient way is with a pull request. And perhaps a little 
patience combined with persistence.
> All previous attempts failed.
> Is it a community effort?
Yes, but that doesn't mean that every suggested change will be accepted, 
or even reviewed right away.
>
> I now attached a patch.
Thank you.
I will comment on github.
https://github.com/matplotlib/matplotlib/issues/1317
Eric
>
> -Alexander
>
> On 25/09/12 23:58, Alexander Heger wrote:
>> Could you please change in the current branch in
>>
>> axes.py, line 7585
>> (Axes.pcolorfast)
>>
>>
>> nr, nc = C.shape
>> to
>> nr, nc = C.shape[:2]
>>
>>
>> this way one can pass [nx,ny,3] or [nx,ny,4] arrays to the routine - for
>> which the PcolorImage it calls is made (style == "pcolorimage")
>>
>> -Alexander

I am not sure what I need to do to get any bug fixes included into mpl.
All previous attempts failed.
Is it a community effort?
I now attached a patch.
-Alexander
On 25/09/12 23:58, Alexander Heger wrote:
> Could you please change in the current branch in
>
> axes.py, line 7585
> (Axes.pcolorfast)
>
>
> nr, nc = C.shape
> to
> nr, nc = C.shape[:2]
>
>
> this way one can pass [nx,ny,3] or [nx,ny,4] arrays to the routine - for
> which the PcolorImage it calls is made (style == "pcolorimage")
>
> -Alexander
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Thu, Sep 27, 2012 at 1:44 PM, Todd <tod...@gm...> wrote:
> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
> <dam...@gm...> 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 of creating a new collection type is that artists will
> be able to manipulate individual sets of events.
>
> For example, with an ordinary LineCollection it will be extremely
> difficult to change the marker type, since doing so will change the
> marker for all 3 points on each segment rather than just the middle
> point. So if someone makes the plot, than wants to set rows to have
> different marker types instead of being lines, they can do that if we
> use a new collection class. But if we use LineCollection this becomes
> much more difficult.
>
> Similarly, with a LineCollection the lines lose their status as
> objects with a single distinct position. They become objects with 3
> 2D coordinates. So if someone wants to add more events to the end,
> they need to take care of handling the x and y coordinates, making
> sure the x coordinates are the same and taking the y coordinates from
> one of the existing lines. Similarly changing the height or vertical
> position of all the objects is complicated, having to manually
> calculate and modify the y coordinates of each point in each segment.
>
> Again, the idea here is to make the most common use-cases as easy as
> possible. LineCollection objects aren't really suited to the sort of
> artistic changes that are typical with this sort of plot.
>
> In fact I would say that having a separate collection class is central
> to this idea. If users aren't able to manipulate the set of events as
> such after they create the plot, then there really isn't any advantage
> over just using a vlines plot. Calculating the ymin and ymax is one
> line of code each, it is the artistic changes that save many lines of
> code and a lot of complexity.
I would also like to add that the new collection object would be
useful outside of this plot type.
For example if someone wanted to create a rug plot as Nathaniel
described, and they want those along the same axes as the main plot,
then they would most likely not be be using the plot function, but
rather creating two individual collection objects in an existing
figure.
I can imagine other cases besides a strict rug plot where adding such
a collection object could be useful.

On Thu, Sep 27, 2012 at 2:17 PM, Damon McDougall
<dam...@gm...> wrote:
> On Thu, Sep 27, 2012 at 12:44 PM, Todd <tod...@gm...> wrote:
>> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
>> <dam...@gm...> 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

On Thu, Sep 27, 2012 at 12:44 PM, Todd <tod...@gm...> wrote:
> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
> <dam...@gm...> 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.
>
>> 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 of creating a new collection type is that artists will
> be able to manipulate individual sets of events.
>
> For example, with an ordinary LineCollection it will be extremely
> difficult to change the marker type, since doing so will change the
> marker for all 3 points on each segment rather than just the middle
> point. So if someone makes the plot, than wants to set rows to have
> different marker types instead of being lines, they can do that if we
> use a new collection class. But if we use LineCollection this becomes
> much more difficult.
>
> Similarly, with a LineCollection the lines lose their status as
> objects with a single distinct position. They become objects with 3
> 2D coordinates. So if someone wants to add more events to the end,
> they need to take care of handling the x and y coordinates, making
> sure the x coordinates are the same and taking the y coordinates from
> one of the existing lines. Similarly changing the height or vertical
> position of all the objects is complicated, having to manually
> calculate and modify the y coordinates of each point in each segment.
>
> Again, the idea here is to make the most common use-cases as easy as
> possible. LineCollection objects aren't really suited to the sort of
> artistic changes that are typical with this sort of plot.
>
> In fact I would say that having a separate collection class is central
> to this idea. If users aren't able to manipulate the set of events as
> such after they create the plot, then there really isn't any advantage
> over just using a vlines plot. Calculating the ymin and ymax is one
> line of code each, it is the artistic changes that save many lines of
> code and a lot of complexity.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
<dam...@gm...> 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 of creating a new collection type is that artists will
be able to manipulate individual sets of events.
For example, with an ordinary LineCollection it will be extremely
difficult to change the marker type, since doing so will change the
marker for all 3 points on each segment rather than just the middle
point. So if someone makes the plot, than wants to set rows to have
different marker types instead of being lines, they can do that if we
use a new collection class. But if we use LineCollection this becomes
much more difficult.
Similarly, with a LineCollection the lines lose their status as
objects with a single distinct position. They become objects with 3
2D coordinates. So if someone wants to add more events to the end,
they need to take care of handling the x and y coordinates, making
sure the x coordinates are the same and taking the y coordinates from
one of the existing lines. Similarly changing the height or vertical
position of all the objects is complicated, having to manually
calculate and modify the y coordinates of each point in each segment.
Again, the idea here is to make the most common use-cases as easy as
possible. LineCollection objects aren't really suited to the sort of
artistic changes that are typical with this sort of plot.
In fact I would say that having a separate collection class is central
to this idea. If users aren't able to manipulate the set of events as
such after they create the plot, then there really isn't any advantage
over just using a vlines plot. Calculating the ymin and ymax is one
line of code each, it is the artistic changes that save many lines of
code and a lot of complexity.

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. Anyway, I hope you'll find my comments
helpful at the least. I also encourage others to weigh in with
opinions and ideas.
> 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'?
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.
> 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.
Good. I like this.
> 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. 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.
> 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.
Fair enough; sensible defaults.
> **kargs are the same as those of plot().
Good. I like this modular approach.
> 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.
> 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.
Me neither.
> 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.
> 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).
> Internally, the lines will be length 3 Line2D objects, with the 3
> points being offset-.5*height, offset, and offset+.5*height.
>
> So what does everyone think of this approach? Does anyone have any
> comments, suggestions, or just think the approach is nonsense? It
> would certainly be possible to implement this based more on existing
> classes, but I don't think the implementation would be as clean, as
> maintainable, or as extensible as this implementation.
I hope these comments are useful.
Best,
Damon
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Thu, Sep 27, 2012 at 12:58 PM, Thomas Kluyver <th...@kl...> wrote:
> On 27 September 2012 11:41, Todd <tod...@gm...> 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

On 27 September 2012 11:41, Todd <tod...@gm...> 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. From the examples linked earlier in the thread, I'd
call it something like EventStrip.
Thanks,
Thomas

On Wed, Sep 26, 2012 at 3:14 PM, Michael Droettboom <md...@st...> wrote:
> On 09/26/2012 04:35 AM, Todd wrote:
>
> On Mon, Sep 24, 2012 at 3:33 PM, Todd <tod...@gm...> 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 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.
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.
Internally, the lines will be length 3 Line2D objects, with the 3
points being offset-.5*height, offset, and offset+.5*height.
So what does everyone think of this approach? Does anyone have any
comments, suggestions, or just think the approach is nonsense? It
would certainly be possible to implement this based more on existing
classes, but I don't think the implementation would be as clean, as
maintainable, or as extensible as this implementation.

There is an annoying bug in print_png (a'm using 1.1.0).
After saving figure it just stops redrawing on screen (gdk). It happens
because the print_png calls the set_pixmap method of the canvas renderer
which change the associated drawable forever. I'm using workaround saving
canvas._renderer.gdkDrawable and restoring it after print_png call. Woud be
nice to fix it in the upcoming release if possible.
Regards,
 Oleg Volkov

On 09/26/2012 04:35 AM, Todd wrote:
> On Mon, Sep 24, 2012 at 3:33 PM, Todd <tod...@gm... 
> <mailto:tod...@gm...>> 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.
Cheers,
Mike

On Mon, Sep 24, 2012 at 3:33 PM, Todd <tod...@gm...> 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.

Hi,
On Wed, Sep 19, 2012 at 7:53 PM, Michael Droettboom <md...@st...> wrote:
> I have tagged and created a tarball for 1.2.0rc2. The githash is
> 656c88f3e546. The tarball is on the github download page here:
I've noticed that running the tests with the debug flavor of python
2.6 and 2.7 makes the interpreter crash: I've reported
https://github.com/matplotlib/matplotlib/issues/1309 which seems
similar to https://github.com/matplotlib/matplotlib/pull/1054
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Could you please change in the current branch in
axes.py, line 7585
(Axes.pcolorfast)
 nr, nc = C.shape
to
 nr, nc = C.shape[:2]
this way one can pass [nx,ny,3] or [nx,ny,4] arrays to the routine - for 
which the PcolorImage it calls is made (style == "pcolorimage")
-Alexander

On Mon, Sep 24, 2012 at 7:23 PM, Russell E. Owen <ro...@uw...> wrote:
> In article <506...@st...>,
> Michael Droettboom <md...@st...>
> wrote:
>
>> For the compilation problem, I am no Objective-C expert, but in C, line
>> 3557 should certainly read:
>>
>> NSSize pxlSize = NSMakeSize(rep->pixelsWide, rep->pixelsHigh);
>>
>> I wonder if that fixes it -- but that's a total stab in the dark. This
>> was a part of the code that was changed quite recently.
>
> I opened issue #1304
> <https://github.com/matplotlib/matplotlib/issues/1304>
> but did not append your comment.
Fixed in https://github.com/matplotlib/matplotlib/pull/1305.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

In article <506...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> For the compilation problem, I am no Objective-C expert, but in C, line 
> 3557 should certainly read:
> 
> NSSize pxlSize = NSMakeSize(rep->pixelsWide, rep->pixelsHigh);
> 
> I wonder if that fixes it -- but that's a total stab in the dark. This 
> was a part of the code that was changed quite recently.
I opened issue #1304 
<https://github.com/matplotlib/matplotlib/issues/1304>
but did not append your comment.
-- Russell

On 09/24/2012 11:33 AM, Damon McDougall wrote:
> On Mon, Sep 24, 2012 at 2:05 PM, Michael Droettboom <md...@st...> wrote:
>> Thanks for pointing this out. It should now be fixed.
>>
> Nope, it still says 1.2.0rc1: http://matplotlib.org
>
Obviously my git skills are down today. Should be up there now.
Mike