matplotlib-devel Mailing List for matplotlib

Oops, sorry. I realized it was actually Ben Root who suggested I start this
discussion. Don't want to put words in anyones mouth.
Nic
On Sun, Aug 12, 2012 at 11:51 PM, Nic Eggert <ns...@co...> 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.
>
> 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
>

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.
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

On 2012年08月12日 3:34 PM, Daniel Hyams wrote:
>
> I was wanting to add a feature to matplotlib...one that I would use in
> my application. I also want to contribute the feature back. I'm
> personally using version 1.1.1 of matplotlib. Disclaimer...I only know
> enough about git to be dangerous.
>
> So is it best to branch from v1.1.1, implement the feature, and then try
> to rebase to master? Or is it best to branch from master, implement the
> feature, and then (somehow) backport the patch to the v1.1.1 tagged version?
Mike answered for the case where you are making a bugfix that really 
does go in v1.1.x. I think that even there, what he is recommending is 
a bit different from what you have in mind: he is saying to branch from 
an up-to-date v1.1.x, not from v1.1.1. Similarly, for the case you have 
in mind, the pull request should be for a change relative to a recent 
enough point on the master branch that it can be merged cleanly, and 
with no unexpected side-effects.
It sounds like what you are trying to do is maintain your own branch off 
of the v1.1.1 tagged version, with only your own features added.
I don't think there is any single best way to do this; it depends on how 
you work, and on what sorts of changes you are making.
Developing your change in your feature branch off of v1.1.1 is perfectly 
reasonable, since that is where you are normally working, and that is 
where you need it to work. To propagate it upstream, you do need to 
either cherry-pick it, or reimplement it, relative to recent master. 
Re-implementing it can be simpler in some cases--easier to see what is 
going on!
I had been thinking "rebase", but this is not correct; you don't want to 
*remove* your commits from your branch off of v1.1.1, you want to 
*reproduce* them, or their net effect, in a *new* topic branch off of 
up-to-date master.
It would go something like this. Assume "upstream" is the remote 
pointing to the main mpl repo, and "origin" is your github repo. Assume 
your changes are in a topic branch called "dh_topic_stable", off of 
v1.1.1. Find the commit numbers in dh_topic_stable that you need to 
propagate, say "a0b123fed" and "df237abc".
git fetch upstream
git checkout -b dh_topic upstream/master
git cherry-pick a0b123fed df237abc
# build and test; maybe add documentation and test commits
git push origin dh_topic
Then make your pull request against mpl master.
For seeing what is in a repo, and what happens at each step of the way, 
I find qgit helpful. Invoke as "qgit --all". You need to hit the 
refresh button after each command-line git call.
Eric
>
> Whatever the best choice is, what would the procedure look like to
> accomplish this?
>
> --
> Daniel Hyams
> dh...@gm... <mailto:dh...@gm...>
>
>
> ------------------------------------------------------------------------------
> 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 08/12/2012 09:34 PM, Daniel Hyams wrote:
>
> I was wanting to add a feature to matplotlib...one that I would use in 
> my application. I also want to contribute the feature back. I'm 
> personally using version 1.1.1 of matplotlib. Disclaimer...I only 
> know enough about git to be dangerous.
>
> So is it best to branch from v1.1.1, implement the feature, and then 
> try to rebase to master? Or is it best to branch from master, 
> implement the feature, and then (somehow) backport the patch to the 
> v1.1.1 tagged version?
If something is a bugfix, I generally branch from v1.1.x (i.e. the 
maintenance branch), implement the feature, submit a pull request for 
that, which eventually gets merged into the maintenance branch. Then I 
merge the maintenance branch into master. The last step can generally 
only be done by people with write permissions to the core repository. I 
know other projects that work the other way around, but that's the way 
things have generally been done in matplotlib.
>
> Whatever the best choice is, what would the procedure look like to 
> accomplish this?
git checkout -b my_new_feature upstream/v1.1.x
... implement feature ...
git add ...files...
git commit
git push origin my_new_feature
...create a pull request on github...
...after the pull request is merged, v1.1.x gets merged into master...
Mike
>
> -- 
> Daniel Hyams
> dh...@gm... <mailto:dh...@gm...>
>
>
> ------------------------------------------------------------------------------
> 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

I was wanting to add a feature to matplotlib...one that I would use in my
application. I also want to contribute the feature back. I'm personally
using version 1.1.1 of matplotlib. Disclaimer...I only know enough about
git to be dangerous.
So is it best to branch from v1.1.1, implement the feature, and then try to
rebase to master? Or is it best to branch from master, implement the
feature, and then (somehow) backport the patch to the v1.1.1 tagged version?
Whatever the best choice is, what would the procedure look like to
accomplish this?
-- 
Daniel Hyams
dh...@gm...