matplotlib-users — Discussion related to using matplotlib

Re: [Matplotlib-users] Re: slowdown when using pcolor and TkAgg; help?

[John H. <jdh...@ac...>]

>>>>> "Russell" == Russell E Owen <ro...@ce...> writes:

    Russell> Thanks. That was helpful -- though also a bit confusing,
    Russell> in that I'm using the TkAgg back end and calling
    Russell> pylab.draw() doesn't update anything visible on my
    Russell> FigureCanvasAgg object. (As an aside, calling show() on
    Russell> my FigureCanvasAgg object seems to work -- the code
    Russell> originally did that when I got it -- but the manual and
    Russell> FAQ clearly point to using draw instead).

I looked back over the code you posted previously and see that you are
using the API, eg making your own tk canvases.  In this case you
should not import pylab at all.  Do everything from the class API.
Call canvas.draw() rather than pylab.draw().

You can still use matplotlib.numerix to get all the Numeric/numarray
symbols, but the pylab interface doesn't mix well with the API
interface because pylab tries to manage figure creation and
destruction for you.

Instead of

  f = figure(figsize=(3,3))  # this is a pylab call
  sp = f.add_subplot(111)
  canvas = FigureCanvasTkAgg(f, master=root)

do 

from matplotlib.figure import Figure

  f = Figure(figsize=(3,3))  # this is an API call
  sp = f.add_subplot(111)
  canvas = FigureCanvasTkAgg(f, master=root)

See also examples/agg_oo.py and this post for a tutorial introduction
the matplotlib API

  http://sourceforge.net/mailarchive/message.php?msg_id=11033442

Hope this helps,
JDH

Re: [Matplotlib-users] How to get a figure's number?

[John H. <jdh...@ac...>]

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> Hi all, I wonder how I can get, in an easy way, the
    Fernando> number of a figure returned by a call to figure(None).
    Fernando> The nasty way is:

    Fernando>          allnums = [f.num for f in
    Fernando> _pylab_helpers.Gcf.get_all_fig_managers()] if allnums:
    Fernando> num = max(allnums) + 1 else: num = 1

    Fernando> but this seems horrible for everyday, user-level code.
    Fernando> What I want to do is simply be able to make a call to:

    Fernando> ff=figure()

    Fernando> and then later make a series of plots which go to that
    Fernando> figure:

    Fernando> myplotfunc(fignum=ff.num) myplotfunc2(fignum=ff.num) ...

What if we just attach the num attribute in the pylab figure function

    figManager.canvas.figure.num = num
    return figManager.canvas.figure

[Matplotlib-users] How to get a figure's number?

[Fernando P. <Fer...@co...>]

Hi all,

I wonder how I can get, in an easy way, the number of a figure returned by a 
call to figure(None).  The nasty way is:

         allnums = [f.num for f in _pylab_helpers.Gcf.get_all_fig_managers()]
         if allnums:
             num = max(allnums) + 1
         else:
             num = 1

but this seems horrible for everyday, user-level code.  What I want to do is 
simply be able to make a call to:

ff=figure()

and then later make a series of plots which go to that figure:

myplotfunc(fignum=ff.num)
myplotfunc2(fignum=ff.num)
...


I need to overlay a set of plots on the same figures, and I don't want to 
manage manually the figure numbering.  I'm comparing results across runs of a 
script, so the automatic figure(None) number increase is perfect.  But I need 
a way to get a hold of those numbers somehow, and I don't see how.  I looked 
at the attributes in the returned figure object, and I couldn't find the 
number anywhere (I think it's hidden higher up in the figure manager object).

An alternate (perhaps more 'pythonic'?) solution would be to allow figure() to 
take figure objects (not just numbers) as arguments.  In this case, it would 
simply be a matter of saying:

ff=figure()

and then later make a series of plots which go to that figure:

myplotfunc(fig=ff)
myplotfunc2(fig=ff)

At any rate, either an integer-based or an object-based solution would work 
for me, so I'll be grateful for any pointers.

best,

f

[Matplotlib-users] Re: slowdown when using pcolor and TkAgg; help?

[Russell E. O. <ro...@ce...>]

In article <m3r...@pe...>,
 John Hunter 
 <jdh...@ac...> wrote:

> >>>>> "Perry" == Perry Greenfield 
> >>>>> <pe...@st...> writes:
> 
>     Perry> My guess is that the hold mode is true (that's the
>     Perry> default). I think this means that every time you call
>     Perry> .pcolor that you are just appending another one to the
>     Perry> axes. You should either change the default hold mode or
>     Perry> call the .clear() method of the axes object before calling
>     Perry> the .pcolor method. If you don't do that it is rendering n
>     Perry> previous versions and the time it takes grows linearly.
> 
> Good catch Perry.  You need
> 
> sp.hold(False)

Thank you both very much. That did the trick. I put a hold on the figure 
and then a hold(False) on the one axis for which I wanted it and all 
works well now.

>     >> P.S. At risk of distracting from the main problem: I am not
>     >> entirely sure I'm commanding a redraw in the correct
>     >> fashion. I'm fuzzy on the difference between show and
>     >> plot. Using canvas.show() and canvas.plot() both seem to
>     >> work. Just calling plot() doesn't. Any hints on this or
>     >> pointers to documentation would be appreciated.
> 
> See  http://matplotlib.sourceforge.net/faq.html#SHOW

Thanks. That was helpful -- though also a bit confusing, in that I'm 
using the TkAgg back end and calling pylab.draw() doesn't update 
anything visible on my FigureCanvasAgg object. (As an aside, calling 
show() on my FigureCanvasAgg object seems to work -- the code originally 
did that when I got it -- but the manual and FAQ clearly point to using 
draw instead).

>     >> Also, is pcolor documented anywhere?
>...
> All the class docs can be found at
> http://matplotlib.sourceforge.net/classdocs.html.  In particular,

That's what I was really missing. Thanks! Now that I know about it, I'm 
not sure how I missed it the first time. Oh well...

-- Russell

Re: [Matplotlib-users] Re: Could not fire up pylab in Japanese Win XP (the font attached)

[John H. <jdh...@ac...>]

>>>>> "Natsu" == Natsu  <nat...@ya...> writes:

    Natsu> Hi, Thanks to MASUDA-san's advice, I could find the
    Natsu> problematic TTF font.

    Natsu> Please see attached font JRLM00M.TTF

OK, I can replicate the bug on windows and linux -- thanks for the
test file.  Even though I've found where the bug is occurring -- the
call to 

  setattr("family_name",     Py::String(face->family_name);

in ft2font.cpp, the fix is not immediately obvious, so we'll continue
to work on it and I'll keep you posted.  In the interim, hopefully you
can remove the troublesome files from your font path and still use
matplotlib.

JDH

[Matplotlib-users] sprint reminder

[John H. <jdh...@ac...>]

Just a reminder that there will be a matplotlib sprint on Monday the
21st before PyCon.  If you are in the DC area and what to hack on
matplotlib, please come out!

  http://www.python.org/moin/MatplotlibSprint

Hope to see you there!
JDH

Re: [Matplotlib-users] Re: Could not fire up pylab in Japanese Win XP

[John H. <jdh...@ac...>]

>>>>> "Yasushi" == Yasushi MASUDA <ym...@et...> writes:

    Yasushi> Hello, This problem seems to caused by (unhandled)
    Yasushi> ft2font.pyd crash for some kind of third-party TTF fonts.

I will try and send you a debug build today so you can identify where
the problem font is.  Also, if you send me a problem ttf font file and
I can replicate the problem on my system, I can probably diagnose it
and fix it myself, which would be more efficient.  Thanks for working
on this.

JDH

Re: [Matplotlib-users] Installation problem "cannot find -ltk" Suse 9.1

[Todd M. <jm...@st...>]

On Fri, 2005-03-18 at 05:02, Jason Hoogland wrote:
> Second question: I can't install Matplotlib and maybe someone will have seen 
> the symptom before or have some bright ideas to help me figure it out.  I'm 
> running SuSE 9.1, python 2.3.3, and seem to have Tcl/Tk/Tkinter installed OK.  

> I set BUILD_GTKAGG = 0 in setup.py.  In an xterm as root I ran this and the 
> output follows
> 
> \start
> 
> # python setup.py build
> Xlib: connection to ":0.0" refused by server
> Xlib: Invalid MIT-MAGIC-COOKIE-1 key
> Using default library and include directories for Tcl and Tk because a
> Tk window failed to open.  You may need to define DISPLAY for Tk to work
> so that setup can determine where your libraries are located.
> running build
> running build_py
> creating build
> creating build/lib.linux-i686-2.3
> copying lib/pylab.py -> build/lib.linux-i686-2.3
> creating build/lib.linux-i686-2.3/matplotlib
> copying lib/matplotlib/patches.py -> build/lib.linux-i686-2.3/matplotlib
> copying lib/matplotlib/_image.py -> build/lib.linux-i686-2.3/matplotlib
> 
> ... etc copying a bunch of files into the build directory

[mostly snipped]

> g++ -pthread -shared build/temp.linux-i686-2.3/src/_tkagg.o -L/usr/local/lib 
> -L/usr/local/lib -L/usr/local/lib -L/usr/lib -L/usr/local/lib -L/usr/lib -ltk 
> -ltcl -lpng -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o 
> build/lib.linux-i686-2.3/matplotlib/backends/_tkagg.so
> /linux1/usr/bin/../lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/ld: 
> cannot find -ltk
> collect2: ld returned 1 exit status
> error: command 'g++' failed with exit status 1
> 
> \end
> 
> I'm figuring the "Tk window open failed" bit at the start is just because it 
> seems to take a few seconds for Tk windows to appear on my system, and its 
> not coded to wait.  

That "Tk window open failed" problem looks to me like it may be *the*
problem.   matplotlib opens a Tk window to help figure out where Tk is; 
the fallback isn't working.  In your case I think the Tk window failed 
because "root" is trying to open a window on a display owned by your
non-priviledged account.   Having the system say "no" to root about
anything is really counter intuitive to me,  but I've experienced it
myself and it's discussed some here:

http://lists.debian.org/debian-user/1998/09/msg00113.html

The article suggests that if you do

% xhost +localhost

in your non-priviledged account before trying to build as root,  X will
allow the Tk window open.

> So assuming that's not fatal, it seems the problem boils 
> down to "cannot find -ltk".  I have searched for a few hours on google to no 
> avail.  The only things I can suspect are maybe:
> 
> - I might be missing some installed components for development stuff in Tcl or 
> g++?

Maybe.  On my RHEL3 system,  I have tk-devel-8.3.5-92.2 installed.

Hope this helps,
Todd

[Matplotlib-users] Installation problem "cannot find -ltk" Suse 9.1

[Jason H. <hoo...@me...>]

Hi,

I have two questions, I'll ask the simple one first.  I migrated from Matlab 
to Octave which uses gnuplot and thus provides 3D plotting capability, which 
is adequate.  Matplotlib is 2D, are there any good 3D plotters out there for 
python?

Second question: I can't install Matplotlib and maybe someone will have seen 
the symptom before or have some bright ideas to help me figure it out.  I'm 
running SuSE 9.1, python 2.3.3, and seem to have Tcl/Tk/Tkinter installed OK.  
For example:

#!/usr/bin/env python

from Tkinter import *
root = Tk()
w = Label(root, text="Hello, world!")
w.pack()
root.mainloop()

does the right thing by bringing up a window with the text.

$PYTHONHOME = /usr

I set BUILD_GTKAGG = 0 in setup.py.  In an xterm as root I ran this and the 
output follows

\start

# python setup.py build
Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Using default library and include directories for Tcl and Tk because a
Tk window failed to open.  You may need to define DISPLAY for Tk to work
so that setup can determine where your libraries are located.
running build
running build_py
creating build
creating build/lib.linux-i686-2.3
copying lib/pylab.py -> build/lib.linux-i686-2.3
creating build/lib.linux-i686-2.3/matplotlib
copying lib/matplotlib/patches.py -> build/lib.linux-i686-2.3/matplotlib
copying lib/matplotlib/_image.py -> build/lib.linux-i686-2.3/matplotlib

... etc copying a bunch of files into the build directory

copying lib/pytz/zoneinfo/Africa/Tripoli.py -> 
build/lib.linux-i686-2.3/pytz/zoneinfo/Africa
copying lib/pytz/zoneinfo/Africa/Banjul.py -> 
build/lib.linux-i686-2.3/pytz/zoneinfo/Africa
running build_ext
building 'matplotlib._nc_transforms' extension
creating build/temp.linux-i686-2.3
creating build/temp.linux-i686-2.3/src
creating build/temp.linux-i686-2.3/CXX
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c CXX/IndirectPythonInterface.cxx 
-o build/temp.linux-i686-2.3/CXX/IndirectPythonInterface.o -DNUMERIC=1
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c CXX/cxxsupport.cxx -o 
build/temp.linux-i686-2.3/CXX/cxxsupport.o -DNUMERIC=1
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c src/_nc_transforms.cpp -o 
build/temp.linux-i686-2.3/src/_nc_transforms.o -DNUMERIC=1
In file included from /usr/include/python2.3/Python.h:8,
                 from CXX/Objects.hxx:9,
                 from CXX/Extensions.hxx:18,
                 from src/_transforms.h:12,
                 from src/_nc_transforms.cpp:2:
/usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE" redefined
In file included from /usr/include/g++/i586-suse-linux/bits/os_defines.h:39,
                 from /usr/include/g++/i586-suse-linux/bits/c++config.h:35,
                 from /usr/include/g++/functional:53,
                 from src/_nc_transforms.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the previous 
definition
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c CXX/cxxextensions.c -o 
build/temp.linux-i686-2.3/CXX/cxxextensions.o -DNUMERIC=1
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c src/mplutils.cpp -o 
build/temp.linux-i686-2.3/src/mplutils.o -DNUMERIC=1
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -Isrc -I. -I/usr/include/python2.3 -c CXX/cxx_extensions.cxx -o 
build/temp.linux-i686-2.3/CXX/cxx_extensions.o -DNUMERIC=1
g++ -pthread -shared build/temp.linux-i686-2.3/src/_nc_transforms.o 
build/temp.linux-i686-2.3/src/mplutils.o 
build/temp.linux-i686-2.3/CXX/cxx_extensions.o 
build/temp.linux-i686-2.3/CXX/cxxsupport.o 
build/temp.linux-i686-2.3/CXX/IndirectPythonInterface.o 
build/temp.linux-i686-2.3/CXX/cxxextensions.o -lstdc++ -lm -o 
build/lib.linux-i686-2.3/matplotlib/_nc_transforms.so
building 'matplotlib.backends._tkagg' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64 
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -Wall 
-fPIC -I/usr/local/include -I/usr/local/include -I/usr/local/include 
-I/usr/include -Isrc -Iagg22/include -I. -I/usr/local/include -I/usr/include 
-I/usr/local/include/freetype2 -I/usr/local/include/freetype2 
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -Isrc/freetype2 
-Iagg22/include/freetype2 -I./freetype2 -I/usr/local/include/freetype2 
-I/usr/include/freetype2 -I/usr/include/python2.3 -c src/_tkagg.cpp -o 
build/temp.linux-i686-2.3/src/_tkagg.o
g++ -pthread -shared build/temp.linux-i686-2.3/src/_tkagg.o -L/usr/local/lib 
-L/usr/local/lib -L/usr/local/lib -L/usr/lib -L/usr/local/lib -L/usr/lib -ltk 
-ltcl -lpng -lz -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o 
build/lib.linux-i686-2.3/matplotlib/backends/_tkagg.so
/linux1/usr/bin/../lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/ld: 
cannot find -ltk
collect2: ld returned 1 exit status
error: command 'g++' failed with exit status 1

\end

I'm figuring the "Tk window open failed" bit at the start is just because it 
seems to take a few seconds for Tk windows to appear on my system, and its 
not coded to wait.  So assuming that's not fatal, it seems the problem boils 
down to "cannot find -ltk".  I have searched for a few hours on google to no 
avail.  The only things I can suspect are maybe:

- I might be missing some installed components for development stuff in Tcl or 
g++?
- Maybe need to have some environment variables set (e.g. for Tk?)
- Have some sort of path mismatch where it's looking for something that is 
somewhere else?

I've compiled a few things successfully on this set up now and not come across 
this one, any thoughts appreciated.

Cheers
Jason

[Matplotlib-users] Re: Could not fire up pylab in Japanese Win XP

[Yasushi M. <ym...@et...>]

Hello,

This problem seems to caused by (unhandled) ft2font.pyd crash for some 
kind of third-party TTF fonts.

In font_manager.py, createFontDict:

try:
  font = ft2font.FT2Font(str(fpath))   # <---- HERE
except RuntimeError:
  verbose.report_error("Could not open font file %s"%fpath)
  continue

For any 'clean' Japanese WinXP box having only MS-bundled TTFfonts,
matplotlib 0.72.1 runs fine, but with some third-party fonts 
are problematic even though they seem to have no problem with other 
Windows applications. In my case, two Japanese fonts were wrong.
(I don't think this is Japanese-font specific problem, because I have 
many Japanese fonts in my C:/WINDOWS/Fonts directory.)

I'm now looking into ft2pyd sources to find exact cause, but it will 
take a while (I'm not expert in font handling). Instead, you may 
find fonts causing problem with following script:
---------------
import os
from matplotlib import rcParams
from matplotlib.ft2font import FT2Font
from matplotlib.font_manager import findSystemFonts

paths = [rcParams['datapath']]
if os.environ.has_key('TTFPATH'):
    ttfpath = os.environ['TTFPATH']
    if ttfpath.find(';') >= 0: #win32 style
        paths.extend(ttfpath.split(';'))
    else:
        paths.append(ttfpath)

ttffiles = findSystemFonts(paths) + findSystemFonts()

for fpath in ttffiles:
    print "probing %s" %(str(fpath))
    font = FT2Font(str(fpath))
print "all fine.'
-------------
This program will crash at the problematic font. Remove it from font 
directory and run again untill it says all fine.
After removing all problematic fonts, Your matplotlib will work.

Thanks.

2005-03-17 01:31, Natsu wrote:
> Hi,
>  After resolving the font_manager.py issue, I could fire up pylab on
>  Japanese Win 2K. However, on my Win XP Japanese PCs, there seems
>  some trouble remaining.
>  
>  The following result was obtained with Enthogut python 2.3.3 on XP
>  professional Version 2002 SP1, Japanese.
>  On other PC with XP SP2, Japanese, I got a similar error.
>  So I"m afraid it is repeatable to any Japanese Win XP.
>  
>  Maybe, my WinXPs are not fresh and clean.  What do you think?
>  I"m ready to test the special debugging build which was mentioned in the
>  list earlier, if the binaries are sent to me.
>  

---
Yasushi Masuda
http://www.cubelab.com/ymasuda/

Re: [Matplotlib-users] legend labelsep ignored

[John H. <jdh...@ac...>]

>>>>> "Scott" == Scott C Splinter <s.c...@la...> writes:

    Scott>          Hi, I am having a problem with legend recognizing
    Scott> the labelsep kwarg.  It recognizes and makes changes

Hey Scott,

This is a bug -- thanks for letting me know.  It will be fixed in the
next release, due out tomorrow, barring unexpected disasters.

JDH

Re: [Matplotlib-users] autoscale problem?

[John P. <jo...@ot...>]

Darren,

This works great for me - thanks!

I should have said this earlier, but matplotlib is excellent! Thank you 
to everyone who works on it.

John

Darren Dale wrote:

>On Wednesday 16 March 2005 07:59 pm, Darren Dale wrote:
>  
>
>>I suggest making the following change to ticker.py, starting
>>at line 501 in version 0.72.1:
>>
>>    def le(self, x):
>>        'return the largest multiple of base <= x'
>>        d,m = divmod(x, self._base)
>>        if closeto(m/self._base,1): # was closeto(m, self._base)
>>            #looks like floating point error
>>            return (d+1)*self._base
>>        else:
>>            return d*self._base
>>
>>    
>>
>
>I was testing this bugfix with plot([1.4e-12,3.0e-12]), and noticed that the 
>1.4e-12 ticklabel was being dropped.
>
>In ticker.py, I suggest replacing Base.ge with:
>
>    def ge(self, x):
>        'return the largest multiple of base >= x'
>        d,m = divmod(x, self._base)
>        if closeto(m,0) and not closeto(m/self._base,1): return x
>        return (d+1)*self._base
>
>The fourth line used to be if m==0: return x, which fails sometimes due to 
>floating point inaccuracy. John, remember I was complaining about how certain 
>ticklabels wouldnt get rendered in the new scalarformatter I posted a couple 
>weeks ago? This was the problem.
>
>Darren
>
>  
>

Re: [Matplotlib-users] polyfit implementation

[Jean-Michel P. <jea...@ar...>]

Hello Andrea,

and...@ti... a écrit :
> That does not depend on Numeric, numarray or Matlab. Is your data. If you
> try, in Matlab, to see how polyfit works (type polyfit), you will see with
> a simple trial that your data are bad conditioned. As an example, if x,
> y are the 2 rows of your data:
> 
> In fact, try to take a look at the condition number of your matrix R:
> 
> condest(R)
> 
> ans =
> 
>      3.89823249817041e+025
> 
> That's too high. Neither Matlab, Python or whatever software will give you
> a result on which you can rely. Maybe at a first glance Matlab seems to
> be more powerful (and, in general, this is the case), but be aware that
> you should not trust on results that are affected by so bad conditioning
> number/numerical errors.
> Try to reduce the number of points (some of them are too close), or try
> a non-linear regression (as lsqnonlin), even if you should not need such
> a tool in order to do the job.

I totally agree to the fact that my problem is highly badly conditioned. 
But as this may not always be the case, I would have preferred polyfit 
to give reliable results without having to track the condition number. 
Do you know how to get it from within Python?

Indeed I do not use the fitted polynomials directly but their
derivatives. Doing so, fitting errors are increased and I noticed that
Matlab keeps providing reliable results for the few input data I tested.
This is not the case with Numeric or numarray.


JM.

Re: [Matplotlib-users] Exception when importing matplotlib in linux

[Darren D. <dd...@co...>]

On Thursday 17 March 2005 10:05 am, Vinj Vinj wrote:
> I'm getting the followign exception on fedora core3.
> Any suggestions. This code works on windows:
>
>     from matplotlib.matlab import *
>   File
> "/usr/lib/python2.3/site-packages/matplotlib/matlab.py",
> line 12, in ?
>     from matplotlib.pylab import *
>   File
> "/usr/lib/python2.3/site-packages/matplotlib/pylab.py",
> line 722, in ?
>     figimage.__doc__ = Figure.figimage.__doc__ + """
>  TypeError: unsupported operand type(s) for +:
> 'NoneType' and 'str'

Hi Vinj,

What version of MPL are you using? Have you tried to remove your 
site-packages/matplotlib directory, and install from a fresh tarball (or are 
you using rpm)?

By the way, "from matplotlib.matlab import" statements are deprecated. You 
should start using "fom matplotlib.pylab import ..." or simply "from pylab 
import ..." 

Darren

[Matplotlib-users] legend labelsep ignored

[Scott C. S. <s.c...@la...>]

         Hi,

         I am having a problem with legend recognizing the labelsep 
kwarg.  It recognizes and makes changes according to the other kwargs (i.e. 
handlelen, handletextsep, axespad, pad, etc.), but when I adjust the number 
for labelsep, nothing happens.  The default is 0.005 and I have tried 
numbers between 100000 and 0.0000001 with no change.  I am currently using 
Python 2.3.5, TK version 8.4 and running my scripts in IDLE 1.0.5 with the 
GTKAgg backend.  The problem I want to fix is to put more space between my 
legend labels so that when I print out the figure in a report, the labels 
don't overlap each other.  The actual legend command I am using is shown 
below.  Appreciate the help.

legend(('TC1','TC2','TC3',TC4','TC5','TC6'),loc=4,labelsep=0.05)

         Scott

[Matplotlib-users] Exception when importing matplotlib in linux

[Vinj V. <vin...@ya...>]

I'm getting the followign exception on fedora core3.
Any suggestions. This code works on windows:

    from matplotlib.matlab import *
  File
"/usr/lib/python2.3/site-packages/matplotlib/matlab.py",
line 12, in ?
    from matplotlib.pylab import *
  File
"/usr/lib/python2.3/site-packages/matplotlib/pylab.py",
line 722, in ?
    figimage.__doc__ = Figure.figimage.__doc__ + """
 TypeError: unsupported operand type(s) for +:
'NoneType' and 'str'

Re: [Matplotlib-users] Re: Parts of plot lagging from previous frame in animation

[Joachim B. H. <c.j...@fy...>]

John Hunter wrote:
>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> John, I've been caught out a few times with this too! I
>     Steve> think we should change it so -d<nonexistentbackend> raises
>     Steve> an error, what do you think?
> 
> I'm inclined to leave it as is though, and deal with it as a annoying
> problem.  Users who are passing -dBackend flags are probably
> sophisticated enough to survive this annoyance.  But if you have a
> clean solution, I'm open to it.

Deprecate -d<backend> and introduce --mpl.backend=<backend>? Perhaps 
extend to allow overriding all .matplotlibrc directives, so you can do 
--mpl.verbose.level=debug and so on?

I think that would be clean, and if you like the idea I can create a 
patch for it. But I saw -d mentioned as matlab compatible, so if that is 
important then maybe not.

-j.

PS. my excuses for not preserving CCs earlier.

Re: [Matplotlib-users] polyfit implementation

[Jean-Michel P. <jea...@ar...>]

Hello Andrea,

and...@ti... a écrit :
> That does not depend on Numeric, numarray or Matlab. Is your data. If you
> try, in Matlab, to see how polyfit works (type polyfit), you will see with
> a simple trial that your data are bad conditioned. As an example, if x,
> y are the 2 rows of your data:
> 
> In fact, try to take a look at the condition number of your matrix R:
> 
> condest(R)
> 
> ans =
> 
>      3.89823249817041e+025
> 
> That's too high. Neither Matlab, Python or whatever software will give you
> a result on which you can rely. Maybe at a first glance Matlab seems to
> be more powerful (and, in general, this is the case), but be aware that
> you should not trust on results that are affected by so bad conditioning
> number/numerical errors.
> Try to reduce the number of points (some of them are too close), or try
> a non-linear regression (as lsqnonlin), even if you should not need such
> a tool in order to do the job.

I totally agree to the fact that my problem is highly bad conditionned. 
But as this may not always be the case and I would have preferred 
polyfit to give reliable results without having to track the condition 
number. Do you know how to get it from within Python?

Indeed I do not use the fitted polynomials directly but their 
derivatives. Doing so, fitting errors are increased and I notice that 
Matlab keeps providing reliable results for the few input data I tested. 
This is not the case with Numeric or numarray.


JM.

Re: [Matplotlib-users] Re: Parts of plot lagging from previous frame in animation

[John H. <jdh...@ac...>]

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> John, I've been caught out a few times with this too! I
    Steve> think we should change it so -d<nonexistentbackend> raises
    Steve> an error, what do you think?

I've been caught many times too.  We used t raise on nonexistant
backend strings, but we were rightly yelled at because mpl is a
library, and users often want to pass other -d flags to their
programs, eg -debug.  So now it fails silently, which is bad, but may
be better than the alternative of blocking all other -d flags.

One possible solution is to warn, but allow the user to turn off the
warning with an rc param.

I'm inclined to leave it as is though, and deal with it as a annoying
problem.  Users who are passing -dBackend flags are probably
sophisticated enough to survive this annoyance.  But if you have a
clean solution, I'm open to it.

JDH

[Matplotlib-users] Re: Parts of plot lagging from previous frame in animation

[Steve C. <ste...@ya...>]

On Wed, 2005-03-16 at 16:59 -0800, matplotlib-users-
re...@li... wrote:
> > Joachim B Haga <cj...@st...> 
> > writes:
> > 
> > >> You may have something there. I tested different backends:
> > >>                                                       
> > >> These show the problem:           While these work fine:
> > >> 
> > >>   GtkAgg                            WX                  
> > >>   QtAgg                             WXAgg               
> > >>   CairoAgg                          GTK                 
> > >>   GtkCairo (yes, really)            TkAgg               
> > 
> > Forget this list. I just discovered that -d<nonexistentbackend> 
> > silently defaults to GtkAgg, at least on my install (debian). So the
> > "problem" list probably boils down to GtkAgg. Maybe you knew that.

John, I've been caught out a few times with this too! I think we should
change it so -d<nonexistentbackend> raises an error, what do you think?

> > Steve Chaplin <ste...@ya...> writes:
> > > I've just fixed it in CVS, it should appear in the next matplotlib
> > > version. Or try installing from CVS if you need the fix now, and would
> > > like to test it.
> > 
> > Excellent! I'll wait; or, if you want me to test, tell me which file and
> > version it is so I can patch my install with the relevant changes.

Its the file lib/matplotlib/backends/backend_gtkagg.py version 1.10,
it may also need lib/matplotlib/backends/backend_gtk.py version 1.80
Steve

[Matplotlib-users] Re: Parts of plot lagging from previous frame in animation

[Steve C. <ste...@ya...>]

On Wed, 2005-03-16 at 09:00 -0600, John Hunter wrote:
> I looked at this briefly and am a little confused by something.  The
> base class FigureCanvasGTK.expose_event has this in the doc string
> 
>         """Expose_event for all GTK backends
>         Should not be overridden.
> 
> but then the derived class 
> 
>   class FigureCanvasGTKAgg(FigureCanvasGTK, FigureCanvasAgg):
> 
> does in fact override it.
A while ago I started updating the GTK backends to be more consistent
(by using the same draw(), expose_event() etc methods) and also so they
create just one Renderer instance and reuse it for all drawing. I
completed doing this for GTK and GTKCairo. With GTKAgg, it looked a bit
more complicated, and seeing that GTKAgg was already working quite well
I decided to leave it and come back to it later.
So my intention was to have all GTK backends using a standard draw() and
expose_event() from the base class and just have a specific
_renderer_init() to set their own renderer. To make this work by reusing
one Renderer instance I needed to add new methods to each Renderer:
    def _set_pixmap(self, pixmap):
    def _set_width_height(self, width, height):
which are called by _render_figure().

I still think this approach is a good idea, but it may need to be
modified to allow it to work with GTKAgg.
The patch I committed to CVS does the first part (using standard draw()
and expose()), but not the second part - GTKAgg still uses multiple
Renderer instances.

The patch also fixes another little problem that GTKAgg has. If you
display a figure, then obscure the window and expose the window (without
resizing it), GTKAgg will completely redraw the window, which may give a
flicker in the obscured/exposed area for a complicated figure, whereas
GTK and GTKCairo will redraw the original figure from the double-
buffered memory, which is much faster and flicker-free.

> I inserted a debug print statement into
> FigureCanvasGTKAgg.expose_event and it is not called until the loop is
> over.  I think this is because the call to sleep is preventing the
> idle handler from ever getting engaged.
I think Joachim just used the sleep call just to make the problem
obvious, and that the problem is there even if sleep is not called,
except that it may flash so quickly you can not be sure what you saw.

> Perhaps Joachim would be better off using a gtk timer to handle his
> animation.  Basically, matplotlib tries to provide a GUI neutral way
> to do animation (eg anim.py) but if you want to do something
> semi-sophisticated like alter the timing between draws, you should use
> the GUI specific functionality for this, eg gtk timers.
> 
> Here is an example
> [...]
Thats works OK, but requires that users write their own animation draw()
routines, whereas using double-buffering for GTKAgg makes it available
to all GTKAgg users for free. I think double-buffering is generally what
you want to use for flicker-free drawing, and there does not seem to be
any performance penalty from the few tests I made.

Steve

Re: [Matplotlib-users] autoscale problem?

[Darren D. <dd...@co...>]

On Wednesday 16 March 2005 07:59 pm, Darren Dale wrote:
> I suggest making the following change to ticker.py, starting
> at line 501 in version 0.72.1:
>
>     def le(self, x):
>         'return the largest multiple of base <= x'
>         d,m = divmod(x, self._base)
>         if closeto(m/self._base,1): # was closeto(m, self._base)
>             #looks like floating point error
>             return (d+1)*self._base
>         else:
>             return d*self._base
>

I was testing this bugfix with plot([1.4e-12,3.0e-12]), and noticed that the 
1.4e-12 ticklabel was being dropped.

In ticker.py, I suggest replacing Base.ge with:

    def ge(self, x):
        'return the largest multiple of base >= x'
        d,m = divmod(x, self._base)
        if closeto(m,0) and not closeto(m/self._base,1): return x
        return (d+1)*self._base

The fourth line used to be if m==0: return x, which fails sometimes due to 
floating point inaccuracy. John, remember I was complaining about how certain 
ticklabels wouldnt get rendered in the new scalarformatter I posted a couple 
weeks ago? This was the problem.

Darren

Re: [Matplotlib-users] autoscale problem?

[Darren D. <dd...@co...>]

Hi John,

It is a bug. I suggest making the following change to ticker.py, starting at 
line 501 in version 0.72.1:

    def le(self, x):
        'return the largest multiple of base <= x'
        d,m = divmod(x, self._base)
        if closeto(m/self._base,1): # was closeto(m, self._base)
            #looks like floating point error
            return (d+1)*self._base
        else:
            return d*self._base

Darren



On Wednesday 16 March 2005 06:26 pm, John Pyle wrote:
> Hello,
>
> When I run:
>
> from pylab import *
> data = [1.6e-012, 3.0e-012]
> plot(data)
>
> the y axis autoscales to 1.8e-12 - 3.2e-12. I get the same behavior when
> I run in interactive mode or save the figure to png.
>
> Does anyone know if this is a bug or if there's something I can do to
> make the autoscaling work out?
>
> Thanks,
> John
>
>
> P.S. Here's the output from the --verbose-helpful flag:
>
> matplotlib data path c:\pyle\python23\share\matplotlib
> loaded rc file c:\pyle\python23\share\matplotlib\.matplotlibrc
> matplotlib version 0.72.1
> verbose.level helpful
> interactive is False
> platform is win32
> numerix numarray 1.2.2
> font search path ['c:\\pyle\\python23\\share\\matplotlib']
> loaded ttfcache file C:/msys/1.0/home/artsys\.ttffont.cache
> backend Agg version v2.2
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

-- 

Darren

[Matplotlib-users] autoscale problem?

[John P. <jo...@ot...>]

Hello,

When I run:

from pylab import *
data = [1.6e-012, 3.0e-012]
plot(data)

the y axis autoscales to 1.8e-12 - 3.2e-12. I get the same behavior when 
I run in interactive mode or save the figure to png.

Does anyone know if this is a bug or if there's something I can do to 
make the autoscaling work out?

Thanks,
John


P.S. Here's the output from the --verbose-helpful flag:

matplotlib data path c:\pyle\python23\share\matplotlib
loaded rc file c:\pyle\python23\share\matplotlib\.matplotlibrc
matplotlib version 0.72.1
verbose.level helpful
interactive is False
platform is win32
numerix numarray 1.2.2
font search path ['c:\\pyle\\python23\\share\\matplotlib']
loaded ttfcache file C:/msys/1.0/home/artsys\.ttffont.cache
backend Agg version v2.2

Re: [Matplotlib-users] slowdown when using pcolor and TkAgg; help?

[John H. <jdh...@ac...>]

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> My guess is that the hold mode is true (that's the
    Perry> default). I think this means that every time you call
    Perry> .pcolor that you are just appending another one to the
    Perry> axes. You should either change the default hold mode or
    Perry> call the .clear() method of the axes object before calling
    Perry> the .pcolor method. If you don't do that it is rendering n
    Perry> previous versions and the time it takes grows linearly.

Good catch Perry.  You need

sp.hold(False)

    >> P.S. At risk of distracting from the main problem: I am not
    >> entirely sure I'm commanding a redraw in the correct
    >> fashion. I'm fuzzy on the difference between show and
    >> plot. Using canvas.show() and canvas.plot() both seem to
    >> work. Just calling plot() doesn't. Any hints on this or
    >> pointers to documentation would be appreciated.


Se  http://matplotlib.sourceforge.net/faq.html#SHOW


    >> Also, is pcolor documented anywhere?

From the python shell

  In [1]: fig = figure()
  In [2]: sp = fig.add_subplot(111)
  In [3]: help(sp.pcolor)

All the class docs can be found at
http://matplotlib.sourceforge.net/classdocs.html.  In particular,
http://matplotlib.sourceforge.net/matplotlib.axes.html#Axes-pcolor

    >> ----- the code -----

Your code was improperly line wrapped and hence I had to edit it to
test it.  Please check that when you paste code in, it does not
improperly wrap.

Hope this helps,
JDH