matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Todd <tod...@gm...>]

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.

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Damon M. <dam...@gm...>]

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

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Todd <tod...@gm...>]

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

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Thomas K. <th...@kl...>]

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

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Todd <tod...@gm...>]

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.

[matplotlib-devel] print_png bug

[Oleg V. <ole...@gm...>]

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

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Michael D. <md...@st...>]

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

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Todd <tod...@gm...>]

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.

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Sandro T. <san...@gm...>]

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

[matplotlib-devel] quick bug fix

[Alexander H. <mat...@2s...>]

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

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Damon M. <dam...@gm...>]

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

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Russell E. O. <ro...@uw...>]

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

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Michael D. <md...@st...>]

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

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Michael D. <md...@st...>]

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.

Mike


On 09/24/2012 01:01 PM, Russell E. Owen wrote:
> In article <505...@st...>,
>   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:
>>
>> https://github.com/matplotlib/matplotlib/downloads
>>
>> This includes a number of important bugfixes, including things required
>> for creating Macintosh and Windows binaries.  The Travis tests are also
>> now passing.
>>
>> I hope it will be easier for the binaries to be created this time. Once
>> they are available at github, I will make an announcement to
>> matplotlib-users and hopefully get some serious testing out of this thing.
>>
>> Thanks for all of the hard work!
> I'm sorry that I missed the announcement until today -- I normally try
> to check news every day or two, but got too busy last week.
>
> I'm even more sorry to report that I can't build the 32-bit Mac OS X
> binary. I have appended the log. I suspect the issue is the need to use
> an old compiler for that python.
>
> The 64-bit Mac binary built just fine and I'm uploading it now. I have
> also appended the test results for it (which look fine to me).
>
> -- Russell
>
> Log of build failure on MacOS X 10.4 for python.org's 32-bit python 2.7
>
> d-173-250-157-131:/Archives/PythonPackages/matplotlib-1.2.0rc2 rowen$
> bdist_mpkg
> basedirlist is: ['/usr/local/', '/usr', '/usr/X11']
> ...
> gcc-4.0 -fno-strict-aliasing -fno-common -dynamic -isysroot
> /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG -g
> -O3 -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1
> -I/usr/local/include -I/usr/include -I/usr/X11/include
> -I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pa
> ckages/numpy/core/include -I/usr/local/include -I/usr/include -I.
> -I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pa
> ckages/numpy/core/include -Isrc -Iagg24/include -I.
> -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c
> src/_macosx.m -o build/temp.macosx-10.3-fat-2.7/src/_macosx.o
> src/_macosx.m: In function 'FigureCanvas_write_bitmap':
> src/_macosx.m:3557: error: request for member 'pixelsWide' in something
> not a structure or union
> src/_macosx.m:3557: error: request for member 'pixelsHigh' in something
> not a structure or union
> src/_macosx.m: In function 'FigureCanvas_write_bitmap':
> src/_macosx.m:3557: error: request for member 'pixelsWide' in something
> not a structure or union
> src/_macosx.m:3557: error: request for member 'pixelsHigh' in something
> not a structure or union
> lipo: can't figure out the architecture type of: /var/tmp//ccpc0juI.out
> error: command 'gcc-4.0' failed with exit status 1
> d-173-250-157-131:/Archives/PythonPackages/matplotlib-1.2.0rc2 rowen$
>
>
>
> Log of test results for the MacOS X 10.6 python.org 64-bit python 2.7
> build:
>
> localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
> .........................................................................
> .........................................................................
> .........SSS.K................................K..........................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> ..................................................................../Libr
> ary/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/
> matplotlib/gridspec.py:298: UserWarning: This figure includes Axes that
> are not compatible with tight_layout, so its results might be incorrect.
>    warnings.warn("This figure includes Axes that are not "
> ...............................
> ----------------------------------------------------------------------
> Ran 1194 tests in 329.568s
>
> OK (KNOWNFAIL=2, SKIP=3)
>
>
> ------------------------------------------------------------------------------
> 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

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Russell E. O. <ro...@uw...>]

In article <505...@st...>,
 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:
> 
> https://github.com/matplotlib/matplotlib/downloads
> 
> This includes a number of important bugfixes, including things required 
> for creating Macintosh and Windows binaries.  The Travis tests are also 
> now passing.
> 
> I hope it will be easier for the binaries to be created this time. Once 
> they are available at github, I will make an announcement to 
> matplotlib-users and hopefully get some serious testing out of this thing.
> 
> Thanks for all of the hard work!

I'm sorry that I missed the announcement until today -- I normally try 
to check news every day or two, but got too busy last week.

I'm even more sorry to report that I can't build the 32-bit Mac OS X 
binary. I have appended the log. I suspect the issue is the need to use 
an old compiler for that python.

The 64-bit Mac binary built just fine and I'm uploading it now. I have 
also appended the test results for it (which look fine to me).

-- Russell

Log of build failure on MacOS X 10.4 for python.org's 32-bit python 2.7

d-173-250-157-131:/Archives/PythonPackages/matplotlib-1.2.0rc2 rowen$ 
bdist_mpkg
basedirlist is: ['/usr/local/', '/usr', '/usr/X11']
...
gcc-4.0 -fno-strict-aliasing -fno-common -dynamic -isysroot 
/Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -g -O2 -DNDEBUG -g 
-O3 -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 
-I/usr/local/include -I/usr/include -I/usr/X11/include 
-I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pa
ckages/numpy/core/include -I/usr/local/include -I/usr/include -I. 
-I/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pa
ckages/numpy/core/include -Isrc -Iagg24/include -I. 
-I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c 
src/_macosx.m -o build/temp.macosx-10.3-fat-2.7/src/_macosx.o
src/_macosx.m: In function 'FigureCanvas_write_bitmap':
src/_macosx.m:3557: error: request for member 'pixelsWide' in something 
not a structure or union
src/_macosx.m:3557: error: request for member 'pixelsHigh' in something 
not a structure or union
src/_macosx.m: In function 'FigureCanvas_write_bitmap':
src/_macosx.m:3557: error: request for member 'pixelsWide' in something 
not a structure or union
src/_macosx.m:3557: error: request for member 'pixelsHigh' in something 
not a structure or union
lipo: can't figure out the architecture type of: /var/tmp//ccpc0juI.out
error: command 'gcc-4.0' failed with exit status 1
d-173-250-157-131:/Archives/PythonPackages/matplotlib-1.2.0rc2 rowen$



Log of test results for the MacOS X 10.6 python.org 64-bit python 2.7 
build:

localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
.........................................................................
.........................................................................
.........SSS.K................................K..........................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
..................................................................../Libr
ary/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/
matplotlib/gridspec.py:298: UserWarning: This figure includes Axes that 
are not compatible with tight_layout, so its results might be incorrect.
  warnings.warn("This figure includes Axes that are not "
...............................
----------------------------------------------------------------------
Ran 1194 tests in 329.568s

OK (KNOWNFAIL=2, SKIP=3)

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Damon M. <dam...@gm...>]

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

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Nathaniel S. <nj...@po...>]

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

-n

Re: [matplotlib-devel] New plot type idea -- EventRaster

[Todd <tod...@gm...>]

On Mon, Sep 24, 2012 at 3:51 PM, Nathaniel Smith <nj...@po...> wrote:
> On Mon, Sep 24, 2012 at 2:33 PM, Todd <tod...@gm...> 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.

[matplotlib-devel] New plot type idea -- EventRaster

[Todd <tod...@gm...>]

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.

Re: [matplotlib-devel] process for getting a new plot type added

[Michael D. <md...@st...>]

We welcome all volunteers!

The threshold for what requires a MEP is somewhat fuzzy, but generally 
it's for things in the core that affect the system as a whole.  Why 
don't you just start discussing your thoughts and plans here and we can 
discuss the best way forward.

Mike

On 09/24/2012 06:17 AM, Todd wrote:
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Michael D. <md...@st...>]

Thanks for pointing this out.  It should now be fixed.

On 09/22/2012 01:55 PM, Damon McDougall wrote:
> On Wed, Sep 19, 2012 at 6: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:
>>
>> https://github.com/matplotlib/matplotlib/downloads
>>
>> This includes a number of important bugfixes, including things required
>> for creating Macintosh and Windows binaries.  The Travis tests are also
>> now passing.
>>
>> I hope it will be easier for the binaries to be created this time. Once
>> they are available at github, I will make an announcement to
>> matplotlib-users and hopefully get some serious testing out of this thing.
>>
>> Thanks for all of the hard work!
>>
>> Mike
> The website says the current development version is rc1.
>

[matplotlib-devel] process for getting a new plot type added

[Todd <tod...@gm...>]

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.

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Damon M. <dam...@gm...>]

On Wed, Sep 19, 2012 at 6: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:
>
> https://github.com/matplotlib/matplotlib/downloads
>
> This includes a number of important bugfixes, including things required
> for creating Macintosh and Windows binaries.  The Travis tests are also
> now passing.
>
> I hope it will be easier for the binaries to be created this time. Once
> they are available at github, I will make an announcement to
> matplotlib-users and hopefully get some serious testing out of this thing.
>
> Thanks for all of the hard work!
>
> Mike

The website says the current development version is rc1.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] Custom plot_trisurf triangulations

[Damon M. <dam...@gm...>]

On Sat, Sep 22, 2012 at 10:40 AM, Damon McDougall
<dam...@gm...> wrote:
> Ah ok, I see. I was assuming a plot_trisurf(x, y, z, triangles, ...)
> signature. Copying the tricontour signature would be better for
> consistency reasons. It appears that I was the one missing something!

I just realised I'm not making any sense here. Please disregard most
of what I say.

I'm using the get_from_args_and_kwargs method and everything is fine.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] Custom plot_trisurf triangulations

[Damon M. <dam...@gm...>]

On Fri, Sep 21, 2012 at 2:38 PM, Benjamin Root <ben...@ou...> wrote:
> I wouldn't be against going down a deprecation path for renaming these
> functions, but for what gains?  The names have been there since before I
> took up this toolkit, and ultimately, these functions aren't typed so often
> that brevity would gain one much.  Definitely any new functions should not
> take up that naming, but I see no real compelling reason to change the
> existing names.

Technically, 1.2 hasn't been released yet. We can still change
plot_trisurf to trisurf, though it appears there is still uncertainty
regarding whether there will actually be a third release candidate.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom