matplotlib-users Mailing List for matplotlib (Page 4)

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

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

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

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

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

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

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/

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

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

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.

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

 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

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'

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.

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.

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

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

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

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

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

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

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

My guess is that the hold mode is true (that's the default). I think 
this means that every time you call .pcolor that you are just appending 
another one to the axes. You should either change the default hold mode 
or call the .clear() method of the axes object before calling the 
.pcolor method. If you don't do that it is rendering n previous 
versions and the time it takes grows linearly.
Perry
On Mar 16, 2005, at 2:47 PM, Russell E. Owen wrote:
> I have appended some code which draws a varying pcolor plot in a 
> Tkinter
> window. The plot shows two 5x5 white rings which shrink to 3x3 and then
> 1x3, then cycles through this repeatedly.
>
> Unfortunately, it slows down with each cycle!!!
>
> Are we doing something wrong? Or can we work around the problem 
> somehow?
>
> (By the way, I did not write the code, though I cleaned up some 
> portions
> of it. I realize the data generation can be cleaned up, but it's not
> slowing things down).
>
> -- Russell
>
> 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.
>
> Also, is pcolor documented anywhere?
>
> ----- the code -----
>
> import Tkinter as Tk
> from matplotlib.pylab import *
> import matplotlib.numerix as num
> from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg,
> NavigationToolbar2TkAgg
>
> root = Tk.Tk()
> a =[ [0,1,2,3,4,5,6,\
> 90,91,92,93,94,95,96,15,30,45,\
> 60,75,21,36,51,66,81,\
> 8,9,10,11,12,13,14,98,99,\
> 100,101,102,103,104,\
> 23,38,53,68,83,29,44,59,74,89],\
> [16,17,18,19,20,76,77,78,79,80,35,50,65,\
> 31,46,61,24,25,26,27,28,\
> 84,85,86,87,88,39,54,69,43,58,73],\
> [32,33,34,62,63,64,47,49,40,41,42,\
> 70,71,72,55,57],\
> [48,56] ]
>
> ioff()
> f = figure(figsize=(3,3))
> sp = f.add_subplot(111)
> canvas = FigureCanvasTkAgg(f, master=root)
> canvas.get_tk_widget().pack(side=Tk.TOP, fill=Tk.BOTH, expand=1)
>
> def displayData(maxCount=20, delayTimeMS=20, count=0):
> fx = count % len(a)
> a[fx].sort()
> ra = []
> cnt = 0
> v = a[fx][cnt]
> for i in range(15*15):
> if i == v:
> ra.append(1)
> cnt += 1
> if cnt < len(a[fx]):
> v = a[fx][cnt]
>
> else:
> ra.append(0)
>
> z = num.reshape(ra, (15,15))
> sp.pcolor(transpose(z), cmap=cm.gray, norm=normalize())
> canvas.draw()
> count += 1
> if count < maxCount:
> root.after(delayTimeMS, displayData, maxCount, delayTimeMS,
> count)
>
> displayData(maxCount=100, delayTimeMS=20)
> root.mainloop()
>
>
>
> -------------------------------------------------------
> 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

John Hunter
<jdh...@ac...> writes:
> 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.
Thanks for the comments and example, John. I'll study it in detail
later.
For the moment I don't really want to do anything more advanced than
anim.py. The sleep() was only there to make the problem obviously
visible, but it was also present without it.
Longer term, I'd like to be able to pass in a 2d array of y values,
and get a window like the one show() presents, only with a "play"
button for animation plus a slider or similar to navigate to a
specific frame. I don't think this should be too hard, but I don't
know python yet so it may take some time.
The context is that I want to visualise time evolving partial
differential equations. (In general 3d complex-valued ones, but that's
a bit too much information to put in one plot.) So I have results from
the solver, for each time step, no real-time plotting or anything like
that.
Cheers, 
Joachim.

I have appended some code which draws a varying pcolor plot in a Tkinter 
window. The plot shows two 5x5 white rings which shrink to 3x3 and then 
1x3, then cycles through this repeatedly.
Unfortunately, it slows down with each cycle!!!
Are we doing something wrong? Or can we work around the problem somehow?
(By the way, I did not write the code, though I cleaned up some portions 
of it. I realize the data generation can be cleaned up, but it's not 
slowing things down).
-- Russell
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.
Also, is pcolor documented anywhere?
----- the code -----
import Tkinter as Tk
from matplotlib.pylab import *
import matplotlib.numerix as num
from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg, 
NavigationToolbar2TkAgg
root = Tk.Tk()
a =[ [0,1,2,3,4,5,6,\
90,91,92,93,94,95,96,15,30,45,\
60,75,21,36,51,66,81,\
8,9,10,11,12,13,14,98,99,\
100,101,102,103,104,\
23,38,53,68,83,29,44,59,74,89],\
[16,17,18,19,20,76,77,78,79,80,35,50,65,\
31,46,61,24,25,26,27,28,\
84,85,86,87,88,39,54,69,43,58,73],\
[32,33,34,62,63,64,47,49,40,41,42,\
70,71,72,55,57],\
[48,56] ]
ioff()
f = figure(figsize=(3,3))
sp = f.add_subplot(111)
canvas = FigureCanvasTkAgg(f, master=root)
canvas.get_tk_widget().pack(side=Tk.TOP, fill=Tk.BOTH, expand=1)
def displayData(maxCount=20, delayTimeMS=20, count=0):
 fx = count % len(a)
 a[fx].sort()
 ra = []
 cnt = 0
 v = a[fx][cnt]
 for i in range(15*15):
 if i == v:
 ra.append(1)
 cnt += 1
 if cnt < len(a[fx]):
 v = a[fx][cnt]
 else:
 ra.append(0)
 z = num.reshape(ra, (15,15))
 sp.pcolor(transpose(z), cmap=cm.gray, norm=normalize())
 canvas.draw()
 count += 1
 if count < maxCount:
 root.after(delayTimeMS, displayData, maxCount, delayTimeMS, 
count)
displayData(maxCount=100, delayTimeMS=20)
root.mainloop()