matplotlib-users Mailing List for matplotlib (Page 4)

I made an error building matplotlib-0.54 for numarray and windows so the
version currently on source forge won't work with numarray-0.9 or
earlier; it only works with the head of numarray CVS. Hopefully a new
version will be up on Source Forge soon. In the meantime, don't waste
your time trying the numarray version of matplotlib-0.54 on Windows
unless you're already working with numarray CVS.
Regards,
Todd Miller

On Fri, 2004年05月21日 at 10:38, John Hunter wrote:
> >>>>> "Andrew" == Andrew Straw <str...@as...> writes:
> 
> Andrew> matplotlib 0.54 numarray 0.9 python 2.2.1 windows XP
> 
> Andrew> if I use WXAgg or Agg, I get this:
> 
> Hmm, this is an I-can't-replicate-your-bugs-day.
I'm sorry I'm just catching up with this now. I made an error building
matplotlib-0.54 for numarray on windows and the original version I sent
John basically doesn't work with numarray-0.9, just numarray-CVS. The
nature of the error is that function calls from C extensions to numarray
are totally mismatched so all bets are off as to what extensions
actually wind up doing.
Sorry for the inconvenience,
Todd Miller
> Using numarray 0.8 or 0.9 with matplotlib on linux, setting numerix :
> numarray in my rc file, I have no troubles with your script on any of
> a variety of backends. 
> 
> Apparently the data coming from the numerix transform is complex. The
> line that is failing for you is a tickline (as indicated by your
> traceback). These lines are small so it would be interesting to see
> by printing them if they are complex before of after being handed off
> to the transformation. In site-packages/matplotlib/lines.py on line
> 180, replace
> 
> xt, yt = self._transform.numerix_x_y(x, y)
> 
> with
> print 'before', x, y
> xt, yt = self._transform.numerix_x_y(x, y)
> print 'after', xt, yt
> 
> and let me know what happens. If they are complex before then it
> appears complex data is being passed in; in this case try printing x,y
> in your script
> 
> x = a*cos( theta )*exp(b*theta)
> y = a*sin( theta )*exp(b*theta)
> print 'x', x
> print 'y', y
> 
> to see if you can find where these complexes are coming from.
> 
> Thanks,
> JDH
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Todd Miller <jm...@st...>

Hello,
> You are apparently working on a platform 'osf1V5' that we haven't
> encountered before. What platform is this?
It's a sun (alpha processor) with a proprietary unix (OSF1 version 5, i 
think it's tru64).
> Also, you may want to install pygtk or Tkinter or wxpython if you want
> to use matplotlib from a GUI.
If i don't do a mistake, i have Tkinter
Well, after the modification of base.dir the building start and fail 
with this error message (sorry for the length but i don't know which 
part is interesting)
 creating build/temp.osf1-V5.1-alpha-2.3/agg2/src
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -I/usr/include -I/usr/local/include 
-I/home2/menut/prg/include -I/home2/menut/GNU/include -Isrc 
-Iagg2/include -I/usr/include -I/usr/local/include 
-I/home2/menut/prg/include -I/home2/menut/GNU/include 
-I/usr/include/freetype2 -I/usr/local/include/freetype2 
-I/home2/menut/prg/include/freetype2 
-I/home2/menut/GNU/include/freetype2 -Isrc/freetype2 
-Iagg2/include/freetype2 -I/usr/include/freetype2 
-I/usr/local/include/freetype2 -I/home2/menut/prg/include/freetype2 
-I/home2/menut/GNU/include/freetype2 
-I/home2/menut/prg/python2.3/include/python2.3 -c 
agg2/src/agg_arrowhead.cpp -o 
build/temp.osf1-V5.1-alpha-2.3/agg2/src/agg_arrowhead.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -I/usr/include -I/usr/local/include 
-I/home2/menut/prg/include -I/home2/menut/GNU/include -Isrc 
-Iagg2/include -I/usr/include -I/usr/local/include 
-I/home2/menut/prg/include -I/home2/menut/GNU/include 
-I/usr/include/freetype2 -I/usr/local/include/freetype2 
-I/home2/menut/prg/include/freetype2 
-I/home2/menut/GNU/include/freetype2 -Isrc/freetype2 
-Iagg2/include/freetype2 -I/usr/include/freetype2 
-I/usr/local/include/freetype2 -I/home2/menut/prg/include/freetype2 
-I/home2/menut/GNU/include/freetype2 
-I/home2/menut/prg/python2.3/include/python2.3 -c 
agg2/src/agg_trans_warp_magnifier.cpp -o 
build/temp.osf1-V5.1-alpha-2.3/agg2/src/agg_trans_warp_magnifier.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -I/usr/include -I/usr/local/include 
-I/home2/menut/prg/include -I/home2/menut/GNU/include -Isrc 
-Iagg2/include -I/usr/include -I/usr/local/include 
-I/home2/menut/prg/include -I/home2/menut/GNU/include 
-I/usr/include/freetype2 -I/usr/local/include/freetype2 
-I/home2/menut/prg/include/freetype2 
-I/home2/menut/GNU/include/freetype2 -Isrc/freetype2 
-Iagg2/include/freetype2 -I/usr/include/freetype2 
-I/usr/local/include/freetype2 -I/home2/menut/prg/include/freetype2 
-I/home2/menut/GNU/include/freetype2 
-I/home2/menut/prg/python2.3/include/python2.3 -c 
agg2/src/agg_scanline_u8.cpp -o 
build/temp.osf1-V5.1-alpha-2.3/agg2/src/agg_scanline_u8.o
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -I/usr/include -I/usr/local/include 
-I/home2/menut/prg/include -I/home2/menut/GNU/include -Isrc 
-Iagg2/include -I/usr/include -I/usr/local/include 
-I/home2/menut/prg/include -I/home2/menut/GNU/include 
-I/usr/include/freetype2 -I/usr/local/include/freetype2 
-I/home2/menut/prg/include/freetype2 
-I/home2/menut/GNU/include/freetype2 -Isrc/freetype2 
-Iagg2/include/freetype2 -I/usr/include/freetype2 
-I/usr/local/include/freetype2 -I/home2/menut/prg/include/freetype2 
-I/home2/menut/GNU/include/freetype2 
-I/home2/menut/prg/python2.3/include/python2.3 -c src/_backend_agg.cpp 
-o build/temp.osf1-V5.1-alpha-2.3/src/_backend_agg.o
In file included from 
/home2/menut/prg/python2.3/include/python2.3/Python.h:8,
 from src/ft2font.h:6,
 from src/_backend_agg.cpp:3:
/home2/menut/prg/python2.3/include/python2.3/pyconfig.h:840:1: warning: 
"_OSF_SOURCE" redefined
In file included from 
/usr/local/lib/gcc-lib/alphaev67-dec-osf5.1/3.3.3/include/string.h:61,
 from /usr/local/include/c++/3.3.3/cstring:51,
 from src/_backend_agg.cpp:1:
/usr/include/standards.h:206:1: warning: this is the location of the 
previous definition
In file included from 
/home2/menut/prg/python2.3/include/python2.3/Python.h:8,
 from src/ft2font.h:6,
 from src/_backend_agg.cpp:3:
/home2/menut/prg/python2.3/include/python2.3/pyconfig.h:847:1: warning: 
"_POSIX_C_SOURCE" redefined
In file included from 
/usr/local/lib/gcc-lib/alphaev67-dec-osf5.1/3.3.3/include/string.h:61,
 from /usr/local/include/c++/3.3.3/cstring:51,
 from src/_backend_agg.cpp:1:
/usr/include/standards.h:198:1: warning: this is the location of the 
previous definition
In file included from 
/home2/menut/prg/python2.3/include/python2.3/Python.h:8,
 from src/ft2font.h:6,
 from src/_backend_agg.cpp:3:
/home2/menut/prg/python2.3/include/python2.3/pyconfig.h:859:1: warning: 
"_XOPEN_SOURCE" redefined
In file included from 
/usr/local/lib/gcc-lib/alphaev67-dec-osf5.1/3.3.3/include/string.h:61,
 from /usr/local/include/c++/3.3.3/cstring:51,
 from src/_backend_agg.cpp:1:
/usr/include/standards.h:188:1: warning: this is the location of the 
previous definition
In file included from /usr/include/sys/resource.h:60,
 from 
/usr/local/lib/gcc-lib/alphaev67-dec-osf5.1/3.3.3/include/sys/wait.h:170,
 from 
/usr/local/lib/gcc-lib/alphaev67-dec-osf5.1/3.3.3/include/stdlib.h:192,
 from 
/home2/menut/prg/python2.3/include/python2.3/Python.h:36,
 from src/ft2font.h:6,
 from src/_backend_agg.cpp:3:
/usr/include/sys/time.h:71: error: 'suseconds_t' is used as a type, but 
is not
 defined as a type.
In file included from 
/home2/menut/prg/python2.3/include/python2.3/pyport.h:157,
 from 
/home2/menut/prg/python2.3/include/python2.3/Python.h:48,
 from src/ft2font.h:6,
 from src/_backend_agg.cpp:3:
/usr/local/lib/gcc-lib/alphaev67-dec-osf5.1/3.3.3/include/sys/stat.h:213: 
error: '
 blksize_t' is used as a type, but is not defined as a type.
/usr/local/lib/gcc-lib/alphaev67-dec-osf5.1/3.3.3/include/sys/stat.h:213: 
error: '
 blkcnt_t' is used as a type, but is not defined as a type.
In file included from src/_backend_agg.cpp:3:
src/ft2font.h:7:22: ft2build.h: No such file or directory
src/ft2font.h:8:10: #include expects "FILENAME" or <FILENAME>
src/ft2font.h:9:10: #include expects "FILENAME" or <FILENAME>
src/ft2font.h:10:10: #include expects "FILENAME" or <FILENAME>
In file included from src/_backend_agg.cpp:3:
src/ft2font.h:29: error: 'FT_Face' is used as a type, but is not defined 
as a
 type.
src/ft2font.h:31: error: 'FT_Matrix' is used as a type, but is not 
defined as a
 type.
src/ft2font.h:32: error: 'FT_Vector' is used as a type, but is not 
defined as a
 type.
src/ft2font.h:33: error: 'FT_Error' is used as a type, but is not 
defined as a
 type.
src/ft2font.h:34: error: parse error before `[' token
src/ft2font.h:35: error: parse error before `[' token
In file included from 
/usr/local/include/c++/3.3.3/bits/locale_facets.tcc:41,
 from /usr/local/include/c++/3.3.3/locale:47,
 from /usr/local/include/c++/3.3.3/bits/istream.tcc:37,
 from /usr/local/include/c++/3.3.3/istream:768,
 from /usr/local/include/c++/3.3.3/fstream:45,
 from src/_backend_agg.h:25,
 from src/_backend_agg.cpp:4:
/usr/local/include/c++/3.3.3/cmath: In function `long double std::acos(long
 double)':
/usr/local/include/c++/3.3.3/cmath:194: error: `::acosl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::asin(long
 double)':
/usr/local/include/c++/3.3.3/cmath:212: error: `::asinl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::atan(long
 double)':
/usr/local/include/c++/3.3.3/cmath:230: error: `::atanl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::atan2(long
 double, long double)':
/usr/local/include/c++/3.3.3/cmath:249: error: `::atan2l' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::ceil(long
 double)':
/usr/local/include/c++/3.3.3/cmath:268: error: `::ceill' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::cosh(long
 double)':
/usr/local/include/c++/3.3.3/cmath:296: error: `::coshl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::exp(long
 double)':
/usr/local/include/c++/3.3.3/cmath:314: error: `::expl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::floor(long
 double)':
/usr/local/include/c++/3.3.3/cmath:342: error: `::floorl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::fmod(long
 double, long double)':
/usr/local/include/c++/3.3.3/cmath:361: error: `::fmodl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::frexp(long
 double, int*)':
/usr/local/include/c++/3.3.3/cmath:380: error: `::frexpl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::ldexp(long
 double, int)':
/usr/local/include/c++/3.3.3/cmath:400: error: `::ldexpl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::log(long
 double)':
/usr/local/include/c++/3.3.3/cmath:419: error: `::logl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::log10(long
 double)':
/usr/local/include/c++/3.3.3/cmath:437: error: `::log10l' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::modf(long
 double, long double*)':
/usr/local/include/c++/3.3.3/cmath:461: error: `::modfl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::pow(long
 double, long double)':
/usr/local/include/c++/3.3.3/cmath:495: error: `::powl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::sinh(long
 double)':
/usr/local/include/c++/3.3.3/cmath:536: error: `::sinhl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::tan(long
 double)':
/usr/local/include/c++/3.3.3/cmath:564: error: `::tanl' undeclared 
(first use
 here)
/usr/local/include/c++/3.3.3/cmath: In function `long double std::tanh(long
 double)':
/usr/local/include/c++/3.3.3/cmath:582: error: `::tanhl' undeclared 
(first use
 here)
error: command 'gcc' failed with exit status 1
Jean-Luc

>>>>> "Jean-Luc" == Jean-Luc Menut <jea...@fr...> writes:
 Jean-Luc> GTKAgg requires pygtk GTKAgg requires pygtk Traceback
 Jean-Luc> (most recent call last): File "setup.py", line 88, in ?
 Jean-Luc> build_agg(ext_modules, packages) File
 Jean-Luc> "/home2/menut/prg/matplotlib-0.53.1/setupext.py", line
 Jean-Luc> 298, in build_agg add_agg_flags(module) File
 Jean-Luc> "/home2/menut/prg/matplotlib-0.53.1/setupext.py", line
 Jean-Luc> 83, in add_agg_flags add_base_flags(module) File
 Jean-Luc> "/home2/menut/prg/matplotlib-0.53.1/setupext.py", line
 Jean-Luc> 64, in add_base_flags incdirs = [os.path.join(p,
 Jean-Luc> 'include') for p in basedir[sys.platform] KeyError:
 Jean-Luc> 'osf1V5'
You are apparently working on a platform 'osf1V5' that we haven't
encountered before. What platform is this?
You need to add that platform as a key to the
basedir dictionary in setupext.py
basedir = {
 'win32' : ['win32_static',],
 'linux2' : ['/usr/local', '/usr',],
 'linux' : ['/usr/local', '/usr',],
 'darwin' : ['/usr/local', '/usr', '/sw'],
 'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
 'osf1V5' : ['/your/base/dir1', '/your/base/dir2'],
}
where /your/base/dir are the base paths to the system libraries.
Also, you may want to install pygtk or Tkinter or wxpython if you want
to use matplotlib from a GUI.
JDH

Hello,
I have a problem when i want to build matplotlib : i have this error 
message :
GTKAgg requires pygtk
GTKAgg requires pygtk
Traceback (most recent call last):
 File "setup.py", line 88, in ?
 build_agg(ext_modules, packages)
 File "/home2/menut/prg/matplotlib-0.53.1/setupext.py", line 298, in 
build_agg
 add_agg_flags(module)
 File "/home2/menut/prg/matplotlib-0.53.1/setupext.py", line 83, in 
add_agg_flags
 add_base_flags(module)
 File "/home2/menut/prg/matplotlib-0.53.1/setupext.py", line 64, in 
add_base_flags
 incdirs = [os.path.join(p, 'include') for p in basedir[sys.platform]
KeyError: 'osf1V5'
I use python 2.3.3 and Numeric 23.1 (and another packages)
Someone can help me ?
best regards,
Jean-Luc Menut

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> matplotlib 0.54 numarray 0.9 python 2.2.1 windows XP
 Andrew> if I use WXAgg or Agg, I get this:
Hmm, this is an I-can't-replicate-your-bugs-day.
Using numarray 0.8 or 0.9 with matplotlib on linux, setting numerix :
numarray in my rc file, I have no troubles with your script on any of
a variety of backends. 
Apparently the data coming from the numerix transform is complex. The
line that is failing for you is a tickline (as indicated by your
traceback). These lines are small so it would be interesting to see
by printing them if they are complex before of after being handed off
to the transformation. In site-packages/matplotlib/lines.py on line
180, replace
 xt, yt = self._transform.numerix_x_y(x, y)
with
 print 'before', x, y
 xt, yt = self._transform.numerix_x_y(x, y)
 print 'after', xt, yt
and let me know what happens. If they are complex before then it
appears complex data is being passed in; in this case try printing x,y
in your script
 x = a*cos( theta )*exp(b*theta)
 y = a*sin( theta )*exp(b*theta)
 print 'x', x
 print 'y', y
to see if you can find where these complexes are coming from.
Thanks,
JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> Hi all, I'd like use matplotlib to draw shapes on a
 Andrew> transparent background using the Agg backend to save .png
 Andrew> files. Is this possible?
 Andrew> I've tried
 Andrew> fig._figurePatch.set_alpha(0)
There is a vestigial limitation from the bad old days when we didn't
have an alpha channel. For polyons, there is no place holder for a
separate alpha channel for the edge and face. The way to do this
right is to simply replace all rgb instances throughout the library
with rgba, but this is a fair amount of work that touches the entire
library. What I am doing currently is sharing the alpha attribute
between edge and face for polygons.
So setting alpha=0 *should work. What backend and version are you
using? Rectangle calls gc.set_alpha before calling draw_polygon in
patches.Patch. In _backend_agg.RendererAgg.draw_polygon, the alpha
attribute for the face is taken from the edge which gets it from the
gc (around line 204 in _backend_agg). I say all this just because
from my read of the code *it should* work, and indeed, in my tests
 f = figure(1, facecolor='r')
 f._figurePatch.set_alpha(0.0)
does work for me using Agg and the latest matplotlib.
What backend and version are you using?
That said, the best way to do this is to add a frameon attribute for
figures, because this will be respected across backends including
those who don't understand alpha. This way you can say
f = figure(1, frameon=False)
I checked this into CVS.
JDH
 Andrew> This seems to get halfway, but there's still (opaque)
 Andrew> white drawn in the background.
 Andrew> Is there a "recommended way", and, if so, what is it?
 Andrew> Otherwise, can we improve matplotlib to allow drawing on
 Andrew> transparent backgrounds?
 Andrew> Cheers! Andrew
 Andrew> -------------------------------------------------------
 Andrew> This SF.Net email is sponsored by: Oracle 10g Get
 Andrew> certified on the hottest thing ever to hit the
 Andrew> market... Oracle 10g. Take an Oracle 10g class now, and
 Andrew> we'll give you the exam FREE.
 Andrew> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
 Andrew> _______________________________________________
 Andrew> Matplotlib-users mailing list
 Andrew> Mat...@li...
 Andrew> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

>>>>> "MWallis" == MWallis <mw...@sw...> writes:
 MWallis> I have 5 plots in one window that I am updating
 MWallis> dynamically and the GUI starts to freeze. Each of the
 MWallis> plots has its own timeout. Is there a better way of
 MWallis> doing this or can I put the plots on different threads?
 MWallis> Any suggestions would be appreciated.
Hi Melissa,
You may look into doing an idle_add instead of a timeout_add. The
former only draws when the processor is idle. Perhaps it is taking
you longer to draw than the frequency that you are calling the draw
functions with the timer, getting you into trouble.
Also, you had asked earlier about one canvas with many axes versus
many canvases embedded in GTK and my answer was it "it depends on
layout considerations". Now that I see better what you are trying to
do, I'd like to add that it will likely be more efficient to
dynamically update several axes on the same canvas than to separately
update many canvases.
def myfunc(*args):
 # update all the figures and draw
 return gtk.TRUE 
idle_add(c.idle_function)
JDH

when running the following simple script:
from matplotlib.matlab import *
from numarray import *
theta = arange(0.0,8*pi,0.1)
a=1
b=.2
dt = 0.0
x = a*cos( theta )*exp(b*theta)
y = a*sin( theta )*exp(b*theta)
plot(x,y)
show()
#savefig('ss')
with the following combination of software:
matplotlib 0.54
numarray 0.9
python 2.2.1
windows XP
if I use WXAgg or Agg, I get this:
Traceback (most recent call last):
 File "simple_spiral.py", line 13, in ?
 show()
 File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_wx.py", line 
1124, in show
 figwin.canvas.draw()
 File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_wxagg.py", 
line 50, in draw
 agg.draw()
 File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_agg.py", line 
299, in draw
 self.figure.draw(self.renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\figure.py", line 128, 
in draw
 for a in self.axes: a.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\axes.py", line 603, in draw
 self.xaxis.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 463, in draw
 tick.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 125, in draw
 if midPoint and self.tick1On: self.tick1line.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 193, in 
draw
 self._lineFunc(renderer, gc, xt, yt)
 File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 326, in 
_draw_solid
 renderer.draw_lines(gc, xt,yt)
TypeError: can't convert complex to float; use e.g. abs(z)
if I use PS, I get this:
Traceback (most recent call last):
 File "simple_spiral.py", line 14, in ?
 savefig('ss')
 File "C:\Python22\Lib\site-packages\matplotlib\matlab.py", line 1156, 
in savefig
 manager.canvas.print_figure(*args, **kwargs)
 File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 
378, in print_figure
 self.figure.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\figure.py", line 128, 
in draw
 for a in self.axes: a.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\axes.py", line 603, in draw
 self.xaxis.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 463, in draw
 tick.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\axis.py", line 125, in draw
 if midPoint and self.tick1On: self.tick1line.draw(renderer)
 File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 193, in 
draw
 self._lineFunc(renderer, gc, xt, yt)
 File "C:\Python22\Lib\site-packages\matplotlib\lines.py", line 326, in 
_draw_solid
 renderer.draw_lines(gc, xt,yt)
 File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 
103, in draw_lines
 ps.append('newpath %s moveto' % _nums_to_str((x[0], y[0])))
 File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 
36, in _nums_to_str
 return ' '.join([_int_or_float(val, fmt) for val in seq])
 File 
"C:\Python22\Lib\site-packages\matplotlib\backends\backend_ps.py", line 
41, in _int_or_float
 ival = int(val)
TypeError: can't convert complex to int; use e.g. int(abs(z))

Hi all,
I'd like use matplotlib to draw shapes on a transparent background using 
the Agg backend to save .png files. Is this possible?
I've tried
fig._figurePatch.set_alpha(0)
This seems to get halfway, but there's still (opaque) white drawn in the 
background.
Is there a "recommended way", and, if so, what is it? Otherwise, can we 
improve matplotlib to allow drawing on transparent backgrounds?
Cheers!
Andrew

>>>>> "MWallis" == MWallis <mw...@sw...> writes:
 MWallis> I am trying to dynamically update some figures that I
 MWallis> have embedded in GTK. The figures display fine and if I
 MWallis> minimize and then maximize the window the figures update
 MWallis> but I can't get the figures to update dynamically as you
 MWallis> watch the window. To try and get this working I used the
 MWallis> code from one of the dynamic samples and just embedded it
 MWallis> in my application.
Hi Melissa,
You were using kind of a hybrid of what I call the matlab interface
and the application interface, so I rewrote your example in the way I
would do it if I were embedding the dynamic demo in a GTK
application. The code is for the latest release (0.54) where some of
the API changed as discussed in the release notes, and would be
slightly different for earlier versions of matplotlib.
The major difference is that under the new API, you create axes and
subplots from a Figure instance with, for example,
 self.ax = self.figure.add_subplot(111)
Hope this helps,
John 
import pygtk
pygtk.require('2.0')
import gtk
import time
from matplotlib.backends.backend_gtkagg import FigureCanvasGTKAgg as FigureCanvas
from matplotlib.figure import Figure
from matplotlib.matlab import *
class C:
 def __init__(self):
 self.figure = Figure( figsize=(8,6), dpi=72)
 self.canvas = FigureCanvas(self.figure) # a gtk.DrawingArea
 self.ax = self.figure.add_subplot(111)
 self.win = gtk.Window()
 self.win.set_name("Embedding in GTK")
 self.win.connect("destroy", gtk.mainquit)
 self.win.set_border_width(5)
 self.win.add(self.canvas)
 def create_AntennaResponseDisplay (self, title):
 ind = arange(1,9)
 p1,p2,p3,p4,p5,p6,p7,p8 = self.ax.bar(ind, self.get_stats())
 centers = ind + 0.5*p1.get_width()
 p1.set_facecolor('b')
 p2.set_facecolor('b')
 p3.set_facecolor('b')
 p4.set_facecolor('b')
 p5.set_facecolor('b')
 p6.set_facecolor('b')
 p7.set_facecolor('b')
 p8.set_facecolor('b')
 self.ax.set_xlim([0.5,9])
 self.ax.set_xticks(centers)
 self.ax.set_ylim([0,100])
 self.ax.set_xticklabels(['1', '2', '3', '4', '5', '6', '7', '8'])
 t = self.figure.text(0.5, 0.95, title,
 horizontalalignment = 'center', fontsize = 10,)
 def updatefig(*args):
 e1, e2, e3, e4, e5, e6, e7, e8 = self.get_stats()
 p1.set_height(e1)
 p2.set_height(e2)
 p3.set_height(e3)
 p4.set_height(e4)
 p5.set_height(e5)
 p6.set_height(e6)
 p7.set_height(e7)
 p8.set_height(e8)
 self.ax.set_ylim([0,100])
 self.canvas.draw()
 return gtk.TRUE
 gtk.timeout_add(250, updatefig)
 self.canvas.show()
 self.win.show()
 gtk.mainloop()
 
 def get_memory(self):
 "Simulate a function that returns system memory"
 return 100*(0.5+0.5*sin(0.5*pi*time.time()))
 def get_cpu(self):
 "Simulate a function that returns cpu usage"
 return 100*(0.5+0.5*sin(0.2*pi*(time.time()-0.25)))
 def get_net(self):
 "Simulate a function that returns network bandwidth"
 return 100*(0.5+0.5*sin(0.7*pi*(time.time()-0.1)))
 def get_stats(self):
 return self.get_memory(), self.get_cpu(), self.get_net(), \
 self.get_memory(), self.get_cpu(), self.get_net(), \
 self.get_memory(), self.get_cpu()
c = C()
c.create_AntennaResponseDisplay('Test!')

What's new in matplotlib 0.54
=============================
I've done a lot of rewriting of the core of matplotlib to support some
new features - mainly fast handling of polygon collections (pcolor and
scatter) and since the changes were pervasive, I took to opportunity
to fix some things that were bugging me about the design of
matplotlib. If you use the API, creating your own Axes, Subplots,
Lines, Rectangles, Texts, or working directly with transforms and
bboxes, you will need to upgrade your code, since the constructors of
all these objects have been simplified. The major changes affecting
users of the matlab interface are for pcolor and scatter. These
changes and others are detailed below and in
http://matplotlib.sf.net/API_CHANGES. Sorry for the pain - in the
long run, the new design is much cleaner and easier to work with, and
as far as I can see, will be stable.
More general transformation architecture
----------------------------------------
Earlier versions of matplotlib handled transformation of x and y
separately (ie we assumed all transformations were separable) but this
makes is difficult to do rotations or polar transformations, for
example. The new transformation lays the framework for doing general
transformations; see the transforms module
http://matplotlib.sf.net/matplotlib.transforms.html.
More efficient pcolor
---------------------
pcolor is now implemented with matplotlib.collections. polygon
collections which should provide significantly faster performance
across backends. The return value from pcolor is now a PolyColleciton
object rather than a list of patches, but the API is largely
compatible. See http://matplotlib.sf.net/API_CHANGES. The old function
pcolor_classic is retained for full backward compatibility.
New scatter plots
-----------------
The http://matplotlib.sf.net/matplotlib.matlab.html#-scatter command
is rewritten, and is implemented in the backend with a new polygon
collection class. For large scatter plots, the performance is 5 times
faster across all backends and 10 times faster for the *Agg
backends. Also, scatter works with many symbols: diamonds, sqaures,
oriented triangles, circles and more. As with pcolor, the scatter
command returns a collection instance rather than a list of patches as
before; see See http://matplotlib.sf.net/API_CHANGES
Also the size argument is now in points^2 (the area of the symbol in
points) and is not in data coords as before. This fixes a few
problems: symbols are not skewed by unequally shaped axes, scatter
works with log coords w/o distoring the symbol, and it is matlab
compatible.
The function scatter_classic is the old scatter function and will work
identically.
Enhanced mathtext
-----------------
A significant rewrite of the mathtext module provides much more
precise layout. The freetype component has been factored out of the
layout engine and replaced by an abstract class for font
handling. This lays the groundwork for ps mathtext. The text clipping
problems have been fixed. Added spacing commands '\/' (small space)
and '\ ' (regular space), and '\hspace{frac}' (space is fraction of
pointsize) as well as composite chars such as \angstrom. Fixed
over/under subscripts so you can say x_i^j and nested subscripts if
you do x_i_{j} (you need the curlys)
Many new plot symbols and markers
---------------------------------
Thanks Gary Ruben. See
http://matplotlib.sf.net/matplotlib.matlab.html#-plot
Font cacheing
-------------
Paul Barrett added caching support to the font manager to increase
performance. This and other changes have dramatically improved
postscript backend performance.
Newlines in text
----------------
After much encouragement from Al, I finally got around to supporting
newline separated text in the Text frontend, so this is no longer
backend dependent. As a bonus, it even works with arbitrary
rotations. There is an additional text attribute 'multialignment' that
specifies the alignment of the lines in multiline text. See
http://matplotlib.sf.net/examples/multiline.py and
http://matplotlib.sf.net/screenshots.html#align_text. Works with all
text instances except mathtext.
Axes hold
---------
matlab compatible hold command determines whether subsequent plot
commands overlay current plot or clear the axes by default. Default
setting is set in matplotlibrc and toggled by the hold command.
New rc file options
-------------------
You can control grid properties and tick padding (the space between
the axes and tick label) in matplotlibrc. The new options and defaults
are
axes.hold : True # whether to clear the axes by default on
 # each plot command. Toggle with hold command
grid.color : k # grid color
grid.linestyle : : # dotted
grid.linewidth : 0.5 # in points 
tick.major.pad : 4 # distance to major tick label in points
tick.minor.pad : 4 # distance to the minor tick label in points
Full dash control
-----------------
You can precisely control the dashes with a sequence of on off ink in
points. See http://matplotlib.sf.net/examples/dash_control.py
Removed close buttons from GUI
------------------------------
Steve Chaplin persuasively argued these were a bad idea. It's taken me
a while not to instinctively try and click on the missing buttons, but
I'm used to it now.
Properly aligned text with arbitrary alignments
-----------------------------------------------
You can now expect horizontal and vertical alignment specifications to
work with text at an arbitrary angle, eg, 45 degrees. See
http://matplotlib.sf.net/examples/alignment_test.py
Added stem plotting command
---------------------------
See http://matplotlib.sf.net/matplotlib.matlab.html#-stem and
http://matplotlib.sf.net/examples/stem_plot.py
Bug fix roundup
---------------
Executive summary: fixed ps centering, errorbar autoscaling, constant
data plot, copy tick attribute, mathtext fontsizing in interactive
mode, missing draw if interactive, some numerix/numarray
incompatibilities in type handling, agg memory leak, wx tooltips and
close not returning interpreter.
See http://matplotlib.sf.net/CHANGELOG for details. 
Downloads at http://sourceforge.net/projects/matplotlib

has anyone come across this bug?
>>> from matplotlib.matlab import *
>>> a = arange(10)
>>> a.shape
(10,)
>>> plot(a)
[<matplotlib.lines.Line2D instance at 0x4147712c>]
>>> show()
this plot works ok but if we turn a into a one dimensional array then...
>>> a.shape=(10,1)
>>> a.shape
(10, 1)
>>> plot(a)
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/usr/lib/python2.3/site-packages/matplotlib/matlab.py", line 941, in plot
 try: lines = gca().plot(*args, **kwargs)
 File "/usr/lib/python2.3/site-packages/matplotlib/axes.py", line 1181, in plot
 self.yaxis.autoscale_view()
 File "/usr/lib/python2.3/site-packages/matplotlib/axis.py", line 405, in autoscale_view
 tup = self._majorTicker.locator.autoscale()
 File "/usr/lib/python2.3/site-packages/matplotlib/ticker.py", line 578, in autoscale
 self._locator = self.get_locator(d)
 File "/usr/lib/python2.3/site-packages/matplotlib/ticker.py", line 589, in get_locator
 fld = math.floor(ld)
TypeError: only rank-0 arrays can be converted to Python scalars.
>>>

>>>>> "Todd" == Todd Miller <jm...@st...> writes:
 Todd> (2) I could just build a numarray version of the matplotlob
 Todd> installer with each release. That would offload the work
 Todd> from you and would keep the matplotlib code cleaner.
If you want to do that I have no objections - I like this better than
maintaining both in a single build. I think we need to make the
matplotlib code work with either build (eg using the nx.Type scheme
you proposed) so that if the user switches their numerix setting with
a given build everything still works. But if there is interest in a
numarray build for win32, I see no reason why not. We should probably
be careful to coordinate so that the two releases are as similar as
possible, with the only difference being the default numerix setting
in the rc file.
JDH

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
 Perry> I had looked at that. I'm a little confused by the
 Perry> terminology though. This sounds like a prescription for
 Perry> changing the defaults for some parameters for a session
 Perry> rather than for a single figure. Do I misread that? (Also,
 Perry> on my browser these entries are much wider than the browser
 Perry> window for some reason; later in the faq that changes as do
 Perry> some of the fonts. I wonder if something is screwed up
 Perry> there).
You were rightfully confused. It said figure when it should say
session. I mainly work from scripts, with one figure per script, so I
was just munging them in my mind. I made a brief update to the FAQ in
my own tree, but with the dynamic customization you discuss below,
this will need to be updated again.
As for the browser problem, I have the same. I tried to spot an html
error that would explain it but haven't found it yet.
 Perry> Changing the use of the rcParams to be immediate rather
 Perry> than locked in at module initialization is more attractive
 Perry> to me (and may allow one to assign differnt rc sets to
 Perry> different backends by default as well; but that is not
 Perry> urgent). Do you mind changing when the parameters are
 Perry> picked up? (I'm asking that you do it now, just whether
 Perry> that is acceptable).
This seems like the way to go. Nothing really speaks against it
except the slightly inelegant use of a bunch of Nones in the
constructors. I'm happy to make the changes, or leave it to one of
you.
JDH

John Hunter wrote:
> >>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
> 
> Perry> Is there a means of using alternate rcParams dictionaries
> Perry> for use with different backends, say as a parameter to the
> Perry> print_figure method? It doesn't look like it at the
> Perry> moment. I'd guess to do that now means replacing rcParams
> Perry> temporarily, rendering the plot to the file, and resetting
> Perry> rcParams to what it was (I haven't actually tried it), but
> Perry> that seems clumsier than it should be.
> 
> There are a few ways to go here.
> 
> Probably the best is based on the answer to "How do I customize the
> default behavior of a single figure?"
> http://matplotlib.sourceforge.net/faq.html#CUSTOM
> 
I had looked at that. I'm a little confused by the terminology though.
This sounds like a prescription for changing the defaults for some
parameters for a session rather than for a single figure. Do I
misread that? (Also, on my browser these entries are much wider
than the browser window for some reason; later in the faq that changes
as do some of the fonts. I wonder if something is screwed up there).
[details about setting up session context and object intialization
snipped]
I'm thinking of the case where someone tailors plots interactively
and then wants to render the same plot, but with different defaults
for a png file or postscript in the same session. In that case
a session change of default isn't very useful. They basically are
going to be force to write a script, and run it from a different
session to get a different version. So I think that is going
to be somewhat inconvenient for some users.
Changing the use of the rcParams to be immediate rather than locked
in at module initialization is more attractive to me (and may allow
one to assign differnt rc sets to different backends by default as
well; but that is not urgent). Do you mind changing when the 
parameters are picked up? (I'm asking that you do it now, just
whether that is acceptable).
Thanks, Perry

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
 Perry> Is there a means of using alternate rcParams dictionaries
 Perry> for use with different backends, say as a parameter to the
 Perry> print_figure method? It doesn't look like it at the
 Perry> moment. I'd guess to do that now means replacing rcParams
 Perry> temporarily, rendering the plot to the file, and resetting
 Perry> rcParams to what it was (I haven't actually tried it), but
 Perry> that seems clumsier than it should be.
There are a few ways to go here.
Probably the best is based on the answer to "How do I customize the
default behavior of a single figure?"
http://matplotlib.sourceforge.net/faq.html#CUSTOM
Ie, you can set the rc params for a given session by updating the rc
dict before importing matplotlib. You could set up a module like
plot_contexts 
plot_contexts.py::
from matplotlib import rcParams
def use(s):
 if s == 'powerpoint':
 rcParams['figure.facecolor'] = 'b'
 rcParams['text.fontname'] = 'cmr10'
 rcParams['lines.linewidth'] = 2.0
 elif s = 'some journal'
 and so on
And at the script level you could do
import plot_contexts
plot_contexts.use('powerpoint')
from matplotlib.matlab import *
The one down side of the rcParams approach is that currently all the
object defaults are evaluated at module load time, so you can only
switch at the start of your python session. Eg, the current
constructors look like
class Line2D(Artist):
 def __init__(self, xdata, ydata,
 linewidth=rcParams['lines.linewidth'],
 linestyle=rcParams['lines.linestyle'],
 )
By changing all the constructor defaults to 
 def __init__(self, xdata, ydata,
 linewidth=None,
 linestyle=None,
 ):
 if linewidth is None: linewidth = rcParams['lines.linewidth'],
 if linestyle is None: linestyle = rcParams['lines.linestyle'],
we could defer those evaluations to construction time, so you could
switch contexts in the middle of an interactive session
 >>> plot_contexts.use('power point')
 >>> make_some_figs()
 >>> plot_contexts.use('some journal')
 >>> make_some_figs() # again
I already did this for the FontProperties so you can have context
fonts, as in examples/font_properties_demo.py. It wouldn't be much
work to do the same for the other properties controlled by rc.
As another approach, I have considered making the matplotlibrc finder
check the current dir first, and using that file if it finds one.
Then you could have dir based contexts.
JDH

I wonder what the recommended way of saving 
and using different plotting defaults is.
Let me give some background first. While many users 
like the current window color defaults (basically black
on white) some prefer white on black for interactive use
(for one thing, colors stand out more). And while they
may be morons for wanting to do so ;-), there is also
a very good reason to use such a color scheme for viewgraphs.
I don't know how many times I've suffered through a presentation
where the presenter showed the plots having a white background
and colored lines or symbols. In that setting, colors just don't
show well. ("well, you could see the yellow points in my version...")
On the other hand such color schemes don't print well (and
the current one does).
I could see someone wanting 2 or 3 different contexts. The 
current rcParams does allow for different save color faces, 
but that isn't quite enough for cases where text needs to be
white or something other than black to show up against black
bacgrounds.
Is there a means of using alternate rcParams dictionaries for 
use with different backends, say as a parameter to the print_figure
method? It doesn't look like it at the moment. I'd guess to do
that now means replacing rcParams temporarily, rendering the
plot to the file, and resetting rcParams to what it was (I haven't
actually tried it), but that seems clumsier than it should be.
Perry

On Fri, 2004年05月14日 at 11:27, Perry Greenfield wrote:
> Todd Miller wrote:
> > 
> > So, while this feels like walking backward, you can say:
> > 
> > y = int(self.height) - y.astype('s')
> > 
> > and expect it to work with either.
> > 
> If this is used as the workaround, perhaps local (to the module)
> versions of Int16 and such can be defined as 's' and so forth
> so that it will be easier to update code rather than litter
> it with such character codes.
> 
> Perry 
Good idea. I'll see if I can get numerix to take care of it.
Todd

Todd Miller wrote:
> 
> So, while this feels like walking backward, you can say:
> 
> y = int(self.height) - y.astype('s')
> 
> and expect it to work with either.
> 
If this is used as the workaround, perhaps local (to the module)
versions of Int16 and such can be defined as 's' and so forth
so that it will be easier to update code rather than litter
it with such character codes.
Perry 

On Fri, 2004年05月14日 at 08:35, John Hunter wrote:
> The new transformation module I've been working on is implemented in
> extension code. It offers a couple of important benefits, namely
> speed and generality (affines, nonseparable xy transformations). It's
> not in CVS yet because I'm still ironing out the details.
> 
> I have two methods for operating over sequences of x and y, seq_x_y
> and numerix_x_y. The first uses the python sequence API and the
> second uses the numerix api. I expect the latter will be a good bit
> faster for long lines, since it doesn't have the python object type
> coercion to deal with, but I haven't profiled it.
> 
> But there is a gotcha. When I compile the code, I use flag in
> setup.py to indicate whether to compile with Numeric or numarray.
> This sets a flag and that is used in the transforms module (and the
> image module) that will import arrayobject.h from either Numeric or
> numarray.
> 
> A problem can arise if someone compiles with one and uses a different
> setting in ~/.matplotlibrc. I compiled the module with Numeric but
> used numarray in my matplotlibrc. The transformation went fine,
> presumably thanks to the numarray compatibility layer. I passed the
> transformed arrays off to one of the backends, which does
> 
> from matplotlib.numerix import Int16
> 
> y = int(self.height) - y.astype(Int16)
> 
> and got a 
> 
> ValueError: type must be either a 1-length string, or python type
> object
> 
> clearly because of the difference between numpy and numarray type
> args.
Yeah. numarray has full blown type objects which form a hierarchy which
can be used to test for type properties such as signed, integral, etc. 
numarray uses names for its type objects that were used by Numeric to
make 1 character typecodes clearer and easier to remember. Thus, in
numarray Int16 is an object, but in Numeric Int16 is an alias for 's'.
Over time, our compatibility ambitions have grown so now numarray
generally works with Numeric typecodes wherever a type object is
expected. 
So, while this feels like walking backward, you can say:
 y = int(self.height) - y.astype('s')
and expect it to work with either.
> Another question is win32, where the user doesn't have the choice at
> compile time. If we compile in numpy for win32, the user's numarrays
> will be transformed into numpys at render time, but this won't affect
> the user arrays (unlike in scipy where the user is getting the return
> values) so I don't see it as a big deal. I think trying to compile in
> both or supplying alternate binaries is doable but may not be worth
> the maintenance and complexity.
>
> In any case, there are a couple of readers here who know a bit more
> about numarray and numeric than I do <wink> ; any thoughts?
(1) One thought I've had for handling this has been to improve the basic
binary compatibility of numarray with Numeric to the point that numerix
can be extended to the C-level. In this scheme, an extension would be
compiled against neither numarray nor Numeric but against numerix; 
which array package was actually being used would be figured out at run
time much as it works at the Python level now. I'm still exploring the
idea.
(2) I could just build a numarray version of the matplotlob installer
with each release. That would offload the work from you and would keep
the matplotlib code cleaner. 
Todd

John Hunter wrote:
> Is there a clever workaround for this problem? It doesn't affect any
> of the agg or PS backends. GTK and GD both need to convert their
> arrays to ints before passing them on to their respective renderers.
> One solution is to do the conversion in list comps
[...]
> Another question is win32, where the user doesn't have the choice at
> compile time. If we compile in numpy for win32, the user's numarrays
> will be transformed into numpys at render time, but this won't affect
> the user arrays (unlike in scipy where the user is getting the return
> values) so I don't see it as a big deal. I think trying to compile in
> both or supplying alternate binaries is doable but may not be worth
> the maintenance and complexity.
[...]
> 
> In any case, there are a couple of readers here who know a bit more
> about numarray and numeric than I do <wink> ; any thoughts?
>
Perhaps there is a clever workaround, but I wonder if the best solution
isn't to build dual versions of the extensions, one for Numeric and one 
for numarray if both are present (and this would also solve the win32
issue by distributing both). I think setup.py could be setup to do this,
and a mechanism for a module that uses these to use whichever 
is selected by the user to pick up the right sharable
(e.g., _numarray_mycext.so vs _Numeric_mycext.so). It's not
elegant, but it should be robust. Todd and I did talk about if
there was a way to make numarray arrays compatable at the binary 
level; perhaps, but I suspect it involves a lot work and I'm not
sure it will eliminate all issues. So do you want us to try to
come up with a an example setup.py to do this? Perhaps Todd will
have some other ideas.
Perry

The new transformation module I've been working on is implemented in
extension code. It offers a couple of important benefits, namely
speed and generality (affines, nonseparable xy transformations). It's
not in CVS yet because I'm still ironing out the details.
I have two methods for operating over sequences of x and y, seq_x_y
and numerix_x_y. The first uses the python sequence API and the
second uses the numerix api. I expect the latter will be a good bit
faster for long lines, since it doesn't have the python object type
coercion to deal with, but I haven't profiled it.
But there is a gotcha. When I compile the code, I use flag in
setup.py to indicate whether to compile with Numeric or numarray.
This sets a flag and that is used in the transforms module (and the
image module) that will import arrayobject.h from either Numeric or
numarray.
A problem can arise if someone compiles with one and uses a different
setting in ~/.matplotlibrc. I compiled the module with Numeric but
used numarray in my matplotlibrc. The transformation went fine,
presumably thanks to the numarray compatibility layer. I passed the
transformed arrays off to one of the backends, which does
from matplotlib.numerix import Int16
 y = int(self.height) - y.astype(Int16)
and got a 
 ValueError: type must be either a 1-length string, or python type
 object
clearly because of the difference between numpy and numarray type
args.
Is there a clever workaround for this problem? It doesn't affect any
of the agg or PS backends. GTK and GD both need to convert their
arrays to ints before passing them on to their respective renderers.
One solution is to do the conversion in list comps
 y = [ int(self.height-val) for val in y]
which obviously implies a performance hit but probably a bearable one
given the other speedups that the new transformation module implies
and that users have an option to use GTKAgg instead of GTK and Agg
instead of GD for optimal performance.
Another question is win32, where the user doesn't have the choice at
compile time. If we compile in numpy for win32, the user's numarrays
will be transformed into numpys at render time, but this won't affect
the user arrays (unlike in scipy where the user is getting the return
values) so I don't see it as a big deal. I think trying to compile in
both or supplying alternate binaries is doable but may not be worth
the maintenance and complexity.
In any case, there are a couple of readers here who know a bit more
about numarray and numeric than I do <wink> ; any thoughts?
JDH

Hi John,
thanks, it seems to work now atleast ..
warm regards
karthik
-----------------------------------------------------------------------
Karthikesh Raju,		 email: ka...@ja...
Researcher,			 http://www.cis.hut.fi/karthik
Helsinki University of Technology, Tel: +358-9-451 5389
Laboratory of Comp. & Info. Sc., Fax: +358-9-451 3277
Department of Computer Sc.,
P.O Box 5400, FIN 02015 HUT,
Espoo, FINLAND
-----------------------------------------------------------------------
On 2004年5月13日, John Hunter wrote:
> >>>>> "Karthikesh" == Karthikesh Raju <ka...@ja...> writes:
>
> Karthikesh> Hi John, Looks like in the previous mail, i had set
> Karthikesh> the build numarray on, now i removed that flag, and
> Karthikesh> the installation went on smooth, and i could
>
> Karthikesh> 1) pygtk, 2) gtk, and 3) matplotlib
>
> Karthikesh> things went smooth so far, and i run most of the
> Karthikesh> examples bearing some. Now i will try to set things
> Karthikesh> to auto slowly and try the rest.
>
>
> Great! Start with agg, then image, then gtkagg, and that may be all
> you need. Unless you want to use matplotlib interactively from the
> shell, in which case tkagg is your best bet.
>
> Karthikesh> BTW: the following were the developmental packages
> Karthikesh> that i needed here: (At work our sys's have not
> Karthikesh> installed any of the developmental packages)
>
> Thanks for the list! I'll put it on the web site.
>
> JDH
>
>

S=E6ll !
I was simply planning to be able to move between the default positions 'upp=
er right', 'upper left', etc
But I believe I can use _offset.
However it did not produce much effect
I have defined the legend the following way:
canvas.leg=3DFigure.legend(canvas.figure,tuple([i[1] for i in d]),tuple([i[=
0] for i in d]),'best')
And then when I toggle a button I apply the following move with the canvas =
object, which is just a test offset
 def toggle_legend(self, event):
 """ Toggle the label in the legend button=20
 between Upper Right and Upper Left """
 =20
 if self.Legend_button.get_active()=3D=3D1:
 self.Legend_button.set_label("Upper Right")
 else:
 self.Legend_button.set_label("Upper Left")
 self.leg._offset(0.1,0.56)
 self.draw()
 =20
 return
When I toggle the button, the label changes, but the legend is unmoved.
Am I missing something ?=20
Takk
Jean-Baptiste
On 2004年5月13日 05:20:28 -0500
John Hunter <jdh...@ni...> wrote:
> >>>>> "Jean-Baptiste" =3D=3D Jean-Baptiste Cazier <jc...@de...> wri=
tes:
>=20
> Jean-Baptiste> S_ll ! I would like to be able to move my
> Jean-Baptiste> Figure.legend Because the optimal position of the
> Jean-Baptiste> legend on my figure is not always the same, I added
> Jean-Baptiste> a button to the navigation toolbar to give the suer
> Jean-Baptiste> a chance to choose the position of the legend I
> Jean-Baptiste> knwo that I can get a handle on my first legend
> Jean-Baptiste> drawing, but how can I just modify its location ?
> Jean-Baptiste> Is there a move_location method for the
> Jean-Baptiste> Figure.legend ?
>=20
> There is currently no "move to" location, but there is an offset
> method where you can supply a deltxa, deltay in relative sizes, in
> your case fractions of the figure width and height. So if you wanted
> to move the legend 5% of the figure width to the right and 10% of the
> figure height up, you can call
>=20
> leg._offset(0.05, 0.10)
>=20
> The leading underscore means that this method was intended for
> internal use, and may change in future releases, but you can try it
> and see if it works for you. If it does, I can probably make it
> a public method for the next release.
>=20
> As always you'll need to call canvas.draw after setting the new legend
> location.
> =20
>=20
> JDH
--=20
-----------------------------
Jea...@de...
Department of Statistics
deCODE genetics Sturlugata,8
570 2993 101 Reykjav=EDk