From: Nic E. <ns...@co...> - 2012-08-24 00:04:27
|
Eric, you make a good point. I'm okay with that approach as well. It also has the benefit of being the least work. Nic On Thu, Aug 23, 2012 at 7:21 PM, Eric Firing <ef...@ha...> wrote: > On 2012/08/23 11:55 AM, Damon McDougall wrote: >> Hey Nic, >> >> Thanks for bringing this up. I was the author for #819, so I'd like to >> get some dicussion going on this, too. Sorry for the delay, I was in the >> midst of writing a thesis, which I am now free of. >> >> On Sun, Aug 12, 2012 at 11:51:24PM -0500, Nic Eggert wrote: >>> Hi all, >>> >>> I'd like to bring up a question spurred by PRs #847(mine) and #819 >>> (recently accepted). These PRs both deal with stacked plots. #819 adds the >>> stackplot function to axes.py as a new function, which plots different 2-d >>> datasets stacked atop each other. #847 slightly modifies the functioning of >>> `hist` in axes.py by adding a new kwarg which allows datasets to be >>> stacked. Currently this is only possible using the `barstacked` histtype. >>> #847 makes it also work with the `step` and `stepfilled` histtypes. >>> >>> One of the issues that has been raised in the comments of #847 is whether >>> we want to take this opportunity to come up with a unified way to handle >>> "stacked-ness". Michael Droettboom suggested I raise this issue on this >>> list. So far, there are 3 different approaches: >>> >>> 1. The state before #819. AFAIK the only way to do any sort of stacking was >>> to call `hist` with `histtype="barstacked"`. This treats stacked histograms >>> as a different type of histogram than non-stacked histograms. One of my >>> motivations for writing #847 was to get stacked step and stepfilled >>> histograms, which would require adding several new histtypes (stepstacked >>> and stepfilledstacked). It seems to me that histtype mostly controls the >>> style of the histogram plotted, and shouldn't have anything to do with >>> "stacked-ness", so I think this is kind of clunky. >>> >>> 2. The approach I take in #847. Add a new kwarg which controls whether or >>> not multiple datasets are stacked. I think this is the cleanest >>> implementation, although that's probably obvious because it's how I wrote >>> my PR. To keep everything consistent in this approach, we should remove the >>> stackplot function added in #819, and move that functionality to the `plot` >>> function, adding a `stacked` kwarg there. >>> >>> 3. The approach of #819. With this approach, we would add a separate >>> function to handle stacked versions of different plots. I'd re-write #847 >>> as a new function called `stackhist`. This approach, IMO, doesn't scale >>> well if we want to add "stacked-ness" to more plot types in the future. >> >> I'm in favour of numero dos, even though for #819 I took approach number >> 3. I didn't really think about the bigger picture here with regards to >> stackedness of other plot types. But since seeing your stacked histogram >> changeset, this seems like a more sensible route. >> >> I say this with zero authority, though. >> >> It'd be nice to have a few people chime in with their two cents. > > OK, here are mine: I oppose overloading plot with a "stacked" kwarg and > functionality. It is complicated enough as it is. I don't see any > problem with having "stackplot" and hist(..., stacked=True). They are > just not all that similar. Nor are "plot" and "stackplot" so very > similar. But stacked and non-stacked histograms *are* very similar, so > using the kwarg to turn on stacking there makes sense. > > Elaborating slightly: stacking in plot makes sense only when there is a > single abcissa in the data set, but plot supports inputs for which this > is not the case; that means that using a stacked kwarg would require > explaining this, and trapping invalid inputs when stacked is True. > Messy. Much neater to have a separate function. > > In the case of a histogram, there is a single set of bins, so a single > abcissa. Therefore turning on stacking only affects the way the lines > are displayed, and does not require additional input validity checking. > > > I would be cautious about looking around for more places to add a > "stacked" kwarg. Where is it really needed? Let's try to keep mpl from > getting more complicated than necessary. > > Eric > >> >>> Please take a look at this and send comments about these proposals or any >>> others you might have. I hope the community can come to a consensus which >>> unifies the handling of stacked-ness. >>> >>> Whatever we end up choosing, I think adding a stacked step histogram will >>> make it much easier to promote the use of mpl in high energy physics, where >>> we use this style of plot frequently. >>> >>> Thanks, >>> >>> Nic Eggert >>> Graduate Fellow >>> Cornell University >> >> > > > ------------------------------------------------------------------------------ > 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 |