Re: [matplotlib-devel] New plot type idea -- EventRaster
On Wed, Sep 26, 2012 at 3:14 PM, Michael Droettboom wrote: > On 09/26/2012 04:35 AM, Todd wrote: > > On Mon, Sep 24, 2012 at 3:33 PM, Todd 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 woul
Re: [matplotlib-devel] New plot type idea -- EventRaster
On 27 September 2012 11:41, Todd 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 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 12:58 PM, Thomas Kluyver wrote: > On 27 September 2012 11:41, Todd wrote: >> I would prefer to get the details worked out before I start coding >> since there are a few different approaches. First thing is to figure >> out a good name, I am not sure this is the best name for it. > > As someone from a field that doesn't regularly use that sort of plot, > 'raster' seems an odd name - it doesn't seem to relate to raster vs. > vector graphics. That was exactly my concern. > From the examples linked earlier in the thread, I'd > call it something like EventStrip. The problem is it isn't really a strip either, since it can have many rows of events. It could be EventStrips, though. Some other possibilities that occured to me: EventPlot EventsPlot SequencePlot SequencesPlot Events1D Sequences1D -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
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 > w
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall 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_linec
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 12:44 PM, Todd wrote: > On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall > 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
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 2:17 PM, Damon McDougall wrote: > On Thu, Sep 27, 2012 at 12:44 PM, Todd wrote: >> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall >> wrote: >>> Hi Todd, >>> >>> Firstly, thanks for taking the time to crystallise your thoughts in >>> words first. This is one of my bad habits; I tend to rush into things. >>> >>> I have some feedback for you, hopefully we can all work together to >>> get this right. It's difficult when something new gets implemented and >>> someone expects it to do something and the only way to resolve it is >>> to break the calling API. >> >> Where is API broken? > > Nowhere. I wasn't implying you were breaking something. My point was > that it's easy to add functionality but hard to remove it, therefore > it's important to get it right from the outset. I'm sorry for the > misunderstanding; I wasn't clear. No problem. I put a lot of other comments inline in my reply to your email, but your mail reader might have cut them off. -Todd -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 1:44 PM, Todd wrote: > On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall > 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 'cons
Re: [matplotlib-devel] quick bug fix
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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >From e555f98ca915eb89c7df1cff21261efb506fc29a Mon Sep 17 00:00:00 2001 From: Alexander Heger Date: Fri, 28 Sep 2012 15:08:27 +1000 Subject: [PATCH] BF - fix pcolor fast to allow direct color --- lib/matplotlib/axes.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/matplotlib/axes.py b/lib/matplotlib/axes.py index 56017a2..6a4a87d 100644 --- a/lib/matplotlib/axes.py +++ b/lib/matplotlib/axes.py @@ -7582,7 +7582,7 @@ class Axes(martist.Artist): if norm is not None: assert(isinstance(norm, mcolors.Normalize)) C = args[-1] -nr, nc = C.shape +nr, nc = C.shape[:2] if len(args) == 1: style = "image" x = [0, nc] -- 1.7.11.4 -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] quick bug fix
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 -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
