matplotlib-devel — matplotlib developers

[matplotlib-devel] Help with windowing corrections for spectrums

[Todd <tod...@gm...>]

Hi, I am trying to make some improvements to the spectrum-related functions
in mlab (and the corresponding plotting functions).

What I am trying to do is make the functions more general, so they work
with complex spectrums, magnitude spectrums, and phase spectrums in
addition to PSDs.  The problem I think I am running into is in line 277 of
mlab.py, where the correction for the window function is applied.  This
correction works for PSDs, but shouldn't work for other sorts of spectrums,
and I none of the digital signal processing books I have access to seem to
deal with this issue.

The line in question is:

    # Scale the spectrum by the norm of the window to compensate for
    # windowing loss; see Bendat & Piersol Sec 11.5.2.
    Pxy /= (np.abs(windowVals)**2).sum()


This book is "Bendat & Piersol – Random Data: Analysis and Measurement
Procedures, John Wiley & Sons (1986)".  However, I can't find this book,
nor am I even sure it deals with this subject for anything other than PSDs.

Does anyone know the formula for calculating the window correction for
complex spectrums and/or magnitude and phase spectrums?  (if I have the
complex spectrums I can calculate magnitude and phase spectrums, and vice
versus)  Or, alternatively, does anyone have access to this book, and can
they check whether it has any of those functions?

Thanks a lot!

Re: [matplotlib-devel] Reorganizing axes plot methods

[Tony Yu <ts...@gm...>]

Nelle, this is great! Thanks for getting the ball rolling!

Cheers,
-Tony


On Thu, Jul 11, 2013 at 6:31 AM, Nelle Varoquaux
<nel...@gm...>wrote:

> FYI, I have started the refactoring we discussed at scipy. I think
> what tony is suggesting is the same thing.
>
> I've created a "work in progress" pull request:
> https://github.com/matplotlib/matplotlib/pull/2213
>
> In the refactoring we discussed at Scipy, we did not mention the
> pyplots wrapper at all. It does not impact pyplot or the axes module
> at all as it doesn't change the API at all. If we want to do something
> more in depth that impacts the API, I think it would be worth writing
> a MEP.
>
> Thanks,
> N
>
>
> On 11 July 2013 13:12, Anton Akhmerov <ant...@gm...> wrote:
> > Eric Firing <efiring@...> writes:
> >>
> >> Anton,
> >>
> >> Yes, I have done things like that in my own code, and basemap has a
> >> similar ability to call gca() when an Axes is not supplied.  One can
> >> even perform the pyplot import on an as-needed basis instead of raising
> >> an error. Nevetheless, it still represents what I view as a big change
> >> in mpl design, scrambling the state machine pyplot layer into the OO
> >> layer.  Sometimes this sort of thing is good, sometimes it isn't.  In
> >> the present case, I am far from convinced that it would be good.  I
> >> don't see any real benefit at all over the present design.  I think that
> >> for the sanity of the developers, if nothing else, it is important to
> >> maintain some clear layering and hierarchy.
> >>
> >> Eric
> >>
> >
> > I completely agree with that, and I just wanted to point out the
> possibility.
> > With the proposed separation of the plots to a separate module, I think,
> the
> > reasonable thing for pyplot would be to wrap the corresponding plot
> functions
> > by feeding gca into the axis argument.
> >
> > PS for what I think, pyplot right now is way too thick of a layer,
> > obstructing an API use of backends.
> >
> > Anton
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Reorganizing axes plot methods

[Nelle V. <nel...@gm...>]

FYI, I have started the refactoring we discussed at scipy. I think
what tony is suggesting is the same thing.

I've created a "work in progress" pull request:
https://github.com/matplotlib/matplotlib/pull/2213

In the refactoring we discussed at Scipy, we did not mention the
pyplots wrapper at all. It does not impact pyplot or the axes module
at all as it doesn't change the API at all. If we want to do something
more in depth that impacts the API, I think it would be worth writing
a MEP.

Thanks,
N


On 11 July 2013 13:12, Anton Akhmerov <ant...@gm...> wrote:
> Eric Firing <efiring@...> writes:
>>
>> Anton,
>>
>> Yes, I have done things like that in my own code, and basemap has a
>> similar ability to call gca() when an Axes is not supplied.  One can
>> even perform the pyplot import on an as-needed basis instead of raising
>> an error. Nevetheless, it still represents what I view as a big change
>> in mpl design, scrambling the state machine pyplot layer into the OO
>> layer.  Sometimes this sort of thing is good, sometimes it isn't.  In
>> the present case, I am far from convinced that it would be good.  I
>> don't see any real benefit at all over the present design.  I think that
>> for the sanity of the developers, if nothing else, it is important to
>> maintain some clear layering and hierarchy.
>>
>> Eric
>>
>
> I completely agree with that, and I just wanted to point out the possibility.
> With the proposed separation of the plots to a separate module, I think, the
> reasonable thing for pyplot would be to wrap the corresponding plot functions
> by feeding gca into the axis argument.
>
> PS for what I think, pyplot right now is way too thick of a layer,
> obstructing an API use of backends.
>
> Anton
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Reorganizing axes plot methods

[Anton A. <ant...@gm...>]

Eric Firing <efiring@...> writes:
> 
> Anton,
> 
> Yes, I have done things like that in my own code, and basemap has a 
> similar ability to call gca() when an Axes is not supplied.  One can 
> even perform the pyplot import on an as-needed basis instead of raising 
> an error. Nevetheless, it still represents what I view as a big change 
> in mpl design, scrambling the state machine pyplot layer into the OO 
> layer.  Sometimes this sort of thing is good, sometimes it isn't.  In 
> the present case, I am far from convinced that it would be good.  I 
> don't see any real benefit at all over the present design.  I think that 
> for the sanity of the developers, if nothing else, it is important to 
> maintain some clear layering and hierarchy.
> 
> Eric
>

I completely agree with that, and I just wanted to point out the possibility. 
With the proposed separation of the plots to a separate module, I think, the 
reasonable thing for pyplot would be to wrap the corresponding plot functions 
by feeding gca into the axis argument.

PS for what I think, pyplot right now is way too thick of a layer, 
obstructing an API use of backends.

Anton

Re: [matplotlib-devel] Reorganizing axes plot methods

[Eric F. <ef...@ha...>]

On 2013/07/10 1:11 AM, Anton Akhmerov wrote:
> Eric Firing <efiring@...> writes:
>
>> This would require pyplot to be imported by everything, wouldn't it?
>> That would completely defeat the strategy of having an OO level that
>> doesn't know about pyplot at all, and then having pyplot be the thin top
>> layer.
>
> Requiring pyplot isn't necessary, instead one may merely check if it's
> available. The following is what we do in a similar situation:
>
>    try:
>        fake_fig = matplotlib.pyplot.figure()
>    except AttributeError:
>        msg = 'matplotlib.pyplot is unavailable.  Execute `import ' \
>        'matplotlib.pyplot` or use a different output mode.'
>        raise RuntimeError(msg)
>
> (obviously, one can substitute figure() call to gca())
>
> Anton

Anton,

Yes, I have done things like that in my own code, and basemap has a 
similar ability to call gca() when an Axes is not supplied.  One can 
even perform the pyplot import on an as-needed basis instead of raising 
an error. Nevetheless, it still represents what I view as a big change 
in mpl design, scrambling the state machine pyplot layer into the OO 
layer.  Sometimes this sort of thing is good, sometimes it isn't.  In 
the present case, I am far from convinced that it would be good.  I 
don't see any real benefit at all over the present design.  I think that 
for the sanity of the developers, if nothing else, it is important to 
maintain some clear layering and hierarchy.

Eric

Re: [matplotlib-devel] Reorganizing axes plot methods

[Anton A. <ant...@gm...>]

Eric Firing <efiring@...> writes:

> This would require pyplot to be imported by everything, wouldn't it? 
> That would completely defeat the strategy of having an OO level that 
> doesn't know about pyplot at all, and then having pyplot be the thin top 
> layer.

Requiring pyplot isn't necessary, instead one may merely check if it's 
available. The following is what we do in a similar situation:

  try:
      fake_fig = matplotlib.pyplot.figure()
  except AttributeError:
      msg = 'matplotlib.pyplot is unavailable.  Execute `import ' \
      'matplotlib.pyplot` or use a different output mode.'
      raise RuntimeError(msg)

(obviously, one can substitute figure() call to gca())

Anton

> 
> Eric
> 
> > I haven't sat down and thought through all the details of such a change,
> > but I wanted to throw it out there to see if anything sticks.
> >
> > Cheers,
> > -Tony
> >
> >
> > ------------------------------------------------------------------------
------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> > http://pubads.g.doubleclick.net/gampad/clk?
id=48808831&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel@...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> 
> --------------------------------------------------------------------------
----
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?
id=48808831&iu=/4140/ostg.clktrk
> 

Re: [matplotlib-devel] Reorganizing axes plot methods

[Tony Yu <ts...@gm...>]

On Tue, Jul 9, 2013 at 1:43 AM, Nelle Varoquaux
<nel...@gm...>wrote:

> On 9 July 2013 08:24, Eric Firing <ef...@ha...> wrote:
> > On 2013/07/08 7:19 PM, Tony Yu wrote:
> >> This is an idea that's been kicking around in my head for awhile.
> >> Basically, the Axes class is way too expansive. Nelle made a major step
> >> in the right direction with a PR that split it up into plotting and
> >> non-plotting methods:
> >>
> >> https://github.com/matplotlib/matplotlib/pull/1931/files
> >>
> >> What I'd like to see is something that further separates plotting
> >> methods into many smaller sub-modules/-packages. Organizing the code
> >> this way would make it easier (for me at least) to read, understand, and
> >> make changes to the code.
> >>
> >> I think that this could be done in an API-compatible way. In fact, a few
> >> of the plotting methods are already implemented this way: In other
> >> words, the bulk of the methods are implemented as functions outside of
> >> Axes, and the Axes methods that are just thin wrappers around those
> >> functions (or classes). See, for example, `streamplot`, `barbs`, and
> >> `quiver` methods
> >
> > I agree.  I would like to see logical groups of plot types broken out
> > into modules.
>
> That's the second step in the refactoring of the axes module.
> We now have to discuss how to organize plots in subtypes that make
> sense. At Scipy, we discussed a bit about it, and we think it should
> follow the same organization as the gallery, but I don't know whether
> the gallery reorganization is logical enough right now to start the
> refactoring straight away.
>

I knew I should have dropped by the matplotlib sprints :) The gallery
categories really aren't that logical, but as long as the functions aren't
meant to be directly imported from their sub-modules (instead you would use
the Axes method or pyplot function), then nothing needs to be permanent,
right?

>
> Should we discuss about this here, or in a ticket?
>

It's probably easier to discuss on a new ticket.

Cheers,
-Tony

Re: [matplotlib-devel] Reorganizing axes plot methods

[Tony Yu <ts...@gm...>]

On Tue, Jul 9, 2013 at 1:24 AM, Eric Firing <ef...@ha...> wrote:

<snip>

This would require pyplot to be imported by everything, wouldn't it?
> That would completely defeat the strategy of having an OO level that
> doesn't know about pyplot at all, and then having pyplot be the thin top
> layer.
>

Ahh, you're right! Like I said, I haven't really sat down and thought
through all the details :)


>
> Eric
>
> > I haven't sat down and thought through all the details of such a change,
> > but I wanted to throw it out there to see if anything sticks.
> >
> > Cheers,
> > -Tony
>
>

Re: [matplotlib-devel] Reorganizing axes plot methods

[Thomas A C. <tca...@uc...>]

I second Eric's concern about pyplot being imported into everything. It
will really mess up the people that are embedding matplotlib into guis
because pyplot starts up gui mainloops if you are using an interactive
backend.

There is a genre of question on SO that is 'why isn't pyplot playing nice
with my gui'.

Tom


On Tue, Jul 9, 2013 at 1:43 AM, Nelle Varoquaux
<nel...@gm...>wrote:

> On 9 July 2013 08:24, Eric Firing <ef...@ha...> wrote:
> > On 2013/07/08 7:19 PM, Tony Yu wrote:
> >> This is an idea that's been kicking around in my head for awhile.
> >> Basically, the Axes class is way too expansive. Nelle made a major step
> >> in the right direction with a PR that split it up into plotting and
> >> non-plotting methods:
> >>
> >> https://github.com/matplotlib/matplotlib/pull/1931/files
> >>
> >> What I'd like to see is something that further separates plotting
> >> methods into many smaller sub-modules/-packages. Organizing the code
> >> this way would make it easier (for me at least) to read, understand, and
> >> make changes to the code.
> >>
> >> I think that this could be done in an API-compatible way. In fact, a few
> >> of the plotting methods are already implemented this way: In other
> >> words, the bulk of the methods are implemented as functions outside of
> >> Axes, and the Axes methods that are just thin wrappers around those
> >> functions (or classes). See, for example, `streamplot`, `barbs`, and
> >> `quiver` methods
> >
> > I agree.  I would like to see logical groups of plot types broken out
> > into modules.
>
> That's the second step in the refactoring of the axes module.
> We now have to discuss how to organize plots in subtypes that make
> sense. At Scipy, we discussed a bit about it, and we think it should
> follow the same organization as the gallery, but I don't know whether
> the gallery reorganization is logical enough right now to start the
> refactoring straight away.
>
> Should we discuss about this here, or in a ticket?
>
> >>
> >> The examples mentioned above simply take the axes as the first
> >> parameter. Here's the Axes-method definition of `quiver`, for example:
> >>
> >>      def quiver(self, *args, **kw):
> >>          ...
> >>          q = mquiver.Quiver(self, *args, **kw)
> >>          ...
> >>          return q
> >>
> >> (might be a good idea to add a decorator to maintain the function
> >> signature and docstring)
> >>
> >> This should work for any of the plotting methods (I would imagine).
> >> Another alternative is for all these plotting functions to have an `ax`
> >> (or some other spelling) keyword argument that defaults to None and then
> >> have a line in every function that does something like
> >>
> >>      ax = ax if ax is not None else plt.gca()
> >>
> >> If I'm not mistaken, this would allow pyplot functions to be even
> >> thinner wrappers around these newly extracted functions. (In some cases,
> >> it might just be a simple import from the the new sub-package/-module
> >> into the `pyplot` namespace).
> >>
> >
> > This would require pyplot to be imported by everything, wouldn't it?
> > That would completely defeat the strategy of having an OO level that
> > doesn't know about pyplot at all, and then having pyplot be the thin top
> > layer.
> >
> > Eric
> >
> >> I haven't sat down and thought through all the details of such a change,
> >> but I wanted to throw it out there to see if anything sticks.
> >>
> >> Cheers,
> >> -Tony
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> See everything from the browser to the database with AppDynamics
> >> Get end-to-end visibility with application monitoring from AppDynamics
> >> Isolate bottlenecks and diagnose root cause in seconds.
> >> Start your free trial of AppDynamics Pro today!
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >>
> >>
> >>
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Thomas A Caswell
PhD Candidate University of Chicago
Nagel and Gardel labs
tca...@uc...
jfi.uchicago.edu/~tcaswell
o: 773.702.7204

Re: [matplotlib-devel] Reorganizing axes plot methods

[Nelle V. <nel...@gm...>]

On 9 July 2013 08:24, Eric Firing <ef...@ha...> wrote:
> On 2013/07/08 7:19 PM, Tony Yu wrote:
>> This is an idea that's been kicking around in my head for awhile.
>> Basically, the Axes class is way too expansive. Nelle made a major step
>> in the right direction with a PR that split it up into plotting and
>> non-plotting methods:
>>
>> https://github.com/matplotlib/matplotlib/pull/1931/files
>>
>> What I'd like to see is something that further separates plotting
>> methods into many smaller sub-modules/-packages. Organizing the code
>> this way would make it easier (for me at least) to read, understand, and
>> make changes to the code.
>>
>> I think that this could be done in an API-compatible way. In fact, a few
>> of the plotting methods are already implemented this way: In other
>> words, the bulk of the methods are implemented as functions outside of
>> Axes, and the Axes methods that are just thin wrappers around those
>> functions (or classes). See, for example, `streamplot`, `barbs`, and
>> `quiver` methods
>
> I agree.  I would like to see logical groups of plot types broken out
> into modules.

That's the second step in the refactoring of the axes module.
We now have to discuss how to organize plots in subtypes that make
sense. At Scipy, we discussed a bit about it, and we think it should
follow the same organization as the gallery, but I don't know whether
the gallery reorganization is logical enough right now to start the
refactoring straight away.

Should we discuss about this here, or in a ticket?

>>
>> The examples mentioned above simply take the axes as the first
>> parameter. Here's the Axes-method definition of `quiver`, for example:
>>
>>      def quiver(self, *args, **kw):
>>          ...
>>          q = mquiver.Quiver(self, *args, **kw)
>>          ...
>>          return q
>>
>> (might be a good idea to add a decorator to maintain the function
>> signature and docstring)
>>
>> This should work for any of the plotting methods (I would imagine).
>> Another alternative is for all these plotting functions to have an `ax`
>> (or some other spelling) keyword argument that defaults to None and then
>> have a line in every function that does something like
>>
>>      ax = ax if ax is not None else plt.gca()
>>
>> If I'm not mistaken, this would allow pyplot functions to be even
>> thinner wrappers around these newly extracted functions. (In some cases,
>> it might just be a simple import from the the new sub-package/-module
>> into the `pyplot` namespace).
>>
>
> This would require pyplot to be imported by everything, wouldn't it?
> That would completely defeat the strategy of having an OO level that
> doesn't know about pyplot at all, and then having pyplot be the thin top
> layer.
>
> Eric
>
>> I haven't sat down and thought through all the details of such a change,
>> but I wanted to throw it out there to see if anything sticks.
>>
>> Cheers,
>> -Tony
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Reorganizing axes plot methods

[Eric F. <ef...@ha...>]

On 2013/07/08 7:19 PM, Tony Yu wrote:
> This is an idea that's been kicking around in my head for awhile.
> Basically, the Axes class is way too expansive. Nelle made a major step
> in the right direction with a PR that split it up into plotting and
> non-plotting methods:
>
> https://github.com/matplotlib/matplotlib/pull/1931/files
>
> What I'd like to see is something that further separates plotting
> methods into many smaller sub-modules/-packages. Organizing the code
> this way would make it easier (for me at least) to read, understand, and
> make changes to the code.
>
> I think that this could be done in an API-compatible way. In fact, a few
> of the plotting methods are already implemented this way: In other
> words, the bulk of the methods are implemented as functions outside of
> Axes, and the Axes methods that are just thin wrappers around those
> functions (or classes). See, for example, `streamplot`, `barbs`, and
> `quiver` methods

I agree.  I would like to see logical groups of plot types broken out 
into modules.

>
> The examples mentioned above simply take the axes as the first
> parameter. Here's the Axes-method definition of `quiver`, for example:
>
>      def quiver(self, *args, **kw):
>          ...
>          q = mquiver.Quiver(self, *args, **kw)
>          ...
>          return q
>
> (might be a good idea to add a decorator to maintain the function
> signature and docstring)
>
> This should work for any of the plotting methods (I would imagine).
> Another alternative is for all these plotting functions to have an `ax`
> (or some other spelling) keyword argument that defaults to None and then
> have a line in every function that does something like
>
>      ax = ax if ax is not None else plt.gca()
>
> If I'm not mistaken, this would allow pyplot functions to be even
> thinner wrappers around these newly extracted functions. (In some cases,
> it might just be a simple import from the the new sub-package/-module
> into the `pyplot` namespace).
>

This would require pyplot to be imported by everything, wouldn't it? 
That would completely defeat the strategy of having an OO level that 
doesn't know about pyplot at all, and then having pyplot be the thin top 
layer.

Eric

> I haven't sat down and thought through all the details of such a change,
> but I wanted to throw it out there to see if anything sticks.
>
> Cheers,
> -Tony
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] Reorganizing axes plot methods

[Tony Yu <ts...@gm...>]

This is an idea that's been kicking around in my head for awhile.
Basically, the Axes class is way too expansive. Nelle made a major step in
the right direction with a PR that split it up into plotting and
non-plotting methods:

https://github.com/matplotlib/matplotlib/pull/1931/files

What I'd like to see is something that further separates plotting methods
into many smaller sub-modules/-packages. Organizing the code this way would
make it easier (for me at least) to read, understand, and make changes to
the code.

I think that this could be done in an API-compatible way. In fact, a few of
the plotting methods are already implemented this way: In other words, the
bulk of the methods are implemented as functions outside of Axes, and the
Axes methods that are just thin wrappers around those functions (or
classes). See, for example, `streamplot`, `barbs`, and `quiver` methods

The examples mentioned above simply take the axes as the first parameter.
Here's the Axes-method definition of `quiver`, for example:

    def quiver(self, *args, **kw):
        ...
        q = mquiver.Quiver(self, *args, **kw)
        ...
        return q

(might be a good idea to add a decorator to maintain the function signature
and docstring)

This should work for any of the plotting methods (I would imagine). Another
alternative is for all these plotting functions to have an `ax` (or some
other spelling) keyword argument that defaults to None and then have a line
in every function that does something like

    ax = ax if ax is not None else plt.gca()

If I'm not mistaken, this would allow pyplot functions to be even thinner
wrappers around these newly extracted functions. (In some cases, it might
just be a simple import from the the new sub-package/-module into the
`pyplot` namespace).

I haven't sat down and thought through all the details of such a change,
but I wanted to throw it out there to see if anything sticks.

Cheers,
-Tony

Re: [matplotlib-devel] Completely wrong tick formatting

[Pål G. E. <pa...@gm...>]

Hi

Thank you that solves the problem we had.
I'm sorry for posting this on the development list, it was intended for the
users list, and I somehow entered the wrong address.

Regards

Pål

On 7 July 2013 21:44, Eric Firing <ef...@ha...> wrote:

> On 2013/07/04 11:43 PM, Pål Gunnar Ellingsen wrote:
> > Hi
> >
> > I'm having some problems with the formatter of ticks in a polar plot.
> > Below is a minimum example
> > The first figure is correct, the second has wrong ticks.
> >
> > This has be tested both on 1.2.0 and the latest from git (1.4.x, commit
> > 64cc3416396ffb2811af80fc810ed63572df71d9 )
> >
> > Does anyone know whys this happens?
> > Is it a bug in MaxNLocator
>
> No, it is a misunderstanding of how the colorbar works.  It's long axis
> is using its own units, and it maps the color scale to those units.
> Therefore, one should not try to manipulate the axis properties
> directly.  Below I show two altered lines and one deletion.  I think
> this will produce what you want.
>
> >
> > Kind regards
> >
> > Pål
> >
> > ---------------------------
> > #!/usr/bin/env python
> >
> > import numpy as np
> > import matplotlib.pyplot as plt
> > from matplotlib.ticker import MaxNLocator
> >
> > # Data
> > M=np.sin(np.meshgrid(np.arange(30),np.arange(30)))
> > M=np.squeeze(M[0,:,:])
> > Radius=np.arange(30)
> > Theta=np.arange(30)
> >
> > # Plotting the correct figure
> > print('Correct ticks')
> > fig=plt.figure()
> > ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
> > c = ax1.pcolormesh(Theta, Radius, M)
> > ax1.set_frame_on(False)
> > plt.xticks([])
> > plt.yticks([])
> > ax2=fig.add_axes([0.9,0.1,0.05,0.7])
> > cb=fig.colorbar(c,cax=ax2)
> > plt.show()
> >
> > # Doing the same plot
> > print('Wrong ticks by using formatter')
> > fig=plt.figure()
> > ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
> #> c = ax1.pcolormesh(Theta, Radius, M)
>
> c = ax1.pcolormesh(Theta, Radius, M, vmin=-1, vmax=1)
>
> > ax1.set_frame_on(False)
> > plt.xticks([])
> > plt.yticks([])
> > ax2=fig.add_axes([0.9,0.1,0.05,0.7])
> #> cb=fig.colorbar(c,cax=ax2)
>
> cb = fig.colorbar(c, cax=ax2, ticks=MaxNLocator(3))
>
> >
> #> # except now setting a limit to the number of ticks using a formatter
> #> # which results in wrong ticks
> #> cb.ax.yaxis.set_major_locator(MaxNLocator(3))
>
> > plt.show()
>
> Eric
>
> > -----------------------
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Windows:
> >
> > Build for Windows Store.
> >
> > http://p.sf.net/sfu/windows-dev2dev
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Colored lines and examples / documentation

[David P. S. <dps...@gm...>]

On Sun, Jul 7, 2013 at 10:14 PM, Tony Yu <ts...@gm...> wrote:

> Hi David,
>
> Sorry for the delay in replying. It was good meeting you last week.
> Comments inline with a lot of parts cut out.
>

Hi Tony,

It was great to meet you too!


>
>
> On Thu, Jul 4, 2013 at 10:13 PM, David P. Sanders <dps...@gm...>wrote:
>>
>> I have been working, as a first step, on colored line support. This is
>> not, of course, new -- it's all in LineCollection. However, as a user,
>> LineCollection is intimidating and difficult to understand, and does not
>> lead to easy experimentation (I speak from experience).
>>
>
> I agree that LineCollection isn't the most user-friendly thing to use.
> Personally, I'd be in favor of something like your `linecolor` suggestion,
> but I'd understand if the core-devs have concerns about feature creep.
>

Yes, I do understand your point, but I feel strongly that providing simple
interfaces for otherwise complicated concepts / syntax is important, and
very much in the spirit of matplotlib as I understand it.



>
>
>> At Tony's suggestion, the first step was to rewrite the
>> multicolored_line.py example.
>> You can find my first attempt as an IPython notebook at
>>
>>
>> https://github.com/dpsanders/matplotlib-examples/blob/master/linecolor.ipynb
>>
>> or
>>
>>
>> http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/linecolor.ipynb
>>
>
> This looked pretty interesting when I first looked at it, but it seems to
> be down now.
>

Apologies, I decided that 'colorline' was a better name than 'linecolor'
(since 'colorline' suggests that we are going to color a line, i.e. it puts
the verb and the noun in the correct order!), so I changed the notebook to

https://github.com/dpsanders/matplotlib-examples/blob/master/colorline.ipynb


http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/colorline.ipynb




>
>
>> Please let me have any comments before I attempt the next step of making
>> a pull request.
>>
>

I am trying to get to making a pull request, but am having trouble
incorporating the plot correctly into the gallery:
I have been trying to include colorline.py in the correct place in the
examples tree to have it added automatically to the gallery.
Somebody (don't remember who exactly -- Mike?) showed me how to do this
during the sprint, but I have been unable to reproduce the steps
successfully.

Could you please remind me exactly where I should put the file, and what
the correct sequence of commands to execute is? Is there a special format
that the file should have? For example, it seems that it should only have
one  plt.show()  following the other examples with multiple plots -- is
that right?
(I once managed to get a single one of the plots to show in the gallery,
and have not been able to reproduce that feat since!)



>  It seems to me that IPython notebooks are quite a natural format for
>> such examples, especially with a view to having interactive examples in the
>> future.
>>
>
> Using IPython notebooks as examples would be really beneficial in the long
> run, as discussed during the BoF. I struggled with implementing support for
> interleaved text, code, and plots for the scikit-image gallery (so that
> examples could have real explanations). IPython notebooks are a more
> natural format for this, but they're not quite there yet---specifically
> nbconvert is still evolving (though this should be integrated into the next
> release). That said, someone will need to write the code that takes the
> output from nbconvert and integrates it with the current Sphinx code that
> generates the gallery. Most of this will be straightforward but tedious.
>

The current git master of ipython indeed has nbconvert integrated. The
Python script output is also in my git repository -- these kind of outputs
should be easy to parse.
(Though I personally have no idea where to even start with something like
that. Any suggestions? Is there some kind of standard package for this kind
of thing?)



>
>
>> What is the situation with tagging the examples? If the examples are
>> being refactored, it would seem to at least be a natural moment to start
>> adding tags, even if nothing is actually done with them yet.
>>
>
> This is a great idea. I wish I had suggested this in my original MEP. I'm
> not sure if there's been progress on adding an interface for tags, but we
> should be adding tags during any clean ups to the examples so they're ready
> in the
>

I agree that it should be added to the MEP. From my point of view, the
exact tags that should be used may well be something that evolves over time.



>
> - Also during the BoF / sprint, style sheets were discussed several times.
>> Tony seems to have already solved this problem in his mpltools package --
>> I would suggest that this could be brought straight into Matplotlib?
>>
>
> This was my original plan. At the time I wrote the original, the rc parser
> wasn't exposed to the user. That's been fixed now, but I haven't found the
> time to integrate changes into Matplotlib proper. If anyone else would like
> to have a go at it, they are more than welcome. Otherwise, I'll get to it
> at some point ... hopefully.
>

OK, great.

Best,
David.


>
> Cheers!
> -Tony
>



-- 
**************************************************************************
Dr. David P. Sanders

Profesor Titular A / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)

dps...@gm...
http://sistemas.fciencias.unam.mx/~dsanders

Cubículo / office: #414
Tel.: +52 55 5622 4965

Re: [matplotlib-devel] Colored lines and examples / documentation

[Tony Yu <ts...@gm...>]

Hi David,

Sorry for the delay in replying. It was good meeting you last week.
Comments inline with a lot of parts cut out.


On Thu, Jul 4, 2013 at 10:13 PM, David P. Sanders <dps...@gm...>wrote:
>
> I have been working, as a first step, on colored line support. This is
> not, of course, new -- it's all in LineCollection. However, as a user,
> LineCollection is intimidating and difficult to understand, and does not
> lead to easy experimentation (I speak from experience).
>

I agree that LineCollection isn't the most user-friendly thing to use.
Personally, I'd be in favor of something like your `linecolor` suggestion,
but I'd understand if the core-devs have concerns about feature creep.


> At Tony's suggestion, the first step was to rewrite the
> multicolored_line.py example.
> You can find my first attempt as an IPython notebook at
>
>
> https://github.com/dpsanders/matplotlib-examples/blob/master/linecolor.ipynb
>
> or
>
>
> http://nbviewer.ipython.org/urls/raw.github.com/dpsanders/matplotlib-examples/master/linecolor.ipynb
>

This looked pretty interesting when I first looked at it, but it seems to
be down now.


> Please let me have any comments before I attempt the next step of making a
> pull request.
> It seems to me that IPython notebooks are quite a natural format for such
> examples, especially with a view to having interactive examples in the
> future.
>

Using IPython notebooks as examples would be really beneficial in the long
run, as discussed during the BoF. I struggled with implementing support for
interleaved text, code, and plots for the scikit-image gallery (so that
examples could have real explanations). IPython notebooks are a more
natural format for this, but they're not quite there yet---specifically
nbconvert is still evolving (though this should be integrated into the next
release). That said, someone will need to write the code that takes the
output from nbconvert and integrates it with the current Sphinx code that
generates the gallery. Most of this will be straightforward but tedious.


> What is the situation with tagging the examples? If the examples are being
> refactored, it would seem to at least be a natural moment to start adding
> tags, even if nothing is actually done with them yet.
>

This is a great idea. I wish I had suggested this in my original MEP. I'm
not sure if there's been progress on adding an interface for tags, but we
should be adding tags during any clean ups to the examples so they're ready
in the future.

- Also during the BoF / sprint, style sheets were discussed several times.
> Tony seems to have already solved this problem in his mpltools package --
> I would suggest that this could be brought straight into Matplotlib?
>

This was my original plan. At the time I wrote the original, the rc parser
wasn't exposed to the user. That's been fixed now, but I haven't found the
time to integrate changes into Matplotlib proper. If anyone else would like
to have a go at it, they are more than welcome. Otherwise, I'll get to it
at some point ... hopefully.

Cheers!
-Tony

Re: [matplotlib-devel] Completely wrong tick formatting

[Eric F. <ef...@ha...>]

On 2013/07/04 11:43 PM, Pål Gunnar Ellingsen wrote:
> Hi
>
> I'm having some problems with the formatter of ticks in a polar plot.
> Below is a minimum example
> The first figure is correct, the second has wrong ticks.
>
> This has be tested both on 1.2.0 and the latest from git (1.4.x, commit
> 64cc3416396ffb2811af80fc810ed63572df71d9 )
>
> Does anyone know whys this happens?
> Is it a bug in MaxNLocator

No, it is a misunderstanding of how the colorbar works.  It's long axis 
is using its own units, and it maps the color scale to those units. 
Therefore, one should not try to manipulate the axis properties 
directly.  Below I show two altered lines and one deletion.  I think 
this will produce what you want.

>
> Kind regards
>
> Pål
>
> ---------------------------
> #!/usr/bin/env python
>
> import numpy as np
> import matplotlib.pyplot as plt
> from matplotlib.ticker import MaxNLocator
>
> # Data
> M=np.sin(np.meshgrid(np.arange(30),np.arange(30)))
> M=np.squeeze(M[0,:,:])
> Radius=np.arange(30)
> Theta=np.arange(30)
>
> # Plotting the correct figure
> print('Correct ticks')
> fig=plt.figure()
> ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
> c = ax1.pcolormesh(Theta, Radius, M)
> ax1.set_frame_on(False)
> plt.xticks([])
> plt.yticks([])
> ax2=fig.add_axes([0.9,0.1,0.05,0.7])
> cb=fig.colorbar(c,cax=ax2)
> plt.show()
>
> # Doing the same plot
> print('Wrong ticks by using formatter')
> fig=plt.figure()
> ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
#> c = ax1.pcolormesh(Theta, Radius, M)

c = ax1.pcolormesh(Theta, Radius, M, vmin=-1, vmax=1)

> ax1.set_frame_on(False)
> plt.xticks([])
> plt.yticks([])
> ax2=fig.add_axes([0.9,0.1,0.05,0.7])
#> cb=fig.colorbar(c,cax=ax2)

cb = fig.colorbar(c, cax=ax2, ticks=MaxNLocator(3))

>
#> # except now setting a limit to the number of ticks using a formatter
#> # which results in wrong ticks
#> cb.ax.yaxis.set_major_locator(MaxNLocator(3))

> plt.show()

Eric

> -----------------------
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] basemap installation problem with mpl master

[Jeff W. <js...@fa...>]

> Thomas Kluyver <mailto:th...@kl...>
> July 6, 2013 11:26 AM
>
> *distribute*, which was a fork of setuptools, was merged into 
> setuptools. *distutils* is the component in the standard library, and 
> is still there. I still prefer distutils where possible, precisely 
> because setuptools' eggs are a mess.
>
> Thomas

I agree eggs are a mess.   Given that it is still easy to have the old 
behavior, can someone explain why the change was made to have setup.py 
create eggs by default?

-Jeff
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> Damon McDougall <mailto:dam...@gm...>
> July 6, 2013 11:20 AM
>
>
>
> On Sat, Jul 6, 2013 at 11:04 AM, Jeff Whitaker <js...@fa... 
> <mailto:js...@fa...>> wrote:
>
>>     Damon McDougall <mailto:dam...@gm...>
>>     July 6, 2013 9:32 AM
>>
>>
>>
>>         If I do a clean install of mpl master, and then of basemap,
>>         basemap
>>         lands in dist-packages/mpl_toolkits, as it always has.  But
>>         now it is
>>         not found--I can't import it.  It seems that now the *real*
>>         mpl_toolkits
>>         is cleverly hidden inside an egg directory with a monstrous name,
>>         leaving basemap orphaned in a directory with no __init__.py.
>>          As a
>>         workaround I can symlink it into the egg location.  I suspect
>>         the real
>>         solution will require basemap to use setuptools, correct?  I
>>         don't know
>>         how to do this, so I hope someone who does will submit a PR.
>>
>>
>>     Actually, using the new setuptools isn't adequate, I just tried
>>     it locally on my machine and it still doesn't install itself into
>>     the matplotlib egg.
>>
>>     I think the proper solution here is to add basemap as an optional
>>     dependency to matplotlib and have the user set a flag (off by
>>     default) to pull basemap if it's desired
>>
>>     Does that sound like a reasonable solution?
>
>     What if a user decides later that he/she wants to install
>     basemap?  Then they would have to reinstall matplotlib?  That
>     doesn't sound reasonable to me.
>
>
> Actually, on reflection, I'm in agreement with you.  I'm comfortable 
> installing from source but this poses a larger problem when users 
> download the basemap binary and expect it to Just Work.
>
>     How about having matplotlib install a symlink to the egg location?
>
>
> If there's a way for setuptools to modify the matplotlib egg to add a 
> symlink, then it must be possible for setuptools to just put the files 
> there.  I just haven't figured out how to do that.
>
>     Why the change to using setuptools by default in the first place?
>
>
> Long story.  The short story is that distutils was merged into 
> setuptools.  So setuptools is now the recommended way to install 
> python packages.
>
>
>     -Jeff
>>
>>     P.S.  Note that the other mpl_toolkits are installed into the
>>     correct place because they are shipped with matplotlib and
>>     installed at the same time.  We could ship basemap with
>>     matplotlib too but it's a rather large download.
>>
>>     Best wishes,
>>     Damon
>>
>>     -- 
>>     Damon McDougall
>>     http://www.damon-is-a-geek.com
>>     Institute for Computational Engineering Sciences
>>     201 E. 24th St.
>>     Stop C0200
>>     The University of Texas at Austin
>>     Austin, TX 78712-1229
>>     Eric Firing <mailto:ef...@ha...>
>>     July 6, 2013 12:53 AM
>>     If I do a clean install of mpl master, and then of basemap,
>>     basemap lands in dist-packages/mpl_toolkits, as it always has. 
>>     But now it is not found--I can't import it.  It seems that now
>>     the *real* mpl_toolkits is cleverly hidden inside an egg
>>     directory with a monstrous name, leaving basemap orphaned in a
>>     directory with no __init__.py.  As a workaround I can symlink it
>>     into the egg location.  I suspect the real solution will require
>>     basemap to use setuptools, correct?  I don't know how to do this,
>>     so I hope someone who does will submit a PR.
>>
>>     Eric
>>
>>     ------------------------------------------------------------------------
>
>
>
>
> -- 
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
> Jeff Whitaker <mailto:js...@fa...>
> July 6, 2013 10:04 AM
>> Damon McDougall <mailto:dam...@gm...>
>> July 6, 2013 9:32 AM
>>
>>
>>
>>     If I do a clean install of mpl master, and then of basemap, basemap
>>     lands in dist-packages/mpl_toolkits, as it always has.  But now it is
>>     not found--I can't import it.  It seems that now the *real*
>>     mpl_toolkits
>>     is cleverly hidden inside an egg directory with a monstrous name,
>>     leaving basemap orphaned in a directory with no __init__.py.  As a
>>     workaround I can symlink it into the egg location.  I suspect the
>>     real
>>     solution will require basemap to use setuptools, correct?  I
>>     don't know
>>     how to do this, so I hope someone who does will submit a PR.
>>
>>
>> Actually, using the new setuptools isn't adequate, I just tried it 
>> locally on my machine and it still doesn't install itself into the 
>> matplotlib egg.
>>
>> I think the proper solution here is to add basemap as an optional 
>> dependency to matplotlib and have the user set a flag (off by 
>> default) to pull basemap if it's desired
>>
>> Does that sound like a reasonable solution?
>
> What if a user decides later that he/she wants to install basemap?  
> Then they would have to reinstall matplotlib?  That doesn't sound 
> reasonable to me.
>
> How about having matplotlib install a symlink to the egg location?
>
> Why the change to using setuptools by default in the first place?
>
> -Jeff
>>
>> P.S.  Note that the other mpl_toolkits are installed into the correct 
>> place because they are shipped with matplotlib and installed at the 
>> same time.  We could ship basemap with matplotlib too but it's a 
>> rather large download.
>>
>> Best wishes,
>> Damon
>>
>> -- 
>> Damon McDougall
>> http://www.damon-is-a-geek.com
>> Institute for Computational Engineering Sciences
>> 201 E. 24th St.
>> Stop C0200
>> The University of Texas at Austin
>> Austin, TX 78712-1229
>> Eric Firing <mailto:ef...@ha...>
>> July 6, 2013 12:53 AM
>> If I do a clean install of mpl master, and then of basemap, basemap 
>> lands in dist-packages/mpl_toolkits, as it always has.  But now it is 
>> not found--I can't import it.  It seems that now the *real* 
>> mpl_toolkits is cleverly hidden inside an egg directory with a 
>> monstrous name, leaving basemap orphaned in a directory with no 
>> __init__.py.  As a workaround I can symlink it into the egg 
>> location.  I suspect the real solution will require basemap to use 
>> setuptools, correct?  I don't know how to do this, so I hope someone 
>> who does will submit a PR.
>>
>> Eric
>>
>> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> Damon McDougall <mailto:dam...@gm...>
> July 6, 2013 9:32 AM
>
>
>
>     If I do a clean install of mpl master, and then of basemap, basemap
>     lands in dist-packages/mpl_toolkits, as it always has.  But now it is
>     not found--I can't import it.  It seems that now the *real*
>     mpl_toolkits
>     is cleverly hidden inside an egg directory with a monstrous name,
>     leaving basemap orphaned in a directory with no __init__.py.  As a
>     workaround I can symlink it into the egg location.  I suspect the real
>     solution will require basemap to use setuptools, correct?  I don't
>     know
>     how to do this, so I hope someone who does will submit a PR.
>
>
> Actually, using the new setuptools isn't adequate, I just tried it 
> locally on my machine and it still doesn't install itself into the 
> matplotlib egg.
>
> I think the proper solution here is to add basemap as an optional 
> dependency to matplotlib and have the user set a flag (off by default) 
> to pull basemap if it's desired.
>
> Does that sound like a reasonable solution?
>
> P.S.  Note that the other mpl_toolkits are installed into the correct 
> place because they are shipped with matplotlib and installed at the 
> same time.  We could ship basemap with matplotlib too but it's a 
> rather large download.
>
> Best wishes,
> Damon
>
> -- 
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
> Eric Firing <mailto:ef...@ha...>
> July 6, 2013 12:53 AM
> If I do a clean install of mpl master, and then of basemap, basemap 
> lands in dist-packages/mpl_toolkits, as it always has.  But now it is 
> not found--I can't import it.  It seems that now the *real* 
> mpl_toolkits is cleverly hidden inside an egg directory with a 
> monstrous name, leaving basemap orphaned in a directory with no 
> __init__.py.  As a workaround I can symlink it into the egg location.  
> I suspect the real solution will require basemap to use setuptools, 
> correct?  I don't know how to do this, so I hope someone who does will 
> submit a PR.
>
> Eric
>
> ------------------------------------------------------------------------

Re: [matplotlib-devel] basemap installation problem with mpl master

[Damon M. <dam...@gm...>]

On Sat, Jul 6, 2013 at 12:20 PM, Eric Firing <ef...@ha...> wrote:

> On 2013/07/06 5:32 AM, Damon McDougall wrote:
>
>>
>>
>>
>> On Sat, Jul 6, 2013 at 1:53 AM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...>> wrote:
>>
>>     If I do a clean install of mpl master, and then of basemap, basemap
>>     lands in dist-packages/mpl_toolkits, as it always has.  But now it is
>>     not found--I can't import it.  It seems that now the *real*
>> mpl_toolkits
>>     is cleverly hidden inside an egg directory with a monstrous name,
>>     leaving basemap orphaned in a directory with no __init__.py.  As a
>>     workaround I can symlink it into the egg location.  I suspect the real
>>     solution will require basemap to use setuptools, correct?  I don't
>> know
>>     how to do this, so I hope someone who does will submit a PR.
>>
>>
>> Actually, using the new setuptools isn't adequate, I just tried it
>> locally on my machine and it still doesn't install itself into the
>> matplotlib egg.
>>
>
> Thank you for giving it a try.


No worries.  All I did was use matplotlib's distribute_setup.py file and
add the lines

from distribute_setup import use_setuptools
use_setuptools()

to setup.py.

I'm sure there's extra setuptools foo I need to make it play nicely with
the matplotlib egg, but I haven't at all looked into it in any detail.


>
>
>
>> I think the proper solution here is to add basemap as an optional
>> dependency to matplotlib and have the user set a flag (off by default)
>> to pull basemap if it's desired.
>>
>> Does that sound like a reasonable solution?
>>
>
> No, unfortunately.  First, because fundamentally, matplotlib is a
> dependency of basemap, not the other way around.  Second, because I want to
> be able to pull basemap from git and do the usual "setup.py build, setup.py
> install" independently of matplotlib.
>

Ah yes, that's entirely reasonable.


>
> It sounds like the only real solution will be for basemap to live as an
> independent package in dist-packages, and drop the mpl_toolkits umbrella
> entirely.  I don't see that it does any good anyway.  It seems setuptools
> has irretrievably broken the usefulness of mpl_toolkits as anything other
> than a place to put sub-packages that are distributed with mpl, and that
> live in the same git repo.
>

That's sounds reasonable to me.  But there's a part of me that can't help
thinking that what we're trying to do should be entirely possible.  Perhaps
it's more hacky, though.


>
> Moving basemap out of mpl_toolkits would also simplify the basemap
> directory structure.  I don't see any downside other than the pain of the
> transition itself, including the problem of user code needing to have every
> import of basemap handle both possible locations.
>

I'm not against having it as a separate package.  We can deprecate the old
location and remove it in 1.5.x, say.


>
> The setuptools arrangement of having mpl_toolkits hidden in an egg, but
> still imported as "import mpl_toolkits", seems like a horrible design. I'm
> also uncomfortable with the new behavior in which the standard command to
> build and install mpl triggers an avalanche of potential package
> installations.  Oh, well...


Yes, I know.  It's a mess.  Also notice that it's really hard to downgrade
to maptlotlib version 1.3.x after having installed 1.4.x, because
setuptools creates an egg for each version.  In principle this is nice as,
I assume, it offers the flexibility to switch between different matplotlib
versions on the fly.  That said, I see no way to actually do this.


>
>
> Eric
>
>
>
>> P.S.  Note that the other mpl_toolkits are installed into the correct
>> place because they are shipped with matplotlib and installed at the same
>> time.  We could ship basemap with matplotlib too but it's a rather large
>> download.
>>
>> Best wishes,
>> Damon
>>
>> --
>> Damon McDougall
>> http://www.damon-is-a-geek.com
>> Institute for Computational Engineering Sciences
>> 201 E. 24th St.
>> Stop C0200
>> The University of Texas at Austin
>> Austin, TX 78712-1229
>>
>
>


-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

Re: [matplotlib-devel] basemap installation problem with mpl master

[Damon M. <dam...@gm...>]

On Sat, Jul 6, 2013 at 12:26 PM, Thomas Kluyver <th...@kl...>wrote:

> On 6 July 2013 18:20, Damon McDougall <dam...@gm...> wrote:
>
>> Long story.  The short story is that distutils was merged into
>> setuptools.  So setuptools is now the recommended way to install python
>> packages.
>
>
> *distribute*, which was a fork of setuptools, was merged into setuptools.
> *distutils* is the component in the standard library, and is still there. I
> still prefer distutils where possible, precisely because setuptools' eggs
> are a mess.
>

Sorry, yes.  My mistake.


>
>
> Thomas
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>


-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

Re: [matplotlib-devel] basemap installation problem with mpl master

[Thomas K. <th...@kl...>]

On 6 July 2013 18:20, Damon McDougall <dam...@gm...> wrote:

> Long story.  The short story is that distutils was merged into setuptools.
>  So setuptools is now the recommended way to install python packages.


*distribute*, which was a fork of setuptools, was merged into setuptools.
*distutils* is the component in the standard library, and is still there. I
still prefer distutils where possible, precisely because setuptools' eggs
are a mess.

Thomas

Re: [matplotlib-devel] basemap installation problem with mpl master

[Eric F. <ef...@ha...>]

On 2013/07/06 5:32 AM, Damon McDougall wrote:
>
>
>
> On Sat, Jul 6, 2013 at 1:53 AM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     If I do a clean install of mpl master, and then of basemap, basemap
>     lands in dist-packages/mpl_toolkits, as it always has.  But now it is
>     not found--I can't import it.  It seems that now the *real* mpl_toolkits
>     is cleverly hidden inside an egg directory with a monstrous name,
>     leaving basemap orphaned in a directory with no __init__.py.  As a
>     workaround I can symlink it into the egg location.  I suspect the real
>     solution will require basemap to use setuptools, correct?  I don't know
>     how to do this, so I hope someone who does will submit a PR.
>
>
> Actually, using the new setuptools isn't adequate, I just tried it
> locally on my machine and it still doesn't install itself into the
> matplotlib egg.

Thank you for giving it a try.

>
> I think the proper solution here is to add basemap as an optional
> dependency to matplotlib and have the user set a flag (off by default)
> to pull basemap if it's desired.
>
> Does that sound like a reasonable solution?

No, unfortunately.  First, because fundamentally, matplotlib is a 
dependency of basemap, not the other way around.  Second, because I want 
to be able to pull basemap from git and do the usual "setup.py build, 
setup.py install" independently of matplotlib.

It sounds like the only real solution will be for basemap to live as an 
independent package in dist-packages, and drop the mpl_toolkits umbrella 
entirely.  I don't see that it does any good anyway.  It seems 
setuptools has irretrievably broken the usefulness of mpl_toolkits as 
anything other than a place to put sub-packages that are distributed 
with mpl, and that live in the same git repo.

Moving basemap out of mpl_toolkits would also simplify the basemap 
directory structure.  I don't see any downside other than the pain of 
the transition itself, including the problem of user code needing to 
have every import of basemap handle both possible locations.

The setuptools arrangement of having mpl_toolkits hidden in an egg, but 
still imported as "import mpl_toolkits", seems like a horrible design. 
I'm also uncomfortable with the new behavior in which the standard 
command to build and install mpl triggers an avalanche of potential 
package installations.  Oh, well...

Eric

>
> P.S.  Note that the other mpl_toolkits are installed into the correct
> place because they are shipped with matplotlib and installed at the same
> time.  We could ship basemap with matplotlib too but it's a rather large
> download.
>
> Best wishes,
> Damon
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229

Re: [matplotlib-devel] basemap installation problem with mpl master

[Jeff W. <js...@fa...>]

> Damon McDougall <mailto:dam...@gm...>
> July 6, 2013 9:32 AM
>
>
>
>     If I do a clean install of mpl master, and then of basemap, basemap
>     lands in dist-packages/mpl_toolkits, as it always has.  But now it is
>     not found--I can't import it.  It seems that now the *real*
>     mpl_toolkits
>     is cleverly hidden inside an egg directory with a monstrous name,
>     leaving basemap orphaned in a directory with no __init__.py.  As a
>     workaround I can symlink it into the egg location.  I suspect the real
>     solution will require basemap to use setuptools, correct?  I don't
>     know
>     how to do this, so I hope someone who does will submit a PR.
>
>
> Actually, using the new setuptools isn't adequate, I just tried it 
> locally on my machine and it still doesn't install itself into the 
> matplotlib egg.
>
> I think the proper solution here is to add basemap as an optional 
> dependency to matplotlib and have the user set a flag (off by default) 
> to pull basemap if it's desired
>
> Does that sound like a reasonable solution?

What if a user decides later that he/she wants to install basemap?  Then 
they would have to reinstall matplotlib?  That doesn't sound reasonable 
to me.

How about having matplotlib install a symlink to the egg location?

Why the change to using setuptools by default in the first place?

-Jeff
>
> P.S.  Note that the other mpl_toolkits are installed into the correct 
> place because they are shipped with matplotlib and installed at the 
> same time.  We could ship basemap with matplotlib too but it's a 
> rather large download.
>
> Best wishes,
> Damon
>
> -- 
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
> Eric Firing <mailto:ef...@ha...>
> July 6, 2013 12:53 AM
> If I do a clean install of mpl master, and then of basemap, basemap 
> lands in dist-packages/mpl_toolkits, as it always has.  But now it is 
> not found--I can't import it.  It seems that now the *real* 
> mpl_toolkits is cleverly hidden inside an egg directory with a 
> monstrous name, leaving basemap orphaned in a directory with no 
> __init__.py.  As a workaround I can symlink it into the egg location.  
> I suspect the real solution will require basemap to use setuptools, 
> correct?  I don't know how to do this, so I hope someone who does will 
> submit a PR.
>
> Eric
>
> ------------------------------------------------------------------------

Re: [matplotlib-devel] basemap installation problem with mpl master

[Damon M. <dam...@gm...>]

On Sat, Jul 6, 2013 at 1:53 AM, Eric Firing <ef...@ha...> wrote:

> If I do a clean install of mpl master, and then of basemap, basemap
> lands in dist-packages/mpl_toolkits, as it always has.  But now it is
> not found--I can't import it.  It seems that now the *real* mpl_toolkits
> is cleverly hidden inside an egg directory with a monstrous name,
> leaving basemap orphaned in a directory with no __init__.py.  As a
> workaround I can symlink it into the egg location.  I suspect the real
> solution will require basemap to use setuptools, correct?  I don't know
> how to do this, so I hope someone who does will submit a PR.


Actually, using the new setuptools isn't adequate, I just tried it locally
on my machine and it still doesn't install itself into the matplotlib egg.

I think the proper solution here is to add basemap as an optional
dependency to matplotlib and have the user set a flag (off by default) to
pull basemap if it's desired.

Does that sound like a reasonable solution?

P.S.  Note that the other mpl_toolkits are installed into the correct place
because they are shipped with matplotlib and installed at the same time.
 We could ship basemap with matplotlib too but it's a rather large download.

Best wishes,
Damon

-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

[matplotlib-devel] basemap installation problem with mpl master

[Eric F. <ef...@ha...>]

If I do a clean install of mpl master, and then of basemap, basemap 
lands in dist-packages/mpl_toolkits, as it always has.  But now it is 
not found--I can't import it.  It seems that now the *real* mpl_toolkits 
is cleverly hidden inside an egg directory with a monstrous name, 
leaving basemap orphaned in a directory with no __init__.py.  As a 
workaround I can symlink it into the egg location.  I suspect the real 
solution will require basemap to use setuptools, correct?  I don't know 
how to do this, so I hope someone who does will submit a PR.

Eric

[matplotlib-devel] Completely wrong tick formatting

[Pål G. E. <pa...@gm...>]

Hi

I'm having some problems with the formatter of ticks in a polar plot.
Below is a minimum example
The first figure is correct, the second has wrong ticks.

This has be tested both on 1.2.0 and the latest from git (1.4.x, commit
64cc3416396ffb2811af80fc810ed63572df71d9 )

Does anyone know whys this happens?
Is it a bug in MaxNLocator

Kind regards

Pål

---------------------------
#!/usr/bin/env python

import numpy as np
import matplotlib.pyplot as plt
from matplotlib.ticker import MaxNLocator

# Data
M=np.sin(np.meshgrid(np.arange(30),np.arange(30)))
M=np.squeeze(M[0,:,:])
Radius=np.arange(30)
Theta=np.arange(30)

# Plotting the correct figure
print('Correct ticks')
fig=plt.figure()
ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
c = ax1.pcolormesh(Theta, Radius, M)
ax1.set_frame_on(False)
plt.xticks([])
plt.yticks([])
ax2=fig.add_axes([0.9,0.1,0.05,0.7])
cb=fig.colorbar(c,cax=ax2)
plt.show()

# Doing the same plot
print('Wrong ticks by using formatter')
fig=plt.figure()
ax1 = fig.add_axes([0,0,0.8,1],projection='polar')
c = ax1.pcolormesh(Theta, Radius, M)
ax1.set_frame_on(False)
plt.xticks([])
plt.yticks([])
ax2=fig.add_axes([0.9,0.1,0.05,0.7])
cb=fig.colorbar(c,cax=ax2)

# except now setting a limit to the number of ticks using a formatter
# which results in wrong ticks
cb.ax.yaxis.set_major_locator(MaxNLocator(3))
plt.show()
-----------------------