matplotlib-users Mailing List for matplotlib (Page 9)

Hello Travis,
I worked about 7 years with Matlab, but at the end I gave up and I switched
to Python. This is mainly due to the fact that with new Matlab releases
(starting from R14) it is almost impossible to build a distributable
executable file. You can compile an application into an exe, but you have to
distribute such big files that I gave up. Moreover, GUI capabilities of
Python (wxPython) are much much (much)^Inf superior to Matlab ones.
Regarding your question:
> They're mostly concerned about
> cost and scriptability, but they're worried that the resulting Python
> code would be very slow.
This much depends on how you use Matlab. If you use highly specialized
mathematical routines, image processing, optimization routines and
everything that involves large matrix computations (inversion,
decomposition, system solving etc...), I would be in doubt on which software
I would use.
Loops, conditionals and friends are much much faster in Python than in
Matlab, even using JIT acceleration.
Both software have a fast learning curve (in my opinion).
In case of large matrix computations, I would try to compare Matlab
capabilities to Python Numeric/scipy.
However, if you could specify a little bit more which use of Matlab you do,
I can probably give some more advice (even if I am not an expert with
Numeric/scipy, so my Python routines may have to be optimized by someone
else ;-) ).
HTH.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.virgilio.it/infinity77

>>>>> "Joost" == Joost van Evert <joo...@gm...> writes:
 Joost> What does this mean in matplotlib practice? Which
 Joost> partitions does one put plotting scripts, that contain
 Joost> latex formulae, to prevent this error?
In practice, matplotlib uses your home dir to cache certain things,
though this location can be overridden).
I just updated CVS to use shutil.move in the texmanager and elsewhere,
so this problem will disappear in the next release.
JDH

On Mon, 2005年10月10日 at 12:17 -0600, Fernando Perez wrote:
> This could be considered a matplolib bug, or a python one, depending on your 
> perspective. os.rename() doesn't work across partitions, which makes it 
> (IMHO) worse than useless. You have to either protect on all uses against this 
> exception, or use shutil.move(), which does work across partitions:
What does this mean in matplotlib practice? Which partitions does one
put plotting scripts, that contain latex formulae, to prevent this
error? 
Greets,
Joost

All,
Lately folks in my office have started inquiring about the possibility
of porting some Matlab code to Python. They're mostly concerned about
cost and scriptability, but they're worried that the resulting Python
code would be very slow. The current Matlab version of the prime
porting target takes about 2 hours to run start to finish.=20
So I'm looking to either run some tests to prove that Python can keep up
or take someone else's results from similar tests and evangelize with
those.
I've googled "python vs. matlab" but most results seem to address
differences in the sort of code one has to write to achieve the same
ends, I'm interested in speed.
Anyone have any links or ammunition for the fight?
thanks,
Travis
--=20
 Travis Brady
 td...@fa...
--=20
http://www.fastmail.fm - Same, same, but different=85

Joost van Evert wrote:
> Dear list,
> /usr/local/lib/python2.4/site-packages/matplotlib/texmanager.py
> in make_dvi(self, tex, force)
> 125 # dir and move it if necessary and then cleanup
> 126 if os.path.exists(dvibase):
> --> 127 os.rename(dvibase, dvifile)
> 128 for fname in glob.glob(prefix+'*'):
> 129 os.remove(fname)
> 
> OSError: [Errno 18] Invalid cross-device link
This could be considered a matplolib bug, or a python one, depending on your 
perspective. os.rename() doesn't work across partitions, which makes it 
(IMHO) worse than useless. You have to either protect on all uses against this 
exception, or use shutil.move(), which does work across partitions:
Definition: shutil.move(src, dst)
Docstring:
 Recursively move a file or directory to another location.
 If the destination is on our current filesystem, then simply use
 rename. Otherwise, copy src to the dst and then remove src.
 A lot more could be done here... A look at a mv.c shows a lot of
 the issues this implementation glosses over.
So if you think that Python is OK in having such a useless os.rename, then 
it's a matplotlib bug (this is, after all, known os.rename behavior). In the 
short term, though, matplotlib would be well advised to use only os.rename 
when doing renamings *known to be in the same directory*. Anytime you use 
rename to actually move things, this problem can appear (and it's 
configuration-specific, hence impossible to detect during in-house testing).
Cheers,
f

Alex,
It would be helpful if you post your basedir (from the beginning of=20
setupext.py),
the output of the build command (maybe just the lines for nc_image) and=20=
the operating
system you are using. This will show whether python is looking for=20
libpng in
the correct directory.
Nadia
On Oct 10, 2005, at 5:38 AM, Alexander Borghgraef wrote:
> On 10/6/05, John Hunter <jdh...@ac...> wrote:
>>
>> The place to start poking around is in setupext.py's build_image
>>
>> This function does a numerix switch to add flags for Numeric and
>> numarray if it finds them.=A0=A0Both paths (Numeric and numarray) =
call
>>
>> =A0=A0=A0=A0add_agg_flags(module)
>>
>> and add_agg_flags calls
>>
>> =A0=A0=A0=A0module.libraries.append('png')
>>
>> so libpng should be in your link chain.=A0=A0Since you have a =
nonstandard
>> Numeric install, make sure the numerix logic is working as it should
>> (eg what is the value of "numerix" in build_image?)
> =A0The value of numerix is=A0 "Numeric", as it should be.=A0 Also,=A0=20=
> add_agg_flags is called four times,
> of which once inside build_image, so libpng should be linked in. I=20
> tried linking libpng into a simple
> c++ program, no problem there.
>
> --=20
> Alex Borghgraef=

Dear list,
activating latex rendering by change of the matplotlibrc variable
'text.usetex' to true gives me the following error. I am using
matplotlib 0.84 using python 2.4.1 on linux. Does anyknow know how to
solve this? This problem doesn't appear for the simple plot command:
 from matplotlib.pylab import *
 title(r'$\rho$')
 plot([1,2,3,4])
 show()
But when I plot multiple lines using the following approach:
 from matplotlib import pylab
 def plotroc(x,y, label=None):
 pylab.figure(0)
 pylab.plot(x,y,label=label)
 pylab.xlabel('1-specificity')
 pylab.ylabel('sensitivity')
 pylab.axis(xmin=0, xmax=1, ymin=0, ymax=1)
 
 plotroc([1,2,3,4],[4,4,2,1],label='a')
 plotroc([1,2,3,4],[4,3,2,1],label='b')
 pylab.savefig('test.eps') 
 
matplotlib comes with the following message:
 exceptions.OSError Traceback
 (most recent call last)
 
 /usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py in expose_event(self, widget, event)
 316 x, y, w, h = self.allocation
 317 self._pixmap_prepare (w, h)
 --> 318 self._render_figure(self._pixmap, w, h)
 319 self._need_redraw = False
 320
 
 ...
 
 /usr/local/lib/python2.4/site-packages/matplotlib/texmanager.py
 in make_dvi(self, tex, force)
 125 # dir and move it if necessary and then cleanup
 126 if os.path.exists(dvibase):
 --> 127 os.rename(dvibase, dvifile)
 128 for fname in glob.glob(prefix+'*'):
 129 os.remove(fname)
 
 OSError: [Errno 18] Invalid cross-device link
 
Thanks in advance,
Joost

On 10/6/05, John Hunter <jdh...@ac...> wrote:
>
>
> The place to start poking around is in setupext.py's build_image
>
> This function does a numerix switch to add flags for Numeric and
> numarray if it finds them. Both paths (Numeric and numarray) call
>
> add_agg_flags(module)
>
> and add_agg_flags calls
>
> module.libraries.append('png')
>
> so libpng should be in your link chain. Since you have a nonstandard
> Numeric install, make sure the numerix logic is working as it should
> (eg what is the value of "numerix" in build_image?)
The value of numerix is "Numeric", as it should be. Also, add_agg_flags is
called four times,
of which once inside build_image, so libpng should be linked in. I tried
linking libpng into a simple
c++ program, no problem there.
--
Alex Borghgraef

User to user question:
What is the *simplest* way when using pylab to turn off=20
exponential notation in the ticks?
Right now I do:
f1ax =3D gca()
f1ax.xaxis.set_major_formatter( P.FormatStrFormatter("%i") )
which works pretty well although I do not get nice commas
(e.g., 10,000 vs 10000).
Is it wrong to think that this might be nicely controlled by=20
a kwarg to xticks?
Thank you,
Alan Isaac
PS ticker.py uses x1e instead of =C3=971e. Is that effort to=20
stick with ASCII important?
=0D

Just wondering if anyone has tried to plot a stereonet with matplotlib
before I try either a modified polar plot or some variation of a
basemap. It would be a pretty nice class of plot to include as an
option in matplotlib.
Cheers,
Derek

http://news.bbc.co.uk/1/hi/world/americas/4313978.stm

> The divide-by-zero behavior may have changed between Numeric versions.
> What are the version numbers on each of your machines?
In fact, we just figured that out. The one that worked was with Numeric
24.0b2. The one that blew up was 23.8. For future reference, in case
anyone cares, you can make 23.8 work by compiling it with 
	-DHAVE_FINITE=1
E

Erik Curiel wrote:
> I've compiled MPL on a new Solaris 10 box, but now it won't initialize on
> this new box (though it still works fine on the old box). Here's what
> happened:
> 
>>>>from pylab import *
[snip]
> File
> "/usr/local/lib/python2.4/site-packages/matplotlib/numerix/_nc_imports.py",
> line 25, in ?
> inf = infty = infinity = Infinity = (array([1])/0.0)[0]
> OverflowError: math range error
The divide-by-zero behavior may have changed between Numeric versions.
What are the version numbers on each of your machines?
-- 
Robert Kern
rk...@uc...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

I've compiled MPL on a new Solaris 10 box, but now it won't initialize on
this new box (though it still works fine on the old box). Here's what
happened:
>>> from pylab import *
loaded rc file /home/erik/.matplotlib/matplotlibrc
matplotlib version 0.84
verbose.level debug
interactive is False
platform is sunos5
loaded modules: ['pylab', '_bisect', '__future__', 'copy_reg',
'sre_compile', 'distutils', '_sre', '__main__', 'site', '__builtin__',
'datetime', 'matplotlib.tempfile', 'encodings', 'pytz.datetime',
'sre_constants', 'distutils.string', 'dateutil', 'matplotlib.datetime',
'posixpath', '_random', 'tempfile', 'errno', 'matplotlib.warnings',
'binascii', 'encodings.codecs', 'matplotlib.sys', 're', 'os.path',
'pytz.sys', '_codecs', 'distutils.sysconfig', 'encodings.exceptions',
'pytz.sets', 'math', 'fcntl', 'stat', 'zipimport', 'string', 'warnings',
'encodings.types', 'UserDict', 'encodings.ascii', 'distutils.os',
'matplotlib', 'sys', 'pytz.tzinfo', 'pytz', 'matplotlib.__future__',
'codecs', 'distutils.re', 'readline', 'matplotlib.pytz', 'types', 'strop',
'matplotlib.dateutil', 'matplotlib.os', 'thread', 'sre', 'bisect',
'matplotlib.distutils', 'signal', 'distutils.errors', 'random',
'linecache', 'itertools', 'posix', 'encodings.aliases', 'sets',
'exceptions', 'sre_parse', 'pytz.bisect', 'distutils.sys', 'os']
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/usr/local/lib/python2.4/site-packages/pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "/usr/local/lib/python2.4/site-packages/matplotlib/pylab.py", line
194, in ?
 import cm
 File "/usr/local/lib/python2.4/site-packages/matplotlib/cm.py", line 5,
in ?
 import colors
 File "/usr/local/lib/python2.4/site-packages/matplotlib/colors.py", line
33, in ?
 from numerix import array, arange, take, put, Float, Int, where, \
 File
"/usr/local/lib/python2.4/site-packages/matplotlib/numerix/__init__.py",
line 59, in ?
 from _nc_imports import nx, inf, infinity, Infinity
 File
"/usr/local/lib/python2.4/site-packages/matplotlib/numerix/_nc_imports.py",
line 25, in ?
 inf = infty = infinity = Infinity = (array([1])/0.0)[0]
OverflowError: math range error
Any help would be greatly appreciated.
Thanks!
E

>>>>> "Martin" == Martin Richter <law...@gm...> writes:
 Martin> Can you reproduce the segmentation fault? Best,
Hi Martin,
Yes, I reproduced it yesterday <wink> The segfault arises when you
pass a path to draw_markers rather than a transformed path. Obviously
this needs to be fixed to raise rather than segfault. I do test for
this in the extension code
why the check in _backend_agg.cpp
 agg::conv_transform<agg::path_storage> *ppath;
 swig_type_info * descr = SWIG_TypeQuery("agg.conv_transform<agg::path_storage> *"); 
 assert(descr);
 if (SWIG_ConvertPtr(args[1].ptr(),(void **)(&ppath), descr, 0) == -1) 
 throw Py::TypeError("Could not convert agg.conv_transform<agg::path_storage>");
but clearly the check is not catching the bogus type and raising the
exception as it should. I'll work on this. In the meantime, you can
continue to work as long as you make sure you don't call draw_markers
with the wrong signature. Eg, in Line2D.draw, something like
 if funcname in ('_draw_square', '_draw_triangle_up'):
 markerFunc = getattr(self, funcname)
 markerFunc(renderer, gc, xt, yt)
The segfault you are getting is happening on the tick drawing, which
are implemented as line markers (eg _draw_tickleft). Since you
probably haven't ported the tick drawing to the new API, you are
getting the crash.
Guess I shouldn't have left this detail out yesterday!!
JDH

Hello everyone,
Hello John,
first of all: thanks for you mail, it was full of information!
I exchanged the lines in _backend_agg.cpp and tried to implement your
thoughts. While writing data.py wasn't a problem the trouble started when I
tried to run a little sample program with GTKAgg - I got a segmentation
fault. Unfortunately I'm not able to see where this one comes from. But when
using GTKAgg you're not able to draw markers at all; not even ticks ...
plotting a line is still possible when using
 from pylab import *
 axis('off')
 plot(arange(10))
so the error seems really due to the draw_markers() and not something else.
Below are the changed files.
Can you reproduce the segmentation fault?
Best,
Martin
P.S.: Once this particular example works, I will convert
the other markers (Arnd and I have worked out a scheme
for the size which seems consistent and simple to implement).
#### data.py 
"""
 Creates a dictionary containing information on how to draw markers.
 The values used within the paths are chosen so that the longest 
 dimension of a sourrounding rectangle is 1, e.g:
 triangle up ... has a height and a width of one
 square ........ has a height and a width of one
 ...
"""
from matplotlib import agg
markerd = {}
# triangle up
path = agg.path_storage()
path.move_to( 0, 0.5)
path.line_to(-0.5, -0.5)
path.line_to( 0.5, -0.5)
path.end_poly()
markerd['^'] = path
# square
path = agg.path_storage()
path.move_to(-0.5, -0.5)
path.line_to(-0.5, 0.5)
path.line_to( 0.5, 0.5)
path.line_to( 0.5, -0.5)
path.end_poly()
markerd['s'] = path
# tri_up (BTW this one change a bit)
offset = 2.0/3.0
offset1 = offset*0.8
offset2 = offset*0.5
path = agg.path_storage()
path.move_to(0, 0)
path.line_to(0, offset)
path.move_to(offset1, -offset2)
path.line_to(0, 0)
path.line_to(-offset1, -offset2)
path.end_poly()
markerd['2'] = path
####
#### changed routine for lines.py
def _draw_square(self, renderer, gc, xt, yt):
 side = renderer.points_to_pixels(self._markersize)
 rgbFace = self._get_rgb_face()
 path = d.markerd['s']
 if self._newstyle:
 scale = agg.trans_affine_scaling(side, side)
 transpath = agg.conv_transform_path(path, scale)
 renderer.draw_markers(gc, path, rgbFace, xt, yt,self._transform)
 else:
 offset = side*.5
 vertices = d.path_2_vertices(path)
 for (x,y) in zip(xt, yt):
 for verts in vertices:
 renderer.draw_polygon(gc, rgbFace, verts)
####
### Example call:
plot(arange(10),'bs')
###
-- 
Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl

>>>>> "Christopher" == Christopher Mutel <cm...@gm...> writes:
 Christopher> Hello again- Well, I think I have everything working,
 Christopher> thanks to your magicness. I had to manually set the
 Christopher> NUMERIX string to "Numeric", because even though I
 Christopher> had the latest python-numarray and
 Christopher> python-numarray-ext packages, setup.py still couldn't
 Christopher> find my numarray files. Observe:
Great! I don't know why you had this numarray problem but it may be
because the dev headers aren't installed in the debian package. If
you want it, it is trivial to compile and install from source. Then
you would need to recompile matplotlib so it would pick up the
numarray extension code.
In any case, glad you have something working!
For future reference, I like to keep mpl discussions on list unless
they get bogged down into machine specific technical minutae because
others will benefit from having this information archived.
CC-ing to list.
Cheers,
JDH
 Christopher> cmutel@veter:~/src/matplotlib-0.84 $ sudo python
 Christopher> setup.py build TKAgg requires TkInter running build
 Christopher> running build_py running build_ext building
 Christopher> 'matplotlib._na_transforms' extension gcc -pthread
 Christopher> -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
 Christopher> -Wstrict-prototypes -fPIC -Isrc -I. -I
 Christopher> -I/usr/local/include -I/usr/include
 Christopher> -I. -I/usr/local/include/python2.4 -c
 Christopher> src/_na_transforms.cpp -o
 Christopher> build/temp.linux-i686-2.4/src/_na_transforms.o
 Christopher> -DNUMARRAY=1 In file included from
 Christopher> /usr/local/include/python2.4/Python.h:8, from
 Christopher> CXX/Objects.hxx:9, from CXX/Extensions.hxx:19, from
 Christopher> src/_transforms.h:12, from src/_na_transforms.cpp:2:
 Christopher> /usr/local/include/python2.4/pyconfig.h:835:1:
 Christopher> warning: "_POSIX_C_SOURCE" redefined In file included
 Christopher> from
 Christopher> /usr/include/c++/3.3/i486-linux/bits/os_defines.h:39,
 Christopher> from
 Christopher> /usr/include/c++/3.3/i486-linux/bits/c++config.h:35,
 Christopher> from /usr/include/c++/3.3/functional:53, from
 Christopher> src/_na_transforms.cpp:1:
 Christopher> /usr/include/features.h:131:1: warning: this is the
 Christopher> location of the previous definition
 Christopher> src/_na_transforms.cpp:6:35: numarray/arrayobject.h:
 Christopher> No such file or directory src/_na_transforms.cpp: In
 Christopher> member function `Py::Object
 Christopher> Bbox::update_numerix(const Py::Tuple&)':
 Christopher> src/_na_transforms.cpp:436: error: `PyArrayObject'
 Christopher> undeclared (first use this function)
 Christopher> src/_na_transforms.cpp:436: error: (Each undeclared
 Christopher> identifier is reported only once for each function it
 Christopher> appears in.) src/_na_transforms.cpp:436: error: `x'
 Christopher> undeclared (first use this function)
 Christopher> src/_na_transforms.cpp:436: error: parse error before
 Christopher> `)' token src/_na_transforms.cpp:442: error: `y'
 Christopher> undeclared (first use this function)
 Christopher> src/_na_transforms.cpp:442: error: parse error before
 Christopher> `)' token src/_na_transforms.cpp: In member function
 Christopher> `Py::Object Transformation::numerix_x_y(const
 Christopher> Py::Tuple&, const Py::Dict&)':
 Christopher> src/_na_transforms.cpp:810: error: parse error before
 Christopher> `)' token src/_na_transforms.cpp:816: error: parse
 Christopher> error before `)' token src/_na_transforms.cpp:841:
 Christopher> error: `retx' undeclared (first use this function)
 Christopher> src/_na_transforms.cpp:841: error: parse error before
 Christopher> `)' token src/_na_transforms.cpp:848: error: `rety'
 Christopher> undeclared (first use this function)
 Christopher> src/_na_transforms.cpp:848: error: parse error before
 Christopher> `)' token src/_na_transforms.cpp: In member function
 Christopher> `Py::Object
 Christopher> Transformation::nonlinear_only_numerix(const
 Christopher> Py::Tuple&, const Py::Dict&)':
 Christopher> src/_na_transforms.cpp:895: error: parse error before
 Christopher> `)' token src/_na_transforms.cpp:901: error: parse
 Christopher> error before `)' token src/_na_transforms.cpp:917:
 Christopher> error: parse error before `)' token
 Christopher> src/_na_transforms.cpp:924: error: parse error before
 Christopher> `)' token src/_na_transforms.cpp:932: error:
 Christopher> `retmask' undeclared (first use this function)
 Christopher> src/_na_transforms.cpp:935: error: parse error before
 Christopher> `)' token src/_na_transforms.cpp: In function `void
 Christopher> init_na_transforms()': src/_na_transforms.cpp:1978:
 Christopher> error: `import_array' undeclared (first use this
 Christopher> function) error: command 'gcc' failed with exit
 Christopher> status 1
 Christopher> ...
 Christopher> cmutel@veter:/usr/local/lib/python2.4/site-packages $
 Christopher> ls /usr/include/python2.4/Numeric/ arrayobject.h
 Christopher> f2c.h ranlib.h ufuncobject.h
 Christopher> cmutel@veter:/usr/local/lib/python2.4/site-packages $
 Christopher> ls /usr/include/python2.4/numarray/ arraybase.h
 Christopher> ieeespecial.h libteacup.h numconfig.h arrayobject.h
 Christopher> libnumarray.h numarray.h nummacro.h cfunc.h
 Christopher> libnumeric.h numcomplex.h tc.h
 Christopher> And of course Numeric built fine.
 Christopher> Ultimately, of course, this doesn't matter, because I
 Christopher> can import matplotlib and pyalb as * without a
 Christopher> problem. I had a presentation yesterday, and I had to
 Christopher> export my data, and then import it on a clean build
 Christopher> of matplotlib on my windows machine, which wasn't
 Christopher> much fun.
 Christopher> Kepp on rockin'-
 Christopher> Chris Mutel
 Christopher> On 10/6/05, Christopher Mutel <cm...@gm...>
 Christopher> wrote:
 >> John-
 >> 
 >> I have been following the matplotlib mailing list for a while,
 >> and you have been unfailing kind and generous with your time in
 >> every message I have seen. I think what you're doing is damn
 >> great.
 >> 
 >> I actually already did to install your python package - I got
 >> errors with PyUnicodeUCS4... after seraching around on the net,
 >> this seems to be an error that is not resolvable without
 >> recompiliing either python or... wait for
 >> it... matplotlib. Here is the actual error code I get:
 >> 
 >> >>> from pylab import *
 >> /usr/lib/python2.4/site-packages/matplotlib/__init__.py:792:
 >> UserWarning: Could not find matplotlibrc; using defaults
 >> warnings.warn('Could not find matplotlibrc; using defaults')
 >> /usr/lib/python2.4/site-packages/matplotlib/__init__.py:813:
 >> UserWarning: could not find rc file; returning defaults
 >> warnings.warn(message) Traceback (most recent call last): File
 >> "<stdin>", line 1, in ? File
 >> "/usr/local/lib/python2.4/site-packages/pylab.py", line 1, in ?
 >> from matplotlib.pylab import * File
 >> "/usr/local/lib/python2.4/site-packages/pylab.py", line 198, in
 >> ?
 >> 
 >> File
 >> "/home/jdhunter/debs/matplotlib/usr/lib/python2.4/site-packages/matplotlib/axes.py",
 >> line 15, in ? File
 >> "/home/jdhunter/debs/matplotlib/usr/lib/python2.4/site-packages/matplotlib/axis.py",
 >> line 25, in ? File
 >> "/home/jdhunter/debs/matplotlib/usr/lib/python2.4/site-packages/matplotlib/font_manager.py",
 >> line 39, in ? ImportError:
 >> /usr/lib/python2.4/site-packages/matplotlib/ft2font.so:
 >> undefined symbol: PyUnicodeUCS4_AsUnicode
 >> 
 >> Is there any reason that this should happen? I don't know. I
 >> also don't know why apt doesn't install a matplotlibrc file.
 >> 
 >> I am pretty sure that my problems are the result of my having a
 >> machine that is out of whack in some respects. I installed
 >> python 2.4 form the standard Ubuntu package, and there is no
 >> reason that my package should break matplotlib while yours
 >> didn't. I don't know enough about linux to fit everything - on
 >> the other hand, the day after I installed Ubuntu the CD-Rom
 >> failed on my Linux box, so I don't have any way of
 >> re-installing everything.
 >> 
 >> I will try what you told me.
 >> 
 >> -Chris
 >> 
 >> On 10/6/05, John Hunter <jdh...@ac...> wrote:
 >> > >>>>> "Christopher" == Christopher Mutel <cm...@gm...>
 >> writes:
 >> >
 >> > Christopher> I'm having trouble compiling 0.84 on Python 2.4
 >> / > Christopher> Ubuntu Hoary (5.04). It seems like when GCC
 >> tries to > Christopher> build ft2font it can't find the two
 >> files referenced > Christopher> in CXX/extensions.hxx and
 >> CXX/objects.hxx.
 >> >
 >> > Do you mean CXX/Extensions.hxx and CXX/Objects.hxx? I just
 >> untarred > the 0.84 distribution and they are certainly there
 >> >
 >> > peds-pc311:/var/tmp/matplotlib-0.84> ls CXX/ > Config.hxx
 >> cxxsupport.cxx IndirectPythonInterface.cxx Version.hxx >
 >> cxxextensions.c Exception.hxx IndirectPythonInterface.hxx >
 >> cxx_extensions.cxx Extensions.hxx Objects.hxx
 >> >
 >> > Are you running setup.py from the dir in which it resides, eg
 >> >
 >> > > python setup.py build
 >> >
 >> > If so CXX/Extensions.hxx and CXX/Objects.hxx will be in your
 >> '.' (ie > current dir) include path. Perhaps there is a
 >> problem with include > flags in setupext.py. Try replacing the
 >> add_base_flags function in > that file with this one:
 >> >
 >> > def add_base_flags(module): > incdirs = [os.path.join(p,
 >> 'include') for p in basedir[sys.platform] > if
 >> os.path.exists(p)] > libdirs = [os.path.join(p, 'lib') for p in
 >> basedir[sys.platform] > if os.path.exists(p)] >
 >> module.include_dirs.extend(incdirs) >
 >> module.include_dirs.append('.') >
 >> module.library_dirs.extend(libdirs)
 >> >
 >> >
 >> >
 >> > Christopher> I installed (through apt) python-cxx, but this
 >> didn't > Christopher> seem to change anything.
 >> >
 >> > No, we use our own CXX
 >> >
 >> > Christopher> This seems like a completely trivial problem >
 >> Christopher> (especially compared to the other frutrations I
 >> have > Christopher> had with matplotlib in the past), but I
 >> don't know > Christopher> how to fix it...
 >> >
 >> > Perhaps the approach above will fix it. If not, you may want
 >> to > enable universe and multiverse in your
 >> /etc/apt/sources.list and then > add
 >> >
 >> > deb http://peds-pc311.bsd.uchicago.edu binary/
 >> >
 >> > and do
 >> >
 >> > > sudo apt-get update > > sudo apt-get python-matplotlib-jdh
 >> >
 >> > These are hoary debs that I maintain for our local system.
 >> I'm > certainly an amateur debian package maker, but they seem
 >> to work and > usually track matplotlib CVS fairly closely.
 >> >
 >> > JDH
 >> >
 >> >
 >> 

>>>>> "Mark" == Mark Bakker <ma...@gm...> writes:
 Mark> I just installed mpl 0.84 for Python23 on win32 and it works
 Mark> great, interactively on TkAgg, running from IDLE (sorry, I
 Mark> don't use gtk) Thanks a million, John. I will try to make
 Mark> the fixes to the axis('scaled') next week.
 Mark> Can you update us on the new Callback for resizing a window.
 Mark> Is that operational?
Only in gtk*. Perhaps you could take a look at the tk backend and add
the functionality for it? It should be fairly simple. See this
thread for more info:
 http://sourceforge.net/mailarchive/message.php?msg_id=12947502
Thanks,
JDH

How did you find out how to use a patch? Trial and Error?
I couldn't find any documentation other than http:// 
matplotlib.sourceforge.net/matplotlib.patches.html
and that doesn't show how to use it.
On 06 Oct, 2005, at 20:26, Mark Bakker wrote:
> Thanks for pointing out this drawing arrow patch.
> I wrote a quick function to use this.
> Figuring out the correct width to use requires some experimentation.
> It would be nice if we could eventually have a line with a regular
> line width, and a nicely sized arrow head. (Any ideas?).
> But this gives nices results.
> Mark
>
> from pylab import *
> def draw_arrow( x, y, dx, dy, width=1, color = 'k' ):
> ax = gca()
> a = Arrow( x, y, dx, dy, width )
> a.set_edgecolor(color)
> a.set_facecolor(color)
> ax.add_patch( a )
> draw_if_interactive()
> return a
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, 
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
**********************************************************************
Samuel M. Smith Ph.D.
2966 Fort Hill Road
Eagle Mountain, Utah 84043
801-768-2768 voice
801-768-2769 fax
**********************************************************************
"The greatest source of failure and unhappiness in the world is
giving up what we want most for what we want at the moment"
**********************************************************************

Thanks for pointing out this drawing arrow patch.
I wrote a quick function to use this.
Figuring out the correct width to use requires some experimentation.
It would be nice if we could eventually have a line with a regular
line width, and a nicely sized arrow head. (Any ideas?).
But this gives nices results.
Mark
from pylab import *
def draw_arrow( x, y, dx, dy, width=3D1, color =3D 'k' ):
 ax =3D gca()
 a =3D Arrow( x, y, dx, dy, width )
 a.set_edgecolor(color)
 a.set_facecolor(color)
 ax.add_patch( a )
 draw_if_interactive()
 return a

I just installed mpl 0.84 for Python23 on win32 and it works great,
interactively on TkAgg, running from IDLE (sorry, I don't use gtk)
Thanks a million, John. I will try to make the fixes to the axis('scaled')
next week.
Can you update us on the new Callback for resizing a window.
Is that operational?
Thanks again, Mark
On 10/6/05, John Hunter <jdh...@ac...> wrote:
> >>>>> "Mark" =3D=3D Mark Bakker <ma...@gm...> writes:
>
> Mark> Hey John - Any chance you can put a win32 install file of
> Mark> mpl 0.84 for Python 2.3 on the download page? I am teaching
> Mark> a class on computational methods, and I really would like
> Mark> the students to use the updated axis('equal') functionality.
> Mark> Would be much appreciated.
>
> Hey Mark -- Coincidentally, I've been working on this this morning.
> It's been a pain mainly because I have a new build machine and getting
> gtk to compile on win32 is no fun. I just uploaded the file so take
> it for a test drive and good luck with your class!
>
> JDH
>

Hi all,
I'm producing a plot with 11 lines, each of which must have a legend 
entry. I'd also like the plot to be wider than it is high.
Since I want a wide plot, I'd prefer to have my legend labels aligned in 
an array, rather than all 11 on top of each other. (So I can put them 
across the bottom of the figure.) Something like:
label1 label4 label7 label10
label2 label5 label8 label11
label3 label6 label9
Can the current matplotlib do this? If so, how?
Thanks,
Ryan
-- 
Ryan Gutenkunst |
Cornell LASSP | "It is not the mountain
 | we conquer but ourselves."
Clark 535 / (607)227-7914 | -- Sir Edmund Hillary
AIM: JepettoRNG |
 http://www.physics.cornell.edu/~rgutenkunst/

Hi, Hardip, try having a look at these instructions:
http://www.scipy.org/wikis/topical_software/CompilingMatPlotLibOnSolaris10
Hope this helps.
E
On Thu, 6 Oct 2005, Hardip Sanghera wrote:
> Date: Thu, 6 Oct 2005 10:19:29 +0100 (BST)
> From: Hardip Sanghera <hs...@as...>
> To: mat...@li...
> Subject: [Matplotlib-users] Cannot install matplotlib on Solaris 10
> 
> Hi,
> I cannot get matplotlib to install on my Solaris 10 platform, and would
> really appreciate some help.
> 
> I've installed the latest version of python from a Solaris 10 package:
> 
> % /usr/local/bin/python -V
> Python 2.4.2
> 
> Added various modules including Numarray and numeric:
> 
> % /usr/local/bin/python
> Python 2.4.2 (#1, Oct 3 2005, 01:55:05)
> [GCC 3.3.2] on sunos5
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numarray
> >>> import Numeric
> >>> ^D
> 
> Then downloading and unpacking the latest version, matplotlib-0.84
> However, it doesn't matter which version of gcc that I use with
> 
> setenv CC gcc
> 
> where gcc can be either the version that comes with Solaris 10:
> 
> % /usr/sfw/bin/gcc -v
> gcc version 3.4.3
> 
> % setenv CC /usr/sfw/bin/gcc
> % /usr/local/bin/python setup.py build
> 
> GTK requires pygtk
> GTKAgg requires pygtk
> running build
> running build_py
> creating build
> creating build/lib.solaris-2.10-sun4u-2.4
> copying lib/pylab.py -> build/lib.solaris-2.10-sun4u-2.4
> creating build/lib.solaris-2.10-sun4u-2.4/matplotlib
> copying lib/matplotlib/__init__.py ->
> build/lib.solaris-2.10-sun4u-2.4/matplotlib
> copying lib/matplotlib/_contour.py ->
> build/lib.solaris-2.10-sun4u-2.4/matplotlib
> ...
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h: In static member function `static wchar_t*
> std::char_traits<wchar_t>::move(wchar_t*, cons
> t wchar_t*, size_t)':
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h:336: error: `wmemmove' undeclared (first use this function)
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h: In static member function `static wchar_t*
> std::char_traits<wchar_t>::copy(wchar_t*, cons
> t wchar_t*, size_t)':
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h:340: error: `wmemcpy' undeclared (first use this function)
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h: In static member function `static wchar_t*
> std::char_traits<wchar_t>::assign(wchar_t*, si
> ze_t, wchar_t)':
> /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/bits/char_traits.
> h:344: error: `wmemset' undeclared (first use this function)
> error: command '/usr/sfw/bin/gcc' failed with exit status 1
> 
> (whole message file is the first attachtment)
> 
> or my own built version:
> 
> /usr/local/bin/gcc -v
> gcc version 3.3.2
> 
> which matches the version that python itself was built with:
> 
> % setenv CC /usr/local/bin/gcc
> % /usr/local/bin/python setup.py build
> 
> GTK requires pygtk
> GTKAgg requires pygtk
> running build
> running build_py
> creating build
> creating build/lib.solaris-2.10-sun4u-2.4
> copying lib/pylab.py -> build/lib.solaris-2.10-sun4u-2.4
> creating build/lib.solaris-2.10-sun4u-2.4/matplotlib
> ...
> /usr/include/pthread.h:305: error: parse error before `)' token
> /usr/include/pthread.h:306: error: `pthread_barrierattr_t' was not
> declared in
> this scope
> /usr/include/pthread.h:306: error: parse error before `,' token
> /usr/include/pthread.h:308: error: parse error before `*' token
> /usr/include/pthread.h:309: error: `pthread_barrier_t' was not declared in
> this
> scope
> /usr/include/pthread.h:309: error: parse error before `,' token
> /usr/include/pthread.h:311: error: `pthread_barrier_t' was not declared in
> this
> scope
> /usr/include/pthread.h:311: error: parse error before `)' token
> /usr/include/pthread.h:312: error: `pthread_barrier_t' was not declared in
> this
> scope
> /usr/include/pthread.h:312: error: parse error before `)' token
> error: command '/usr/local/bin/gcc' failed with exit status 1
> 
> (whole message file is the second attachtment)
> 
> Any help would really be appreciated as I need matplotlib to install.
> 
> cheers,
> hardip
> 
> -------------------------------------------------------------------------------
> 
> Hardip S. Sanghera (hs...@as...)
> 
> Institute of Astronomy Phone (office): 44 (0)1223 766663
> Madingley Road Fax: 44 (0)1223 337523
> Cambridge CB3 0HA
> United Kingdom

>>>>> "Martin" == Martin Richter <law...@gm...> writes:
 Martin> Hello everyone, Hello John,
 Martin> I would like to ask you (right before I'll mess everything
 Martin> up ;) if all this at least could work: What I would try
 Martin> for unification is writing the dictionary 'markerd' in
 Martin> lines.py (I'd prefer it right in front of 'class Line2D'
 Martin> as global - but there it isn't readable for a program
 Martin> later, isn't it?) and change the functions a bit like: def
 Martin> _make_triangle_down(size): return reshape([[0, -size,
Hi Martin,
Sorry for the delay getting back to you.
Perhaps the best approach is to predefine some paths in a new module,
eg data.py and define your path dictionary like so
 from matplotlib import agg
 markerd = {}
 # triangle up
 path = agg.path_storage()
 path.move_to(0, 1.0)
 path.line_to(-1.0, -1.0)
 path.line_to(1.0, -1.0)
 path.end_poly()
 markerd['^'] = path
 # square
 path = agg.path_storage()
 path.move_to(-1.0, -1.0)
 path.line_to(-1.0, 1.0)
 path.line_to(1.0, 1.0)
 path.line_to(1.0, -1.0)
 path.end_poly()
 markerd['s'] = path
We should think about what property of the marker should be conserved
(radius in points, area, area of circumscribed circle), because I
don't think we're terribly consistent on that one currently. In the
current implementation, the markersize of the triangle and square
gives the side, for the circle it gives the diameter. I'm not sure
what the right answer is here, but while you are doing this
refactoring it would be good to rationalize this and document any
changes in API_CHANGES.
In lines.py you could transform this path to scale it to the requested
size; something like
 def _draw_square(self, renderer, gc, xt, yt):
 side = renderer.points_to_pixels(self._markersize)
 s = side*0.5
 rgbFace = self._get_rgb_face()
 if self._newstyle:
 path = markerd['s']
 scale = agg.trans_affine_scaling(s,s) 
 transpath = agg.conv_transform_path(path, scale)
 renderer.draw_markers(gc, transpath, rgbFace, xt, yt, self._transform)
 
We would then need to modify renderer.draw_markers to take a
transformed path "transpath" rather than a path but this would be easy
-- I'm including a modified src/_backend_agg.cpp
RendererAgg::draw_markers function below if you want to go this route.
For code that doesn't want to use the path object, it is easy to
extract the moveto/lineto command as well as the vertices like so 
for i in range(path.total_vertices()):
 command, x, y = path.vertex(i)
 print command, x, y
With a little thought and care, you should be able to do away with all
the _draw_square, _draw_triangle, etc, in Line2D and replace them with
a single _draw_path, eg
 def _draw_path(self, renderer, gc, path, xt, yt):
 s = renderer.points_to_pixels(self._markersize)
 scale = agg.trans_affine_scaling(s,s) 
 transpath = agg.conv_transform_path(path, translation)
 renderer.draw_markers(gc, transpath, rgbFace, xt, yt, self._transform)
where the calling function pulls the path out of the dict.
Another advantage of this approach is that it could supports arbitrary
paths (including splines) and user extensible markers. Eg, the user
should be able to do
 markerd['somekey'] = somepath
and then be able to call 
 plot(rand(N), marker='somekey')
and have everything work automagically -- your task is growing :-)
Seriously, though, I think this would be a very nice addition, and not
too much work.
 Martin> Another question would be: Are those new for-loops in
 Martin> _draw_marker() too annoying (in the sense of speed)? (I
 Martin> quess they are vital for the _make_triangle_down()-like
I don't think the for loop is a problem because it is one per line
object, so as long as you don't create a ton of separate lines, you'll
be OK.
JDH
Here is the modified code from _backend_agg.cpp you will need
Py::Object
RendererAgg::draw_markers(const Py::Tuple& args) {
 //_draw_markers_cache(gc, path, rgbFace, xo, yo, transform)
 theRasterizer->reset_clipping();
 
 _VERBOSE("RendererAgg::_draw_markers");
 args.verify_length(6); 
 
 GCAgg gc = GCAgg(args[0], dpi);
 agg::conv_transform<agg::path_storage> *ppath;
 swig_type_info * descr = SWIG_TypeQuery("agg.conv_transform<agg::path_storage> *"); 
 assert(descr);
 if (SWIG_ConvertPtr(args[1].ptr(),(void **)(&ppath), descr, 0) == -1) 
 throw Py::TypeError("Could not convert agg.conv_transform<agg::path_storage>");
 facepair_t face = _get_rgba_face(args[2], gc.alpha);
 Py::Object xo = args[3];
 Py::Object yo = args[4];
 
 PyArrayObject *xa = (PyArrayObject *) PyArray_ContiguousFromObject(xo.ptr(), PyArray_DOUBLE, 1, 1); 
 
 if (xa==NULL) 
 throw Py::TypeError("RendererAgg::_draw_markers_cache expected numerix array");
 
 
 PyArrayObject *ya = (PyArrayObject *) PyArray_ContiguousFromObject(yo.ptr(), PyArray_DOUBLE, 1, 1); 
 
 if (ya==NULL) 
 throw Py::TypeError("RendererAgg::_draw_markers_cache expected numerix array");
 
 Transformation* mpltransform = static_cast<Transformation*>(args[5].ptr());
 
 double a, b, c, d, tx, ty;
 try {
 mpltransform->affine_params_api(&a, &b, &c, &d, &tx, &ty);
 }
 catch(...) {
 throw Py::ValueError("Domain error on affine_params_api in RendererAgg::_draw_markers_cache"); 
 }
 
 agg::trans_affine xytrans = agg::trans_affine(a,b,c,d,tx,ty); 
 
 size_t Nx = xa->dimensions[0];
 size_t Ny = ya->dimensions[0];
 
 if (Nx!=Ny) 
 throw Py::ValueError(Printf("x and y must be equal length arrays; found %d and %d", Nx, Ny).str());
 
 
 double heightd = double(height); 
 ppath->rewind(0);
 //ppath->flip_y(0,0);
 //typedef agg::conv_curve<agg::path_storage> curve_t;
 typedef agg::conv_curve<agg::conv_transform<agg::path_storage> > curve_t;
 curve_t curve(*ppath);
 //maxim's suggestions for cached scanlines
 agg::scanline_storage_aa8 scanlines; 
 theRasterizer->reset();
 agg::int8u* fillCache = NULL;
 unsigned fillSize = 0;
 if (face.first) {
 theRasterizer->add_path(curve);
 agg::render_scanlines(*theRasterizer, *slineP8, scanlines); 
 fillSize = scanlines.byte_size();
 fillCache = new agg::int8u[fillSize]; // or any container
 scanlines.serialize(fillCache);
 }
 
 agg::conv_stroke<curve_t> stroke(curve);
 stroke.width(gc.linewidth);
 stroke.line_cap(gc.cap);
 stroke.line_join(gc.join); 
 theRasterizer->reset();
 theRasterizer->add_path(stroke);
 agg::render_scanlines(*theRasterizer, *slineP8, scanlines); 
 unsigned strokeSize = scanlines.byte_size();
 agg::int8u* strokeCache = new agg::int8u[strokeSize]; // or any container
 scanlines.serialize(strokeCache);
 theRasterizer->reset_clipping();
 
 if (gc.cliprect==NULL) { 
 rendererBase->reset_clipping(true); 
 }
 else {
 int l = (int)(gc.cliprect[0]) ; 
 int b = (int)(gc.cliprect[1]) ; 
 int w = (int)(gc.cliprect[2]) ; 
 int h = (int)(gc.cliprect[3]) ; 
 rendererBase->clip_box(l, height-(b+h),l+w, height-b);
 }
 double thisx, thisy;
 for (size_t i=0; i<Nx; i++) {
 thisx = *(double *)(xa->data + i*xa->strides[0]);
 thisy = *(double *)(ya->data + i*ya->strides[0]);
 
 if (mpltransform->need_nonlinear_api())
 try { 
	mpltransform->nonlinear_only_api(&thisx, &thisy);
 }
 catch(...) {
	continue;
 }
 
 xytrans.transform(&thisx, &thisy);
 thisy = heightd - thisy; //flipy
 thisx = (int)thisx + 0.5;
 thisy = (int)thisy + 0.5;
 
 agg::serialized_scanlines_adaptor_aa8 sa;
 agg::serialized_scanlines_adaptor_aa8::embedded_scanline sl;
 
 if (face.first) {
 //render the fill
 sa.init(fillCache, fillSize, thisx, thisy);
 rendererAA->color(face.second); 
 agg::render_scanlines(sa, sl, *rendererAA);
 }
 
 //render the stroke
 sa.init(strokeCache, strokeSize, thisx, thisy);
 rendererAA->color(gc.color); 
 agg::render_scanlines(sa, sl, *rendererAA);
 
 } //for each marker 
 Py_XDECREF(xa);
 Py_XDECREF(ya);
 
 if (face.first) 
 delete [] fillCache;
 delete [] strokeCache;
 return Py::Object();
 
}

 skip> I installed the fink version of mpl on my 10.3.9 laptop the other
 skip> day. I've not been able to work around font problems ...
 John> What version of matplotlib are you using. 
According to fink I am using
 matplotlib-py24 0.84-2
 freetype219 2.1.9-1
 freetype219-shlibs 2.1.9-1
The -1 and -2 are presumably fink package numbers.
 John> I suggest either upgrading to the most recent mpl which should be
 John> tolerant of bad fonts.
Unfortunately, I think I'm as up-to-date as I can get, right?
 John> If that doesn't work, you might want to look into the font_manager
 John> module, and hack the font finding machinery to just return the mpl
 John> system fonts (eg Vera*). If you search for
 John> self.ttffiles = findSystemFonts(paths) + findSystemFonts()
 John> you'll find the spot where the font search list is set and you
 John> could manually hack this. We could provide an override setting
 John> for the font manager in rc that says "just use such and such font
 John> dirs".
Thanks, I'll check into this this evening...
Skip