matplotlib-devel Mailing List for matplotlib

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