matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] assertion error with xkcd

[Michael D. <md...@st...>]

On 10/23/2013 09:51 AM, Neal Becker wrote:
> Benjamin Root wrote:
>
>> Can you provide a code example to reproduce this. I suspect that recent
>> work on path effects might be to blame here. Also, exactly which version of
>> matplotlib and numpy were you using? The assert was placed there about a
>> year ago IIRC to deal with a short-lived numpy bug.
> The code is large and reads a bunch of data to plot.
>
>
> The line that triggers the error says:
>
>      self.pdf.savefig (self.fig)
>
> Would it be useful to provide a pickled fig (umm,,, pickled figs)
No, we really need a self-contained example that triggers it.  We 
already have a self-contained example that works (multipage_pdf.py in 
the examples)...  So there's something extra that's happening in your 
context.  Maybe start with multipage_pdf.py and add things from your own 
app until it breaks?

Mike


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

Re: [matplotlib-devel] Weird issue with mpl-1.3.1 install

[Neal B. <ndb...@gm...>]

OK, this seems to be a pip caching bug.  After rm -rf /tmp/pip*, it installed 
correctly

Neal Becker wrote:

> This is really strange.  It d/l 1.3.1, but then builds installs 1.3.0???
> 
> python3-pip install --user --up --no-deps matplotlib
> Downloading/unpacking matplotlib from
> 
https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.1/matplotlib-1.3.1.tar.gz
>   Running setup.py egg_info for package matplotlib
>     
============================================================================
>     Edit setup.cfg to change the build options
>     
>     BUILDING MATPLOTLIB
>                 matplotlib: yes [1.3.0]
>                     python: yes [3.3.2 (default, Aug 23 2013, 19:00:04)  [GCC
>                             4.8.1 20130603 (Red Hat 4.8.1-1)]]
>                   platform: yes [linux]
>     
>     REQUIRED DEPENDENCIES AND EXTENSIONS
>                      numpy: yes [version 1.7.1]
>                   dateutil: yes [using dateutil version 2.1]
>                    tornado: yes [using tornado version 3.1.1]
>                  pyparsing: yes [using pyparsing version 2.0.1]
>                      pycxx: yes [Official versions of PyCXX are not compatible
>                             with Python 3.x.  Using local copy]
>                     libagg: yes [Requires patches that have not been merged
>                             upstream. Using local copy.]
>                   freetype: yes [version 16.0.10]
>                        png: yes [version 1.5.13]
>     
>     OPTIONAL SUBPACKAGES
>                sample_data: yes [installing]
>                   toolkits: yes [installing]
>                      tests: yes [using nose version 1.3.0]
>     
>     OPTIONAL BACKEND EXTENSIONS
>                     macosx: no  [Mac OS-X only]
>                     qt4agg: yes [Qt: 4.8.4, PyQt4: 4.10.1]
>                    gtk3agg: no  [gtk3agg backend does not work on Python 3]
>                  gtk3cairo: no  [Requires pygobject to be installed.]
>                     gtkagg: no  [Requires pygtk]
>                      tkagg: no  [The C/C++ header for Tk (tk.h) could not be
>                             found.  You may need to install the development
>                             package.]
>                      wxagg: no  [requires wxPython]
>                        gtk: no  [Requires pygtk]
>                        agg: yes [installing]
>                      cairo: yes [version 1.10.0]
>                  windowing: no  [Microsoft Windows only]
>     
>     OPTIONAL LATEX DEPENDENCIES
>                     dvipng: yes [version 1.14]
>                ghostscript: yes [version 9.10]
>                      latex: yes [version 3.1415926]
>                    pdftops: yes [version 0.22.1]
>     
>     
> Installing collected packages: matplotlib
>   Found existing installation: matplotlib 1.3.0
>     Uninstalling matplotlib:
>       Successfully uninstalled matplotlib
>   Running setup.py install for matplotlib
>     
============================================================================
>     Edit setup.cfg to change the build options
>     
>     BUILDING MATPLOTLIB
>                 matplotlib: yes [1.3.0]
>                     python: yes [3.3.2 (default, Aug 23 2013, 19:00:04)  [GCC
>                             4.8.1 20130603 (Red Hat 4.8.1-1)]]
>                   platform: yes [linux]
>     
>     REQUIRED DEPENDENCIES AND EXTENSIONS
>                      numpy: yes [version 1.7.1]
>                   dateutil: yes [using dateutil version 2.1]
>                    tornado: yes [using tornado version 3.1.1]
>                  pyparsing: yes [using pyparsing version 2.0.1]
>                      pycxx: yes [Official versions of PyCXX are not compatible
>                             with Python 3.x.  Using local copy]
>                     libagg: yes [Requires patches that have not been merged
>                             upstream. Using local copy.]
>                   freetype: yes [version 16.0.10]
>                        png: yes [version 1.5.13]
>     
>     OPTIONAL SUBPACKAGES
>                sample_data: yes [installing]
>                   toolkits: yes [installing]
>                      tests: yes [using nose version 1.3.0]
>     
>     OPTIONAL BACKEND EXTENSIONS
>                     macosx: no  [Mac OS-X only]
>                     qt4agg: yes [Qt: 4.8.4, PyQt4: 4.10.1]
>                    gtk3agg: no  [gtk3agg backend does not work on Python 3]
>                  gtk3cairo: no  [Requires pygobject to be installed.]
>                     gtkagg: no  [Requires pygtk]
>                      tkagg: no  [The C/C++ header for Tk (tk.h) could not be
>                             found.  You may need to install the development
>                             package.]
>                      wxagg: no  [requires wxPython]
>                        gtk: no  [Requires pygtk]
>                        agg: yes [installing]
>                      cairo: yes [version 1.10.0]
>                  windowing: no  [Microsoft Windows only]
>     
>     OPTIONAL LATEX DEPENDENCIES
>                     dvipng: yes [version 1.14]
>                ghostscript: yes [version 9.10]
>                      latex: yes [version 3.1415926]
>                    pdftops: yes [version 0.22.1]
>     
>     Skipping installation of /home/nbecker/.local/lib/python3.3/site-
> packages/mpl_toolkits/__init__.py (namespace package)
>     
>     Installing /home/nbecker/.local/lib/python3.3/site-
> packages/matplotlib-1.3.0-py3.3-nspkg.pth
> Successfully installed matplotlib
> Cleaning up...
> [
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk

Re: [matplotlib-devel] assertion error with xkcd

[Neal B. <ndb...@gm...>]

Benjamin Root wrote:

> Can you provide a code example to reproduce this. I suspect that recent
> work on path effects might be to blame here. Also, exactly which version of
> matplotlib and numpy were you using? The assert was placed there about a
> year ago IIRC to deal with a short-lived numpy bug.

The code is large and reads a bunch of data to plot.


The line that triggers the error says:

    self.pdf.savefig (self.fig)

Would it be useful to provide a pickled fig (umm,,, pickled figs)

[matplotlib-devel] Weird issue with mpl-1.3.1 install

[Neal B. <ndb...@gm...>]

This is really strange.  It d/l 1.3.1, but then builds installs 1.3.0???

python3-pip install --user --up --no-deps matplotlib
Downloading/unpacking matplotlib from 
https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.1/matplotlib-1.3.1.tar.gz
  Running setup.py egg_info for package matplotlib
    ============================================================================
    Edit setup.cfg to change the build options
    
    BUILDING MATPLOTLIB
                matplotlib: yes [1.3.0]
                    python: yes [3.3.2 (default, Aug 23 2013, 19:00:04)  [GCC
                            4.8.1 20130603 (Red Hat 4.8.1-1)]]
                  platform: yes [linux]
    
    REQUIRED DEPENDENCIES AND EXTENSIONS
                     numpy: yes [version 1.7.1]
                  dateutil: yes [using dateutil version 2.1]
                   tornado: yes [using tornado version 3.1.1]
                 pyparsing: yes [using pyparsing version 2.0.1]
                     pycxx: yes [Official versions of PyCXX are not compatible
                            with Python 3.x.  Using local copy]
                    libagg: yes [Requires patches that have not been merged
                            upstream. Using local copy.]
                  freetype: yes [version 16.0.10]
                       png: yes [version 1.5.13]
    
    OPTIONAL SUBPACKAGES
               sample_data: yes [installing]
                  toolkits: yes [installing]
                     tests: yes [using nose version 1.3.0]
    
    OPTIONAL BACKEND EXTENSIONS
                    macosx: no  [Mac OS-X only]
                    qt4agg: yes [Qt: 4.8.4, PyQt4: 4.10.1]
                   gtk3agg: no  [gtk3agg backend does not work on Python 3]
                 gtk3cairo: no  [Requires pygobject to be installed.]
                    gtkagg: no  [Requires pygtk]
                     tkagg: no  [The C/C++ header for Tk (tk.h) could not be
                            found.  You may need to install the development
                            package.]
                     wxagg: no  [requires wxPython]
                       gtk: no  [Requires pygtk]
                       agg: yes [installing]
                     cairo: yes [version 1.10.0]
                 windowing: no  [Microsoft Windows only]
    
    OPTIONAL LATEX DEPENDENCIES
                    dvipng: yes [version 1.14]
               ghostscript: yes [version 9.10]
                     latex: yes [version 3.1415926]
                   pdftops: yes [version 0.22.1]
    
    
Installing collected packages: matplotlib
  Found existing installation: matplotlib 1.3.0
    Uninstalling matplotlib:
      Successfully uninstalled matplotlib
  Running setup.py install for matplotlib
    ============================================================================
    Edit setup.cfg to change the build options
    
    BUILDING MATPLOTLIB
                matplotlib: yes [1.3.0]
                    python: yes [3.3.2 (default, Aug 23 2013, 19:00:04)  [GCC
                            4.8.1 20130603 (Red Hat 4.8.1-1)]]
                  platform: yes [linux]
    
    REQUIRED DEPENDENCIES AND EXTENSIONS
                     numpy: yes [version 1.7.1]
                  dateutil: yes [using dateutil version 2.1]
                   tornado: yes [using tornado version 3.1.1]
                 pyparsing: yes [using pyparsing version 2.0.1]
                     pycxx: yes [Official versions of PyCXX are not compatible
                            with Python 3.x.  Using local copy]
                    libagg: yes [Requires patches that have not been merged
                            upstream. Using local copy.]
                  freetype: yes [version 16.0.10]
                       png: yes [version 1.5.13]
    
    OPTIONAL SUBPACKAGES
               sample_data: yes [installing]
                  toolkits: yes [installing]
                     tests: yes [using nose version 1.3.0]
    
    OPTIONAL BACKEND EXTENSIONS
                    macosx: no  [Mac OS-X only]
                    qt4agg: yes [Qt: 4.8.4, PyQt4: 4.10.1]
                   gtk3agg: no  [gtk3agg backend does not work on Python 3]
                 gtk3cairo: no  [Requires pygobject to be installed.]
                    gtkagg: no  [Requires pygtk]
                     tkagg: no  [The C/C++ header for Tk (tk.h) could not be
                            found.  You may need to install the development
                            package.]
                     wxagg: no  [requires wxPython]
                       gtk: no  [Requires pygtk]
                       agg: yes [installing]
                     cairo: yes [version 1.10.0]
                 windowing: no  [Microsoft Windows only]
    
    OPTIONAL LATEX DEPENDENCIES
                    dvipng: yes [version 1.14]
               ghostscript: yes [version 9.10]
                     latex: yes [version 3.1415926]
                   pdftops: yes [version 0.22.1]
    
    Skipping installation of /home/nbecker/.local/lib/python3.3/site-
packages/mpl_toolkits/__init__.py (namespace package)
    
    Installing /home/nbecker/.local/lib/python3.3/site-
packages/matplotlib-1.3.0-py3.3-nspkg.pth
Successfully installed matplotlib
Cleaning up...
[

Re: [matplotlib-devel] assertion error with xkcd

[Michael D. <md...@st...>]

Can you provide a standalone example to reproduce?  The multipage_pdf.py 
example works fine with xkcd switched on.

Mike

On 10/23/2013 08:01 AM, Neal Becker wrote:
> This was using pdfpages (if that matters)
>
> Traceback (most recent call last):
>    File "./plot_stuff2.py", line 326, in <module>
>      the_plot.finish (args, opt, time, res)
>    File "./plot_stuff2.py", line 145, in finish
>      self.pdf.savefig (self.fig)
>    File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backends/backend_pdf.py", line 2297, in savefig
>      figure.savefig(self, format='pdf', **kwargs)
>    File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/figure.py",
> line 1421, in savefig
>      self.canvas.print_figure(*args, **kwargs)
>    File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backend_bases.py", line 2220, in print_figure
>      **kwargs)
>    File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backends/backend_pdf.py", line 2340, in print_pdf
>      self.figure.draw(renderer)
>    File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/artist.py",
> line 54, in draw_wrapper
>      draw(artist, renderer, *args, **kwargs)
>    File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/figure.py",
> line 1034, in draw
>      func(*args)
>    File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/artist.py",
> line 54, in draw_wrapper
>      draw(artist, renderer, *args, **kwargs)
>    File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/text.py",
> line 589, in draw
>      self._fontproperties, angle)
>    File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/patheffects.py", line 102, in draw_text
>      self._draw_text_as_path(renderer, gc, x, y, s, prop, angle, ismath)
>    File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/patheffects.py", line 112, in _draw_text_as_path
>      ismath)
>    File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backend_bases.py", line 526, in _get_text_path_transform
>      path = Path(verts, codes)
>    File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/path.py",
> line 147, in __init__
>      assert vertices.ndim == 2
> AssertionError
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

Re: [matplotlib-devel] assertion error with xkcd

[Benjamin R. <ben...@ou...>]

Can you provide a code example to reproduce this. I suspect that recent
work on path effects might be to blame here. Also, exactly which version of
matplotlib and numpy were you using? The assert was placed there about a
year ago IIRC to deal with a short-lived numpy bug.

Re: [matplotlib-devel] mpl 1.3.1 install issues with py3.3

[Benjamin R. <ben...@ou...>]

This isn't a matplotlib bug. Somehow, a py2.x version of nose got into your
python3.3 site-packages. Try clearing that out first. Of course, it might
still be possible that we are somehow forcing the wrong nose to be
installed...

[matplotlib-devel] assertion error with xkcd

[Neal B. <ndb...@gm...>]

This was using pdfpages (if that matters)

Traceback (most recent call last):
  File "./plot_stuff2.py", line 326, in <module>
    the_plot.finish (args, opt, time, res)
  File "./plot_stuff2.py", line 145, in finish
    self.pdf.savefig (self.fig)
  File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/backends/backend_pdf.py", line 2297, in savefig
    figure.savefig(self, format='pdf', **kwargs)
  File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/figure.py", 
line 1421, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/backend_bases.py", line 2220, in print_figure
    **kwargs)
  File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/backends/backend_pdf.py", line 2340, in print_pdf
    self.figure.draw(renderer)
  File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/artist.py", 
line 54, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/figure.py", 
line 1034, in draw
    func(*args)
  File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/artist.py", 
line 54, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/text.py", 
line 589, in draw
    self._fontproperties, angle)
  File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/patheffects.py", line 102, in draw_text
    self._draw_text_as_path(renderer, gc, x, y, s, prop, angle, ismath)
  File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/patheffects.py", line 112, in _draw_text_as_path
    ismath)
  File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/backend_bases.py", line 526, in _get_text_path_transform
    path = Path(verts, codes)
  File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/path.py", 
line 147, in __init__
    assert vertices.ndim == 2
AssertionError

[matplotlib-devel] mpl 1.3.1 install issues with py3.3

[Neal B. <ndb...@gm...>]

pip install of mpl 1.3.1 has issues.
It wants to install nose, but seems to be incompatible with py3.3:

  Running setup.py install for nose
      File "/home/nbecker/.local/lib/python3.3/site-
packages/nose/plugins/base.py", line 70
        except OptionConflictError, e:
                                  ^
    SyntaxError: invalid syntax
    
      File "/home/nbecker/.local/lib/python3.3/site-
packages/nose/plugins/multiprocess.py", line 481
        except (KeyboardInterrupt, SystemExit), e:
                                              ^
    SyntaxError: invalid syntax
  

[matplotlib-devel] feedback on multi-figure-manager

[Federico A. <ari...@gm...>]

Hello everybody

Its been a couple of weeks an I was wondering if anybody has feedback for me.
https://github.com/matplotlib/matplotlib/pull/2465

I changed the description on the PR to be more precise.
At the begining I called it tabbed gtk3 figuremanager but it is more a
multi-figure-manager with the first implementation in gtk3.

Thanks
Federico
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

Re: [matplotlib-devel] OS-X binaries?

[Matthew B. <mat...@gm...>]

Hi Chris,

On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
<chr...@no...> wrote:
> Are there recent binaries for OS-X anywhere? There don't seem to be
> any for recent releases on the MPL download page.
>
> I know we had a discussion about this a whole back, but don't remember
> the outcome. But I hope we'll continue to put them up-- macports and
> friends really aren't the best solutions for everyone.

I hope I have this cracked now, at least in principle.

The latest versions are here:

http://nipy.bic.berkeley.edu/scipy_installers/

Following Matt Terry's example, I'm testing the builds and then the
installers here:

https://travis-ci.org/matthew-brett/mpl-osx-binaries

It would be great if you could give them a try.

Cheers,

Matthew

Re: [matplotlib-devel] Pull request

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

On Tue, Oct 22, 2013 at 6:06 PM, Pierre Haessig <pie...@cr...>wrote:

>  Hi,
>
> Le 21/10/2013 15:58, Todd a écrit :
>
>  On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig <pie...@cr...
> > wrote:
>
>    1) is the terminology "phase" vs. "angle" spectrum standardized ? I
>> must
>> say I've never heard of one meaning "wrapped" and the other "unwrapped".
>> I didn't find similar terms in Matlab docs, but I didn't search that
>> thoroughly.
>>
>
>  The "angle" function in numpy returns the wrapped angle, while the
> "unwrap" function documentation talks about phase, so it is consistent with
> the usage in numpy.   Further, in signal processing, phases can have any
> value, while "angle" often refers to the angle between two lines, which
> must be wrapped.
>
>  There may be some ambiguity, but I made sure to explain it in the
> documentation and provide links between the two functions so people know
> what they should do if they want to use the other approach.
>
>
>> 2) Should there be two separate functions for these two, or just one
>> function, with a switch argument `unwrap` ? (I guess it would be True by
>> default)
>>
>
>  I originally was going to do that, but decided against it.  The problem
> is with specgram.  Here, I thought it would be needlessly complicated to
> add an "unwrap" parameter that is only useful for one "mode".  To make it
> obvious to users, I wanted to keep specgram as similar as possible to the
> other plot types, and that involved keeping the parameter.
>
> Further, this approach is simpler to code and easier to maintain. Having
> to deal with the "unwrap" parameter would have been more difficult to
> program.  Dealing with both an "unwrap" parameter in some cases and a
> separate "mode" in others would have been even more complicated.
>
> Further, _spectral_helper and specgram already have a huge number of
> arguments.  This way I was able to get away with just adding one new
> argument rather than two.
>
>  Thanks for the feedback. I agree that your documentation does make clear
> the distinction between "phase" and "angle" and that it has a consistency.
> I just feel that this distinction does not exist "outside" ...
>
> But beyond this question of phase vs. angle, I must say I don't see that
> big a use case for phase/angle spectrums[*] (as opposed to magnitude which
> are much used).
>

I personally use phase and angle spectrums a huge amount.  In signal
processing it is extremely important.  It is a critical component in
acoustics.  It is also used a lot to separate out signals that have been
mixed together.  Knowing the phases of signals can also be very important
in certain optics applications and for radio signals and RADAR.  Changes in
the phase spectrum over time (like you would get from a phase spectrogram)
is important for doppler analysis both with optical and acoustic signals.

Also, from an educational perspective, anyone taking a digital signal
processing course will need to produce magnitude/phase plots, probably both
with and without wrapping (since any decent digital signal processing
course will teach you about the pitfalls that occur due to phase
wrapping).  So this will make matplotlib much more useful for such courses.


> Also, in many cases, "spectrum" is synonymous with spectral density, which
> implies "magnitude". In the end I wonder whether the notion of phase even
> makes sense for a spectrogram ?
>

Yes, particularly electrical engineering.  But there are many other fields
where spectral density is rarely used, and where more "ordinary" magnitude
and phase plots are the norm, as I explained in the previous paragraphs.

Re: [matplotlib-devel] OS-X binaries?

[Michael D. <md...@st...>]

Matthew Brett has an experimental installer that includes the Python 
dependencies:

http://matplotlib.1069221.n5.nabble.com/Any-progress-on-binary-installer-for-OSX-td42163.html

Once the remaining issues are ironed out, we'll definitely link to this 
from matplotlib.org/downloads.html

Mike

On 10/22/2013 12:03 PM, Chris Barker - NOAA Federal wrote:
> Are there recent binaries for OS-X anywhere? There don't seem to be
> any for recent releases on the MPL download page.
>
> I know we had a discussion about this a whole back, but don't remember
> the outcome. But I hope we'll continue to put them up-- macports and
> friends really aren't the best solutions for everyone.
>
> Chris
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

Re: [matplotlib-devel] Pull request

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

On Tue, Oct 22, 2013 at 5:41 PM, Pierre Haessig <pie...@cr...>wrote:

> Hi,
>
> Le 22/10/2013 12:31, Todd a écrit :
> > Currently, both axes.psd and axes.csd return the same thing as
> > mlab.psd and mlab.csd, namely the spectrum and frequency points.  They
> > do NOT return the line object that was plotted.  This is different
> > than specgram, which returns the AxesImage object that was plotted in
> > addition to the mlab.specgram return values.
> >
> > I think having access to the line object is important, so
> > axes.magnitude_spectrum, axes.angle_spectrum, and axes.phase_spectrum
> > do return the line object.  I know this is inconsistent, but I think
> > it is very important and would strongly objefct to removing this.
> >
> > The question, then, is whether this would be a good opportunity to add
> > the line object to the returned values for axes.psd and axes.csd.
> > This would be an API break, but would be very easy to fix, and it may
> > be beneficial enough to warrant it.  What does everyone think?
>
> I agree that it may be nice to have plt.psd/csd to return lines just
> like plt.plot for increased consistency. I guess that returning the
> values comes from Matlab style inspiration.
>
> Maybe breaking the API is too strong. In that case, adding a
> transitional keyword (for example `return_line=False`) to psd/csd may
> help introduce your new proposed behavior in a softer manner. What do
> you think ?
>
> Of course, for your new functions, there is no API breakage problem.
>
> best,
> Pierre
>

I considered that solution as well, but it seemed ugly.  However, I think
having it available is important, so I will add it.  The current behavior
can probably be deprecated at some point, allowing for a smoother
transition.

Re: [matplotlib-devel] Pull request

[Pierre H. <pie...@cr...>]

Hi,

Le 21/10/2013 15:58, Todd a écrit :
> On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig
> <pie...@cr... <mailto:pie...@cr...>> wrote:
>
>     1) is the terminology "phase" vs. "angle" spectrum standardized ?
>     I must
>     say I've never heard of one meaning "wrapped" and the other
>     "unwrapped".
>     I didn't find similar terms in Matlab docs, but I didn't search that
>     thoroughly.
>
>
> The "angle" function in numpy returns the wrapped angle, while the
> "unwrap" function documentation talks about phase, so it is consistent
> with the usage in numpy.   Further, in signal processing, phases can
> have any value, while "angle" often refers to the angle between two
> lines, which must be wrapped.
>
> There may be some ambiguity, but I made sure to explain it in the
> documentation and provide links between the two functions so people
> know what they should do if they want to use the other approach.
>  
>
>     2) Should there be two separate functions for these two, or just one
>     function, with a switch argument `unwrap` ? (I guess it would be
>     True by
>     default)
>
>
> I originally was going to do that, but decided against it.  The
> problem is with specgram.  Here, I thought it would be needlessly
> complicated to add an "unwrap" parameter that is only useful for one
> "mode".  To make it obvious to users, I wanted to keep specgram as
> similar as possible to the other plot types, and that involved keeping
> the parameter.
>
> Further, this approach is simpler to code and easier to maintain.
> Having to deal with the "unwrap" parameter would have been more
> difficult to program.  Dealing with both an "unwrap" parameter in some
> cases and a separate "mode" in others would have been even more
> complicated.
>
> Further, _spectral_helper and specgram already have a huge number of
> arguments.  This way I was able to get away with just adding one new
> argument rather than two.
>
Thanks for the feedback. I agree that your documentation does make clear
the distinction between "phase" and "angle" and that it has a
consistency. I just feel that this distinction does not exist "outside" ...

But beyond this question of phase vs. angle, I must say I don't see that
big a use case for phase/angle spectrums[*] (as opposed to magnitude
which are much used).  Also, in many cases, "spectrum" is synonymous
with spectral density, which implies "magnitude". In the end I wonder
whether the notion of phase even makes sense for a spectrogram ?

That's the reason why I'm a bit skeptical with the many new "mode
switches" in the spec helper, along with the new phase/angle_* functions.

best,
Pierre


[*] On the other hand I do see a usecase of magnitude and phase for
plotting transfer functions (i.e. Bode diagrams). Those are not fft
based plots, so it's a different topic I guess. Bode/Nyquist/Black
diagrams could be nice to have.

[matplotlib-devel] OS-X binaries?

[Chris B. - N. F. <chr...@no...>]

Are there recent binaries for OS-X anywhere? There don't seem to be
any for recent releases on the MPL download page.

I know we had a discussion about this a whole back, but don't remember
the outcome. But I hope we'll continue to put them up-- macports and
friends really aren't the best solutions for everyone.

Chris

Re: [matplotlib-devel] Pull request

[Pierre H. <pie...@cr...>]

Hi,

Le 22/10/2013 12:31, Todd a écrit :
> Currently, both axes.psd and axes.csd return the same thing as
> mlab.psd and mlab.csd, namely the spectrum and frequency points.  They
> do NOT return the line object that was plotted.  This is different
> than specgram, which returns the AxesImage object that was plotted in
> addition to the mlab.specgram return values.
>
> I think having access to the line object is important, so
> axes.magnitude_spectrum, axes.angle_spectrum, and axes.phase_spectrum
> do return the line object.  I know this is inconsistent, but I think
> it is very important and would strongly objefct to removing this.
>
> The question, then, is whether this would be a good opportunity to add
> the line object to the returned values for axes.psd and axes.csd. 
> This would be an API break, but would be very easy to fix, and it may
> be beneficial enough to warrant it.  What does everyone think?

I agree that it may be nice to have plt.psd/csd to return lines just
like plt.plot for increased consistency. I guess that returning the
values comes from Matlab style inspiration.

Maybe breaking the API is too strong. In that case, adding a
transitional keyword (for example `return_line=False`) to psd/csd may
help introduce your new proposed behavior in a softer manner. What do
you think ?

Of course, for your new functions, there is no API breakage problem.

best,
Pierre

[matplotlib-devel] weak behavior of the home button in figure() (version 1.3.1)

[lorenzo.digregorio <lor...@gm...>]

Hello,

I've noticed a behavior which is a bit annoying in the 'home' button of a
figure.
Employing 'sharex' I can share an axis of across two figures(), say figure 1
and figure 2.
If I zoom on figure 2, the axis gets correspondly changed in figure 1:
wonderful!
However, if I click the home button on figure 1 now, I cannot revert to the
original view.
I have to zoom once in figure 1 as well in order to make the home button
work as expected.

Best Regards,
Lorenzo



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/weak-behavior-of-the-home-button-in-figure-version-1-3-1-tp42353.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Re: [matplotlib-devel] Pull request

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

On Sun, Oct 20, 2013 at 9:45 AM, Todd <tod...@gm...> wrote:

> Hello,
>
> I submitted a pull request #2522 [1].  It includes support for more basic
> spectrum plots like magnitude and phase spectrums.  These are extremely
> commonly used in signal processing, acoustics, and many other fields, but
> are also very important for educational usage since pretty much anyone
> going through one of several engineering degrees like electrical
> engineering has to learn these types of plots.  I have heard a number of
> colleagues complaining about the lack of these plots in matlab.
>
> It has been up for 5 days, but I haven't received any comments on its
> content or structure.  I understand that it is a pretty substantial patch,
> but I think the features are very useful.
>
> I am also a bit concerned that patches covering the same code might be
> submitted and accepted while I am waiting for this, since such changes
> would be hard to merge into my branch.
>
> So does anyone have any thoughts on the patch?
>
> [1] https://github.com/matplotlib/matplotlib/pull/2522
>

I do have one question about my pull request.

Currently, both axes.psd and axes.csd return the same thing as mlab.psd and
mlab.csd, namely the spectrum and frequency points.  They do NOT return the
line object that was plotted.  This is different than specgram, which
returns the AxesImage object that was plotted in addition to the
mlab.specgram return values.

I think having access to the line object is important, so
axes.magnitude_spectrum, axes.angle_spectrum, and axes.phase_spectrum do
return the line object.  I know this is inconsistent, but I think it is
very important and would strongly objefct to removing this.

The question, then, is whether this would be a good opportunity to add the
line object to the returned values for axes.psd and axes.csd.  This would
be an API break, but would be very easy to fix, and it may be beneficial
enough to warrant it.  What does everyone think?

Re: [matplotlib-devel] Problem compiling master

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

On Tue, Oct 22, 2013 at 9:30 AM, Ian Thomas <ian...@gm...> wrote:

> On 22 October 2013 07:53, Todd <tod...@gm...> wrote:
>
>> As of last night, I can no longer compile master.  I get the following
>> error:
>>
>> building 'matplotlib.ttconv' extension
>> creating build/temp.linux-x86_64-2.7/extern/ttconv
>> gcc -pthread -fno-strict-aliasing -fmessage-length=0 -O2 -Wall
>> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
>> -fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall
>> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
>> -fasynchronous-unwind-tables -g -fPIC
>> -DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ttconv_ARRAY_API
>> -DPYCXX_ISO_CPP_LIB=1
>> -I/usr/lib64/python2.7/site-packages/numpy/core/include
>> -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.7 -c
>> src/_ttconv.cpp -o build/temp.linux-x86_64-2.7/src/_ttconv.o
>> src/_ttconv.cpp:12:27: fatal error: ttconv/pprdrv.h: No such file or
>> directory
>> compilation terminated.
>> error: command 'gcc' failed with exit status 1
>>
>> This happens even when building from a newly-cloned directory.  I am
>> building on Linux (openSUSE 12.3).  There shouldn't be ttconv/pprdrv.h, it
>> has been moved to extern/ttconv/pprdrv.h.  I can't figure out why it is
>> still looking there.
>>
>
> Todd,
>
> This is my fault, I would expect to see a '-Iextern' in the compilation
> options.  Usually this is obtained from CXX().add_flags(), but obviously
> not in your case which implies that your CXX is available via pkg-config.
>
> I think either of the following changes will fix the problem:
>
> 1) Either adding the following after line 947 in setupext.py:
>        ext.include_dirs.append('extern')
>
> 2) Or changing line 12 of src/_ttconv.cpp from
>     #include "ttconv/pprdrv.h"
> to
>     #include "extern/ttconv/pprdrv.h"
>
> I'll need to think about which is the better solution.  If you can let me
> know which of these fix the problem, I'll have a PR out later today.
>
> Ian
>
> Thanks, both seem to work.

Re: [matplotlib-devel] Problem compiling master

[Ian T. <ian...@gm...>]

On 22 October 2013 07:53, Todd <tod...@gm...> wrote:

> As of last night, I can no longer compile master.  I get the following
> error:
>
> building 'matplotlib.ttconv' extension
> creating build/temp.linux-x86_64-2.7/extern/ttconv
> gcc -pthread -fno-strict-aliasing -fmessage-length=0 -O2 -Wall
> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall
> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
> -fasynchronous-unwind-tables -g -fPIC
> -DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ttconv_ARRAY_API
> -DPYCXX_ISO_CPP_LIB=1
> -I/usr/lib64/python2.7/site-packages/numpy/core/include
> -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.7 -c
> src/_ttconv.cpp -o build/temp.linux-x86_64-2.7/src/_ttconv.o
> src/_ttconv.cpp:12:27: fatal error: ttconv/pprdrv.h: No such file or
> directory
> compilation terminated.
> error: command 'gcc' failed with exit status 1
>
> This happens even when building from a newly-cloned directory.  I am
> building on Linux (openSUSE 12.3).  There shouldn't be ttconv/pprdrv.h, it
> has been moved to extern/ttconv/pprdrv.h.  I can't figure out why it is
> still looking there.
>

Todd,

This is my fault, I would expect to see a '-Iextern' in the compilation
options.  Usually this is obtained from CXX().add_flags(), but obviously
not in your case which implies that your CXX is available via pkg-config.

I think either of the following changes will fix the problem:

1) Either adding the following after line 947 in setupext.py:
       ext.include_dirs.append('extern')

2) Or changing line 12 of src/_ttconv.cpp from
    #include "ttconv/pprdrv.h"
to
    #include "extern/ttconv/pprdrv.h"

I'll need to think about which is the better solution.  If you can let me
know which of these fix the problem, I'll have a PR out later today.

Ian

[matplotlib-devel] Problem compiling master

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

As of last night, I can no longer compile master.  I get the following
error:

building 'matplotlib.ttconv' extension
creating build/temp.linux-x86_64-2.7/extern/ttconv
gcc -pthread -fno-strict-aliasing -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables -g -fPIC
-DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ttconv_ARRAY_API
-DPYCXX_ISO_CPP_LIB=1
-I/usr/lib64/python2.7/site-packages/numpy/core/include
-I/usr/local/include -I/usr/include -I. -I/usr/include/python2.7 -c
src/_ttconv.cpp -o build/temp.linux-x86_64-2.7/src/_ttconv.o
src/_ttconv.cpp:12:27: fatal error: ttconv/pprdrv.h: No such file or
directory
compilation terminated.
error: command 'gcc' failed with exit status 1

This happens even when building from a newly-cloned directory.  I am
building on Linux (openSUSE 12.3).  There shouldn't be ttconv/pprdrv.h, it
has been moved to extern/ttconv/pprdrv.h.  I can't figure out why it is
still looking there.

Re: [matplotlib-devel] ggplot for matplotlib

[Jason G. <jas...@cr...>]

On 10/21/13 12:11 PM, Michael Droettboom wrote:
> Yes -- I reached out to the author about exactly that this morning.  It
> would be great to closely collaborate on this.
>

Awesome.  I saw this on HackerNews a few days ago and got really excited 
about it.  So a big +1 from me.

Thanks,

Jason

Re: [matplotlib-devel] Directories for C/C++ extensions

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

On Mon, Oct 21, 2013 at 7:36 PM, Chris Barker <chr...@no...> wrote:

> > To expand slightly, with the current situation the onus is on us to
> ensure
> > that mpl builds OK and passes all of our tests with and without each of
> the
> > external libraries.
>
> If you only have internal libs, then there is less to do -- it only
> need to work with the version you bundle. And making sure it works
> with any-old-version-that-may-not-exist-yet is a pretty formidable
> challenge!
>

We have sonums for this very reason.  And this could apply just as well to
python itself.  There is a reason not many distros ship SAGE packages.


> > Linux distro packagers will choose to set up qhull as a
> > required dependency for their mpl package, and once they have done this
> can
> > simply delete our directory containing the qhull source code in their mpl
> > source package,
>
> If they are going to insist on doing this, then, yes you should
> certainly do it this way.
>

Yes, they are.  This is the whole point of having packages in the first
place, as opposed to something like windows where every program just
bundles everything..


> > we can all be confident that it will work correctly.
>
> only if you've  tested against the version (maybe patched) of the
> external lib they are using...
>

It is only matplotlib's responsibility to test against the unpatched
versions specified, just like it is only matplotlib's responsibility to
test against the unpatched python versions specified.  Doing this isn't a
particularly difficult task, there are easily tens of thousands of apps
that have no problem with this.


> > If we always used our internal version then distro packagers would have
> to
> > change our setup scripts to build using the external libraries.  This
> would
> > be more time-consuming and error prone leading to less timely mpl distro
> > releases.  We need to make their job as easy as possible.
>
> it's easiest for them if they don't try to pull out an included
> dependency -- but maybe you're right that that REALLY want to do that!
>

It would be easiest if matplotlib detected whether the library is present
at build-time.  That is what most packages do.


> >The needs of the distro packagers, which are primarily security and
> > stability, are sometimes at odds with the needs of scientific software,
> > where the premium is on reproducibility.  The output of matplotlib
> depends
> > on the versions of some of its dependencies, not the version of
> matplotlib
> > alone, and that's problematic for some...
>
> exactly -- if we know exactly which version of a lib is in use, we
> know that it works the way we expect in the use cases we expect to use
> it in.
>
> But I'm not maintaining this code, so have at it in the way that makes
> sense to you.
>
> NOTE: it would be a different story if this were a netwroking protocol
> lib, or something where security patches would be critical. Maybe I'm
> naive, but this doesn't seem likely in this case.
>

You would be surprised what sort of packages can lead to security
vulnerabilities.

Re: [matplotlib-devel] Directories for C/C++ extensions

[Ian T. <ian...@gm...>]

On 21 October 2013 18:36, Chris Barker <chr...@no...> wrote:

> > we can all be confident that it will work correctly.
>
> only if you've  tested against the version (maybe patched) of the
> external lib they are using...
>

Of course not.  We provide the framework to build mpl and run tests.
Distro developers choose how they want to build it and then run our tests.
If the tests pass then both they and us are confident that it works
correctly.  We haven't had to test against anyone else's choice of library
version.

But I'm not maintaining this code, so have at it in the way that makes
> sense to you.
>

This is nothing to do with what makes sense to me; it is about following
the existing policy on C/C++ extensions when adding a new one.  Just
because I am taking time to answer your questions don't presume I am taking
a particular stance.  In fact I don't have a preference either way, I am
just doing the work that is required in a way that is consistent with
existing code.  If there is a change of policy I am happy to do it a
different way.

Ian