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 ------------------------------------------------------------------------------ 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
