matplotlib-devel Mailing List for matplotlib (Page 2)

On Mon, Aug 27, 2012 at 01:26:49PM -0400, Michael Droettboom wrote:
> I'm not sure this is a bug. The transformation is being applied in data 
> space, and then the mapping to physical space is not square in the x and 
> y dimensions.
> 
> I think calling set_aspect('equal') on the axes should fix this -- if it 
> doesn't, that's indeed a bug.
>
Awesome, it worked. Honestly, I probably should have realised that when
you don't have square axes, right angles are no longer right angles:
noob error. Apologies.
> 
> Mike
> 
> On 08/27/2012 01:05 PM, Damon McDougall wrote:
> > My cherubs,
> >
> > With my new found free time, I may have discovered a sneaky bug to which
> > you are not aware. Unless, of course, my example code is incorrect.
> >
> > I do normal setup:
> >
> > from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
> > from matplotlib.figure import Figure
> > from matplotlib.patches import Rectangle
> > from matplotlib.transforms import Affine2D
> >
> > fig = Figure()
> > canvas = FigureCanvas(fig)
> > ax = fig.add_subplot(1, 1, 1)
> >
> > # Make a sexy rectangle at the origin
> > r = Rectangle((0.0, 0.0), 0.6, 0.4)
> >
> > # Construct a mind-blowing transformation: rotation by 30 degrees
> > t = Affine2D().rotate_deg(30.0)
> >
> > # Make sure to add in the already-known axes data transformation
> > t += ax.transData
> >
> > # Rotate that shizzle
> > r.set_transform(t)
> >
> > # Plottify
> > ax.add_patch(r)
> >
> > fig.savefig('my_awesome_TRAPEZIUM.pdf')
> >
> > Or you can look at my output here: http://i.imgur.com/2l439.png
> >
> > Rotation by 30 degrees is an angle-preserving linear transformation. So
> > this shouldn't happen.
> >
> > Here's what's messing shiz up: the figure dimensions are not square.
> > Look what happens when I use a square figure and make the axes fit
> > exactly to the figure dimensions:
> >
> > ...
> > fig = Figure((4, 4))
> > ...
> > ax = fig.add_axes([0, 0, 1, 1])
> > ...
> > ...
> > fig.savefig('my_awesome_RECTANGLE.pdf')
> >
> > You can see the output here: http://i.imgur.com/baXiH.png
> >
> > Boom.
> >
> > I have no idea how to fix it. I came across it while trying to address
> > https://github.com/matplotlib/matplotlib/issues/987 but it may or may
> > not also be related to
> > https://github.com/matplotlib/matplotlib/issues/1113
> >
> > Let me know if it's worth putting in github issue. I'm dont want to
> > create a duplicate ticket should it transpire that this problem is
> > actually #1113 in disguise.
> >
> > Best,
> > Damon
> >
> 
> 
> ------------------------------------------------------------------------------
> 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
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

I'm not sure this is a bug. The transformation is being applied in data 
space, and then the mapping to physical space is not square in the x and 
y dimensions.
I think calling set_aspect('equal') on the axes should fix this -- if it 
doesn't, that's indeed a bug.
Mike
On 08/27/2012 01:05 PM, Damon McDougall wrote:
> My cherubs,
>
> With my new found free time, I may have discovered a sneaky bug to which
> you are not aware. Unless, of course, my example code is incorrect.
>
> I do normal setup:
>
> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
> from matplotlib.figure import Figure
> from matplotlib.patches import Rectangle
> from matplotlib.transforms import Affine2D
>
> fig = Figure()
> canvas = FigureCanvas(fig)
> ax = fig.add_subplot(1, 1, 1)
>
> # Make a sexy rectangle at the origin
> r = Rectangle((0.0, 0.0), 0.6, 0.4)
>
> # Construct a mind-blowing transformation: rotation by 30 degrees
> t = Affine2D().rotate_deg(30.0)
>
> # Make sure to add in the already-known axes data transformation
> t += ax.transData
>
> # Rotate that shizzle
> r.set_transform(t)
>
> # Plottify
> ax.add_patch(r)
>
> fig.savefig('my_awesome_TRAPEZIUM.pdf')
>
> Or you can look at my output here: http://i.imgur.com/2l439.png
>
> Rotation by 30 degrees is an angle-preserving linear transformation. So
> this shouldn't happen.
>
> Here's what's messing shiz up: the figure dimensions are not square.
> Look what happens when I use a square figure and make the axes fit
> exactly to the figure dimensions:
>
> ...
> fig = Figure((4, 4))
> ...
> ax = fig.add_axes([0, 0, 1, 1])
> ...
> ...
> fig.savefig('my_awesome_RECTANGLE.pdf')
>
> You can see the output here: http://i.imgur.com/baXiH.png
>
> Boom.
>
> I have no idea how to fix it. I came across it while trying to address
> https://github.com/matplotlib/matplotlib/issues/987 but it may or may
> not also be related to
> https://github.com/matplotlib/matplotlib/issues/1113
>
> Let me know if it's worth putting in github issue. I'm dont want to
> create a duplicate ticket should it transpire that this problem is
> actually #1113 in disguise.
>
> Best,
> Damon
>

My cherubs,
With my new found free time, I may have discovered a sneaky bug to which
you are not aware. Unless, of course, my example code is incorrect.
I do normal setup:
from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
from matplotlib.figure import Figure
from matplotlib.patches import Rectangle
from matplotlib.transforms import Affine2D
fig = Figure()
canvas = FigureCanvas(fig)
ax = fig.add_subplot(1, 1, 1)
# Make a sexy rectangle at the origin
r = Rectangle((0.0, 0.0), 0.6, 0.4)
# Construct a mind-blowing transformation: rotation by 30 degrees
t = Affine2D().rotate_deg(30.0)
# Make sure to add in the already-known axes data transformation
t += ax.transData
# Rotate that shizzle
r.set_transform(t)
# Plottify
ax.add_patch(r)
fig.savefig('my_awesome_TRAPEZIUM.pdf')
Or you can look at my output here: http://i.imgur.com/2l439.png
Rotation by 30 degrees is an angle-preserving linear transformation. So
this shouldn't happen.
Here's what's messing shiz up: the figure dimensions are not square.
Look what happens when I use a square figure and make the axes fit
exactly to the figure dimensions:
...
fig = Figure((4, 4))
...
ax = fig.add_axes([0, 0, 1, 1])
...
...
fig.savefig('my_awesome_RECTANGLE.pdf')
You can see the output here: http://i.imgur.com/baXiH.png
Boom.
I have no idea how to fix it. I came across it while trying to address
https://github.com/matplotlib/matplotlib/issues/987 but it may or may
not also be related to
https://github.com/matplotlib/matplotlib/issues/1113
Let me know if it's worth putting in github issue. I'm dont want to
create a duplicate ticket should it transpire that this problem is
actually #1113 in disguise.
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

On 2012年08月26日 5:50 AM, Michael Welter wrote:
> Hello,
>
> i made a patch which would allow the svg backend to make
> rasterized plots according to the dpi given in savefig.
> I wanted this in order to have high-res scatter plots.
> As you probably know it is hardcoded to 72 dpi right now.
> The idea how to, came from the pdf backend. I mostly
> copy pasted some code.
>
> I also added a test for it. Some other tests now fail
> the image comparison. It is nothing serious apparently.
> Probably roundoff errors. Except interp_nearest_vs_none.
> The result of which looks now exactly like the pdf which
> it did not before.
>
> Also, two other minor changes which i needed
>
> - Compare_images failed for older numy versions. Simple fix ...
> - A numpy.float32 variable got passed to the pdfRepr function in
> backend_pdf.py. I changed this function to accept this type, too.
>
>
> Cheers,
> Michael
Michael,
Thank you, this sounds good. Although we can deal with it as a patch if 
necessary, it would be greatly preferable to see it as a github PR:
http://matplotlib.sourceforge.net/devel/gitwash/git_development.html#git-development
Are you willing to give that a try?
Eric

As of now, we have 14 issues on the 1.2.x milestone, plus 6 issues on 
the 1.2.x known bugs milestone.
Since there's still a lot of work to be done on these before the rc1, 
I'm thinking I will continue to hold off on creating a 1.2.x branch. 
(Creating the branch would mean all of the pending PRs would have to be 
merged both to master and then manually pulled back to 1.2.x -- totally 
doable, or course, but an extra step.) Once we're down to only a 
handful, that might be a good time to create the branch.
Are there any objections to continuing to hold off? The downside is we 
can't continue to merge non 1.2.x "blue sky" PRs in the meantime.
Mike

On 08/26/2012 05:33 AM, Anton Akhmerov wrote:
> Michael Droettboom <mdroe@...> writes:
>
>>
>> 
>> Working with the documentation this past week has me a little
>> frustrated with the state of it. Enough to write a MEP.
> https://github.com/matplotlib/matplotlib/wiki/Mep10
>> In particular, it would be nice to compile a list of concerns about
>> the docstrings and documentation layout so that we can address as
>> much as possible in a single pass. Also, let me know if there are
>> any relevant PRs and Issues.
>> In particular, I think PR #1032, as it is a large structural
>> reorganization, my dovetail well with the proposed reorganization of
>> the docs.
>> Mike
> The proposal looks great. I would like to comment on one issue that it touches,
> and which I found very uncomfortable to work with as a newcomer. I think that
> matplotlib style of using *args and **kwargs for delegation of arguments is a
> rather bad practice, which is hard to solve by just updating documentation. It
> breaks many rules of pep 20: it is implicit, since it is not allowing
> introspection, it is nested, since it always involves nested calls, it allows
> for alternative ways to do things, and I also don't think it's anyhow beautiful.
> Most of the things passed with *args, **kwargs can be done with an added
> function call, like:
>
> points = ax.scatter(data)
> points.update(*args, **kwargs)
>
> What would be the disadvantage of abolishing this practice?
>
I understand the comments about the difficulty of introspection. The 
reason it works the way it does is so that additional parameters can be 
added to the artist layer without needing to update every single 
plotting function. A real world example of this is when hatching was 
added -- that feature only had to be added in one place and most artists 
were able to use it. In that sense, I think this approach is very 
beautiful in terms of code maintainability and extensibility.
I'm willing to consider this if there's a better suggestion, but I think 
pushing what is currently a single function call for the user in to two 
is not going to fly.
An alternative might be to have "style" objects that are passed to the 
plotting functions, and these style objects could grow new features over 
time. But that's going to break a lot of backward compatibility, of course.
Mike

Hello,
i made a patch which would allow the svg backend to make
rasterized plots according to the dpi given in savefig.
I wanted this in order to have high-res scatter plots.
As you probably know it is hardcoded to 72 dpi right now.
The idea how to, came from the pdf backend. I mostly
copy pasted some code.
I also added a test for it. Some other tests now fail
the image comparison. It is nothing serious apparently.
Probably roundoff errors. Except interp_nearest_vs_none.
The result of which looks now exactly like the pdf which
it did not before.
Also, two other minor changes which i needed
- Compare_images failed for older numy versions. Simple fix ...
- A numpy.float32 variable got passed to the pdfRepr function in
backend_pdf.py. I changed this function to accept this type, too.
Cheers,
Michael

Michael Droettboom <mdroe@...> writes:
> 
> 
> 
> Working with the documentation this past week has me a little
> frustrated with the state of it. Enough to write a MEP. 
https://github.com/matplotlib/matplotlib/wiki/Mep10
> In particular, it would be nice to compile a list of concerns about
> the docstrings and documentation layout so that we can address as
> much as possible in a single pass. Also, let me know if there are
> any relevant PRs and Issues.
> In particular, I think PR #1032, as it is a large structural
> reorganization, my dovetail well with the proposed reorganization of
> the docs.
> Mike
The proposal looks great. I would like to comment on one issue that it touches, 
and which I found very uncomfortable to work with as a newcomer. I think that 
matplotlib style of using *args and **kwargs for delegation of arguments is a 
rather bad practice, which is hard to solve by just updating documentation. It 
breaks many rules of pep 20: it is implicit, since it is not allowing 
introspection, it is nested, since it always involves nested calls, it allows 
for alternative ways to do things, and I also don't think it's anyhow beautiful.
Most of the things passed with *args, **kwargs can be done with an added 
function call, like:
points = ax.scatter(data)
points.update(*args, **kwargs)
What would be the disadvantage of abolishing this practice?
Anton

Hi all,
I'm not sure if anyone's noticed, but I have been looking through some
of the issues tagged 'SF' and 'wishlist' on github to try and get them
sorted out. I have some spare time since I finished my thesis yesterday;
woohoo!
I was just wondering, since I've got a little free time now, are there
any specific issues I can help out with that should be prioritised
higher? I'm aware of the 1.2 feature freeze, so anything new won't be
merged over issues that affect a possible release candidate.
Thanks!
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

On 08/24/2012 09:31 AM, Damon McDougall wrote:
> On Fri, Aug 24, 2012 at 09:03:48AM -0400, Michael Droettboom wrote:
>> Sorry about that. PyPI is a bear.
>>
>> It seems to finally be uploaded correctly, and "pip install
>> matplotlib" is working for me. Can you please confirm?
>>
> OP mentioned easy_install. Is there a difference between this and pip?
They use the same PyPI database, so if one is able to find the file, I 
would assume the other can. I don't use easy_install, and didn't have 
it handy, so I only tested with pip.
Mike

Stacked type histograms have this problem as well. The solution I've
found is to do fig.set_yscale('log', nonposy='clip').
On Fri, Aug 24, 2012 at 8:43 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Fri, Aug 24, 2012 at 1:44 AM, Eric Firing <ef...@ha...> wrote:
>>
>> On 2012年08月23日 6:41 PM, Fernando Perez wrote:
>> > Hi Eric,
>> >
>> > On Thu, Aug 23, 2012 at 7:56 PM, Eric Firing <ef...@ha...> wrote:
>> >> I'm not sure I understand what you are getting at, but I don't think
>> >> there
>> >> should be any interface changes for plot or for their log variants.
>> >
>> > I probably phrased my question poorly. I'm just wondering, how would
>> > one use the proposed stackplot function to obtain a stacked plot but
>> > that used log axes (x, y or both)?
>>
>> One would follow the stackplot call with calls to xscale('log') and/or
>> yscale('log'). This works fine for the x-axis (if x values are
>> positive), but when the y-axis is log, the bottom region is not filled,
>> presumably because it is trying to fill down to zero. I haven't looked
>> at the code, so I don't know whether there is some way of improving this
>> behavior without the stackplot call knowing beforehand that it will be
>> dealing with a log axis.
>>
>> Eric
>>
>
> This is a similar problem that we face with bar() and hist()...
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> 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
>

Hi Mike and Damon,
> It seems to finally be uploaded correctly, and "pip install matplotlib"
> is working for me. Can you please confirm?
> 
> 
It works, thanks!
> OP mentioned easy_install. Is there a difference between this and pip?
> 
> 
Depends on who you ask :-) I used to hate pip in the pre-1.0 days and used easy_install instead, but now I've mostly moved over to pip. They are pretty similar nowadays and I still mix up my terminology...
Regards,
Ludwig

On Fri, Aug 24, 2012 at 09:03:48AM -0400, Michael Droettboom wrote:
> Sorry about that. PyPI is a bear.
> 
> It seems to finally be uploaded correctly, and "pip install
> matplotlib" is working for me. Can you please confirm?
>
OP mentioned easy_install. Is there a difference between this and pip?
> 
> Mike
> 
> On 08/24/2012 05:23 AM, Ludwig Schwardt wrote:
> >Hi,
> >
> >There does not seem to be an actual tarball of matplotlib 1.1.1 on
> >PyPI at http://pypi.python.org/pypi/matplotlib/1.1.1 ... Maybe I'm
> >the only person who still likes to easy_install my matplotlib :-)
> >
> >L.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Sorry about that. PyPI is a bear.
It seems to finally be uploaded correctly, and "pip install matplotlib" 
is working for me. Can you please confirm?
Mike
On 08/24/2012 05:23 AM, Ludwig Schwardt wrote:
> Hi,
>
> There does not seem to be an actual tarball of matplotlib 1.1.1 on 
> PyPI at http://pypi.python.org/pypi/matplotlib/1.1.1 ... Maybe I'm the 
> only person who still likes to easy_install my matplotlib :-)
>
> L.
>
>
>
> ------------------------------------------------------------------------------
> 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 Fri, Aug 24, 2012 at 5:23 AM, Ludwig Schwardt
<lud...@gm...>wrote:
> Hi,
>
> There does not seem to be an actual tarball of matplotlib 1.1.1 on PyPI at
> http://pypi.python.org/pypi/matplotlib/1.1.1 ... Maybe I'm the only person
> who still likes to easy_install my matplotlib :-)
>
> L.
>
>
I swear, if I had a nickel for every time we try releasing a new version of
mpl and it doesn't *quite* work with pypi, I'd have about a dollar...
Ben Root

On Fri, Aug 24, 2012 at 1:44 AM, Eric Firing <ef...@ha...> wrote:
> On 2012年08月23日 6:41 PM, Fernando Perez wrote:
> > Hi Eric,
> >
> > On Thu, Aug 23, 2012 at 7:56 PM, Eric Firing <ef...@ha...> wrote:
> >> I'm not sure I understand what you are getting at, but I don't think
> there
> >> should be any interface changes for plot or for their log variants.
> >
> > I probably phrased my question poorly. I'm just wondering, how would
> > one use the proposed stackplot function to obtain a stacked plot but
> > that used log axes (x, y or both)?
>
> One would follow the stackplot call with calls to xscale('log') and/or
> yscale('log'). This works fine for the x-axis (if x values are
> positive), but when the y-axis is log, the bottom region is not filled,
> presumably because it is trying to fill down to zero. I haven't looked
> at the code, so I don't know whether there is some way of improving this
> behavior without the stackplot call knowing beforehand that it will be
> dealing with a log axis.
>
> Eric
>
>
This is a similar problem that we face with bar() and hist()...
Ben Root

Hi, 
There does not seem to be an actual tarball of matplotlib 1.1.1 on PyPI at http://pypi.python.org/pypi/matplotlib/1.1.1 ... Maybe I'm the only person who still likes to easy_install my matplotlib :-)
L. 

On 2012年08月23日 6:41 PM, Fernando Perez wrote:
> Hi Eric,
>
> On Thu, Aug 23, 2012 at 7:56 PM, Eric Firing <ef...@ha...> wrote:
>> I'm not sure I understand what you are getting at, but I don't think there
>> should be any interface changes for plot or for their log variants.
>
> I probably phrased my question poorly. I'm just wondering, how would
> one use the proposed stackplot function to obtain a stacked plot but
> that used log axes (x, y or both)?
One would follow the stackplot call with calls to xscale('log') and/or 
yscale('log'). This works fine for the x-axis (if x values are 
positive), but when the y-axis is log, the bottom region is not filled, 
presumably because it is trying to fill down to zero. I haven't looked 
at the code, so I don't know whether there is some way of improving this 
behavior without the stackplot call knowing beforehand that it will be 
dealing with a log axis.
Eric
>
> Cheers,
>
> f
>

Hi Eric,
On Thu, Aug 23, 2012 at 7:56 PM, Eric Firing <ef...@ha...> wrote:
> I'm not sure I understand what you are getting at, but I don't think there
> should be any interface changes for plot or for their log variants.
I probably phrased my question poorly. I'm just wondering, how would
one use the proposed stackplot function to obtain a stacked plot but
that used log axes (x, y or both)?
Cheers,
f

I think this gives more reason to not add a stacked kwarg to plot. You
would need to add it to the log variants as well.
Nic
On Thu, Aug 23, 2012 at 10:56 PM, Eric Firing <ef...@ha...> wrote:
> On 2012年08月23日 2:54 PM, Fernando Perez wrote:
>> On Thu, Aug 23, 2012 at 4:21 PM, Eric Firing <ef...@ha...> wrote:
>>> 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.
>>
>> Quick q: how would things like log plots be handles for the stacked
>> case? Log plots are really just axis scale choices on a normal plot,
>> but for historical reasons they happen to be implemented via a bunch
>> of different functions. But for that reason, any interface changes
>> that make sense for plot pretty should also apply to the *log*
>> functions, no?
>
> I'm not sure I understand what you are getting at, but I don't think
> there should be any interface changes for plot or for their log variants.
>
> Eric
>
>>
>> Cheers,
>>
>> f
>>
>
>
> ------------------------------------------------------------------------------
> 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 2012年08月23日 2:54 PM, Fernando Perez wrote:
> On Thu, Aug 23, 2012 at 4:21 PM, Eric Firing <ef...@ha...> wrote:
>> 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.
>
> Quick q: how would things like log plots be handles for the stacked
> case? Log plots are really just axis scale choices on a normal plot,
> but for historical reasons they happen to be implemented via a bunch
> of different functions. But for that reason, any interface changes
> that make sense for plot pretty should also apply to the *log*
> functions, no?
I'm not sure I understand what you are getting at, but I don't think 
there should be any interface changes for plot or for their log variants.
Eric
>
> Cheers,
>
> f
>

On Thu, Aug 23, 2012 at 4:21 PM, Eric Firing <ef...@ha...> wrote:
> 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.
Quick q: how would things like log plots be handles for the stacked
case? Log plots are really just axis scale choices on a normal plot,
but for historical reasons they happen to be implemented via a bunch
of different functions. But for that reason, any interface changes
that make sense for plot pretty should also apply to the *log*
functions, no?
Cheers,
f

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

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

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