matplotlib-devel Mailing List for matplotlib

 Hi all,
I just realised that the fonts in eps files produced with the "usetex"
switch where not T1 fonts. The fix is quite easy, during the LaTeX
compiling we should include a package that provides T1 fonts. Not I am
not sure which one to use. I like the lmodern, but it is not available
everywhere (on Ubuntu it is not installed by default with LaTeX). The
package "times" is more universal, but has less international glyphs.
Yet this is a low hanging fruit that will improve the look of the pdf
files created by matplotlib.
Ga=EBl

The developer list had grown a bit large and did not reflect people
who were actively working on the project, so I decided to prune it
down to people who have made commits in 2006 or people who I know are
planning to make commits soon. If you would like to be added back at
any point, just email me and I'll reinstate you.
Thanks,
JDH

Hi there,
would it be possible to get SVN write access for matplotlib (username 
"nnemec")?
Currently, I have four open patches waiting for inclusion (see 
sourceforge "Patches", submitted by "nnemec") and nobody seems to have 
the time to put them into the SVN repo. This is particularly annoying 
since a number of changes were done to the same files in SVN, so I had 
to update the patches manually several times.
I don't find the time to contribute code very often, but when I do so, I 
do invest some time and effort to produce high-quality code.
Thanks,
Norbert Nemec

icpc -bundle -undefined dynamic_lookup build/temp.macosx-10.3- 
i386-2.5/src/_nc_transforms.o build/temp.macosx-10.3-i386-2.5/src/ 
mplutils.o build/temp.macosx-10.3-i386-2.5/CXX/cxx_extensions.o build/ 
temp.macosx-10.3-i386-2.5/CXX/cxxsupport.o build/temp.macosx-10.3- 
i386-2.5/CXX/IndirectPythonInterface.o build/temp.macosx-10.3- 
i386-2.5/CXX/cxxextensions.o -L/opt/local/lib -L/usr/lib -lstdc++ -lm 
-o build/lib.macosx-10.3-i386-2.5/matplotlib/_nc_transforms.so
ld: warning -prebind has no effect with -bundle
ld: multiple definitions of symbol 
__ZNSbItSt11char_traitsItESaItEE4_Rep20_S_empty_rep_storageE
build/temp.macosx-10.3-i386-2.5/src/_nc_transforms.o definition of 
__ZNSbItSt11char_traitsItESaItEE4_Rep20_S_empty_rep_storageE in 
section (__DATA,__bss)
build/temp.macosx-10.3-i386-2.5/CXX/cxx_extensions.o definition of 
__ZNSbItSt11char_traitsItESaItEE4_Rep20_S_empty_rep_storageE in 
section (__DATA,__bss)
build/temp.macosx-10.3-i386-2.5/CXX/cxxsupport.o definition of 
__ZNSbItSt11char_traitsItESaItEE4_Rep20_S_empty_rep_storageE in 
section (__DATA,__bss)
error: command 'icpc' failed with exit status 1
Warning: the following items did not execute (for py-matplotlib): 
com.apple.build
Error: Status 1 encountered during processing.
# echo __ZNSbItSt11char_traitsItESaItEE4_Rep20_S_empty_rep_storageE|c+ 
+filt
std::basic_string<unsigned short, std::char_traits<unsigned short>, 
std::allocator<unsigned short> >::_Rep::_S_empty_rep_storage
is defined in
src/_nc_transforms.o
CXX/cxx_extensions.o
CXX/cxxsupport.o
What am I doing wrong?

>>>>> "Steven" == Steven Chaplin <ste...@ya...> writes:
 Steven> Does mpl only work with specific versions of numpy?
 Steven> Should mpl check for a required version and report an
 Steven> error if its not there?
numpy has been a bit of a moving target of late, and typically the
latest release of mpl works with the latest release of numpy, and mpl
svn works with numpy svn, but you can't mix and match. Hopefully this
will stabilize soon.
JDH

When using the latest matplotlib from svn and numpy version 0.9.6 I get:
$ ./simple_plot.py
Traceback (most recent call last):
 File "./simple_plot.py", line 6, in ?
 from pylab import *
 File "/usr/lib/python2.4/site-packages/pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line 197, in ?
 import cm
 File "/usr/lib/python2.4/site-packages/matplotlib/cm.py", line 5, in ?
 import colors
 File "/usr/lib/python2.4/site-packages/matplotlib/colors.py", line 33, in ?
 from numerix import array, arange, take, put, Float, Int, where, \
 File "/usr/lib/python2.4/site-packages/matplotlib/numerix/__init__.py", line 145, in ?
 __import__('fft', g, l)
 File "/usr/lib/python2.4/site-packages/matplotlib/numerix/fft/__init__.py", line 11, in ?
 from numpy.dft.old import *
ImportError: No module named old
Does mpl only work with specific versions of numpy?
Should mpl check for a required version and report an error if its not there?
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

On 9/25/06, Cedric Gustin <ced...@gm...> wrote:
> John Hunter wrote:
> >>>>>> "Cedric" == Cedric Gustin <ced...@gm...> writes:
> >
> > Cedric> Or, if you want, I can give you early access to pygtk
> > Cedric> binaries for python 2.5 for testing purpose with
> > Cedric> matplotlib ? Just tell me if you need pygtk-2.10 or 2.8 ?
> >
> > Most likely 2.8, but Steve (who is the gtk maintainer) may feel
> > otherwise, so I CCd him in case he has any input here.
>
> I uploaded binaries here
>
> http://www.gustin.be/win32/pygtk/2.8/
>
> Please note that this is a temporary storage location as I am in the
> process of moving my binaries to the gnome servers.
Thanks for the builds. I was able to build against them no problem.
I would like to push a minor bump for python2.5 and to fix a few of
the small issues Andrew Straw mentioned about the last release. Does
Wednesday sound doable for this?
- Charlie

John Hunter wrote:
>>>>>> "Cedric" == Cedric Gustin <ced...@gm...> writes:
> 
> Cedric> Or, if you want, I can give you early access to pygtk
> Cedric> binaries for python 2.5 for testing purpose with
> Cedric> matplotlib ? Just tell me if you need pygtk-2.10 or 2.8 ?
> 
> Most likely 2.8, but Steve (who is the gtk maintainer) may feel
> otherwise, so I CCd him in case he has any input here.
I uploaded binaries here
http://www.gustin.be/win32/pygtk/2.8/
Please note that this is a temporary storage location as I am in the
process of moving my binaries to the gnome servers.
Cedric

>>>>> "Cedric" == Cedric Gustin <ced...@gm...> writes:
 Cedric> Or, if you want, I can give you early access to pygtk
 Cedric> binaries for python 2.5 for testing purpose with
 Cedric> matplotlib ? Just tell me if you need pygtk-2.10 or 2.8 ?
Most likely 2.8, but Steve (who is the gtk maintainer) may feel
otherwise, so I CCd him in case he has any input here.
Thanks,
JDH

Hi John and the matplotlib people,
John Hunter wrote:
>>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
> 
> Charlie> At what point should we push another minor release
> Charlie> for py2.5? or should we at all? I am able to compile and
> Charlie> run the latest in svn on all 3 major platforms. The only
> Charlie> missing component is pygtk for windows. 0.87.5 is not
> Charlie> py2.5 compatible in many ways. Just thought I would
> Charlie> throw it out there.
> 
> I've CCd Cedric Gustin, who maintains pygtk for win32. Cedric, do you
> plan to push out a python2.5 version in the near future? If so, we
> can hold up the mpl release which uses some pygtk extension code in
> building. If not, we can go ahead with the release w/o gtk support,
> since this is not a common backend on windows.
Yes, pygtk binaries for python 2.5 will be available this week. I just
need a few more days as I'm also working on binaries for
pygtk-2.10/pygobject-2.12/pycairo-1.2.
Or, if you want, I can give you early access to pygtk binaries for
python 2.5 for testing purpose with matplotlib ? Just tell me if you
need pygtk-2.10 or 2.8 ?
Cedric

* Short Story :
I want to create my custom navigation bar with my custom zoom behavior:
My first step is zooming by pressing +/- keys to zoom in and zoom out 
while pointing the mouse to the "zoom's center".
I the long run I want a zooming and panning behavior interact smoothly 
with images (similar to photoshop's):
- Zooming with the left button to zoom in the right button to zoom out.
- Zooming with the mouse wheel.
- Other interactions ...
But I am stuck :-(
* Question :
My question is how do you "magnify" the image after change the axes ?
(with
self.axes.set_xlim((x1, x2))
self.axes.set_ylim((y1, y2))
)
* Long story:
First, I wanted to understand how the zoom worked. So I traced the zoom 
functionality from the NavigationToolbar2Wx to the following method:
- backend._bases.NavigationToolbar2.drag_pan
 From what I understand, this is where the magic bar happens?
Now I wrote a dirty method ( see OnKeyPress below ) where I drive the 
zoom by changing the xmin,xmax,ymin,ymax when I press any key instead of 
the default mouse dragging behavior.
When I zoom out:
xmin,xmax = Xmin + 50, Xmax - 50
ymin,ymax = Ymin + 50, Ymax – 50
it works find. The image becomes smaller.
But, when I zoom in as below
xmin,xmax = Xmin - 50, Xmax + 50
ymin,ymax = Ymin - 50, Ymax + 50
the image just get cropped but not magnified. I other words
self.axes.set_xlim and self.axes.set_ylim do not make the "data pixels 
bigger" (as happends in the correct zoom funcionality), they just stay 
the same size. The image becomes smaller and smaller instead of keeping 
the same size with les "data pixels into it"...
def OnKeyPress(self, event):
if not event.inaxes: return
x, y = self.axes.transData.inverse_xy_tup( (event.x, event.y))
Xmin,Xmax=self.axes.get_xlim()
Ymin,Ymax=self.axes.get_ylim()
# Dirty hack to understand how zoom works
xmin,xmax = Xmin - 50, Xmax + 50
ymin,ymax = Ymin - 50, Ymax + 50
if self.axes.get_xscale()=='log':
alpha=log(Xmax/Xmin)/log(xmax/xmin)
x1=pow(Xmin/xmin,alpha)*Xmin
x2=pow(Xmax/xmin,alpha)*Xmin
else:
alpha=(Xmax-Xmin)/(xmax-xmin)
x1=alpha*(Xmin-xmin)+Xmin
x2=alpha*(Xmax-xmin)+Xmin
if self.axes.get_yscale()=='log':
alpha=log(Ymax/Ymin)/log(ymax/ymin)
y1=pow(Ymin/ymin,alpha)*Ymin
y2=pow(Ymax/ymin,alpha)*Ymin
else:
alpha=(Ymax-Ymin)/(ymax-ymin)
y1=alpha*(Ymin-ymin)+Ymin
y2=alpha*(Ymax-ymin)+Ymin
self.axes.set_xlim((x1, x2))
self.axes.set_ylim((y1, y2))
self.canvas.draw()
Any help would be welcomed!
Daniel.

>>>>> "Nicholas" == Nicholas Young <mat...@su...> writes:
 Nicholas> Hi, I sent this message to the list this time yesterday
 Nicholas> and it doesn't seem to have either arrived or bounced -
 Nicholas> so I'm trying again.
I Nicholas -- I just applied this to svn. Thanks!
JDH

John Hunter wrote:
>>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
> Manuel> would be nice. Or, if I write something like this myself,
> Manuel> is there any chance to add this to matplotlib ?
> 
> certainly.
I personally find it a little bit confusing to have the option to define
a marker-symbol via two different keywords: marker and verts. Isn't it
possible and more natural to use the same keyword (maker) for multiple
options?
Hm , how about the following ideas:
- remove keyword verts again
- check type of argument of marker
 -> string: behave as before
 -> a list or a tuple that may be
 (numsides, style, [optional angle])
 or
 (verts, style, [optional angle])
- then it would be possible to define a custom symbol giving the number
of sides it should have + a style (i.e, filled or starred)
 AND
- to define a custom symbol using a list of (x,y) points
I have fiddled a little bit around with matplotlib/axes.py and attach a
file that contains a modified version of the function scatter() in
axes.py, as well as a little script and it's output.
What is missing - and I haven't tried that - is to add a class similar
to RegularPolyCollection for Lines allowing for none-filled symbols.
This should/could produce star-like symbols. Adding the option style for
verts would also allow e.g. S-shaped line-symbols (-> Create a
LineCollection instead of a PolyCollection).
As you can see in the modified scatter function, I also added a
rescaling for 'verts'. This rescaling assumes that the vertices are
centred on the coordinate origin (or if not, one has the option to
systematically displace symbols !), and rescales them such that the
largest distance from the origin is 1.
I hope this is somehow helpful ...!?
Manuel

On 9/21/06, Boyd Waters <bw...@nr...> wrote:
>
> On Sep 21, 2006, at 1:52 PM, Charlie Moad wrote:
>
> > At what point should we push another minor release for py2.5? or
> > should we at all?
>
> FWIW, I have matplotlib built against Python 2.5 on my Mac with the
> patches I posted in August.
> http://www.mail-archive.com/mat...@li.../
> msg00293.html
The problems addressed by those patches have been fixed. Win32, linux
and osx all compile fine now.
Thanks,

On Sep 21, 2006, at 1:52 PM, Charlie Moad wrote:
> At what point should we push another minor release for py2.5? or
> should we at all?
FWIW, I have matplotlib built against Python 2.5 on my Mac with the 
patches I posted in August.
http://www.mail-archive.com/mat...@li.../ 
msg00293.html
Not sure if that helps...
- boyd
Boyd Waters
Scientific Programmer
National Radio Astronomy Observatory
http://www.aoc.nrao.edu

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> At what point should we push another minor release
 Charlie> for py2.5? or should we at all? I am able to compile and
 Charlie> run the latest in svn on all 3 major platforms. The only
 Charlie> missing component is pygtk for windows. 0.87.5 is not
 Charlie> py2.5 compatible in many ways. Just thought I would
 Charlie> throw it out there.
I've CCd Cedric Gustin, who maintains pygtk for win32. Cedric, do you
plan to push out a python2.5 version in the near future? If so, we
can hold up the mpl release which uses some pygtk extension code in
building. If not, we can go ahead with the release w/o gtk support,
since this is not a common backend on windows.
JDH

 At what point should we push another minor release for py2.5? or
should we at all? I am able to compile and run the latest in svn on
all 3 major platforms. The only missing component is pygtk for
windows. 0.87.5 is not py2.5 compatible in many ways. Just thought I
would throw it out there.
Charlie

Hi Nicholas,
Thank you for the submission. I won't have time to look at this for a while (I 
will be out of town and out of email contact for a couple of weeks.) Maybe 
one of the other developers will have some time to consider your patch, 
otherwise, I'll have a look when I get back. Would you post it to the bug 
tracker at the sourceforge site?
Darren
On Wednesday 20 September 2006 12:34, Nicholas Young wrote:
> Hi,
>
> I sent this message to the list this time yesterday and it doesn't seem
> to have either arrived or bounced - so I'm trying again.
>
> I've written a patch (attached) to allow the PS backend to respect the
> dpi that's given to the FigureCanvasPS on initialisation when saving
> images. The solution I came with to do this isn't the nicest, but I
> couldn't see any significantly different way to do it without changing
> the rendering process for images.
>
> What I've done is add a get_image_magnification method to the default
> backend with a default return value of 1.0. This magnification factor
> is then taken by the draw method of the figure, axes or image and passed
> as a keyword argument to the make_image method of the image where it
> used to scale the widthDisplay and heightDisplay returned from the
> bounding box. (I also changed the self.make_image(False) call in
> Image.write_png to self.make_image() as I'm pretty sure that's what was
> meant to be - and if I hadn't the introduction of my new keyword
> argument would have resulted in a zero size image.)
>
> By returning a magnification of dpi/72.0, the PS backend is able to
> instruct the image instances to create larger images which it then
> scales by an appropriate value on output to give the requested dpi.
>
> This patch, or something like it, is vital for me at the moment because
> the low 72 dpi output used by matplotlib at the moment gives rise to
> some fairly significant distortion to my results. I imagine others will
> come across the same problem.
>
> I hope this patch is useful,
> Nicholas Young

Hi Nicholas,
Thank you for the submission. I won't have time to look at this for a while=
 (I=20
will be out of town and out of email contact for a couple of weeks.) Maybe=
=20
one of the other developers will have some time to consider your patch,=20
otherwise, I'll have a look when I get back. Would you post it to the bug=20
tracker at the sourceforge site?
Darren
On Wednesday 20 September 2006 12:34, Nicholas Young wrote:
> Hi,
>
> I sent this message to the list this time yesterday and it doesn't seem
> to have either arrived or bounced - so I'm trying again.
>
> I've written a patch (attached) to allow the PS backend to respect the
> dpi that's given to the FigureCanvasPS on initialisation when saving
> images. =A0The solution I came with to do this isn't the nicest, but I
> couldn't see any significantly different way to do it without changing
> the rendering process for images.
>
> What I've done is add a get_image_magnification method to the default
> backend with a default return value of 1.0. =A0This magnification factor
> is then taken by the draw method of the figure, axes or image and passed
> as a keyword argument to the make_image method of the image where it
> used to scale the widthDisplay and heightDisplay returned from the
> bounding box. =A0(I also changed the self.make_image(False) call in
> Image.write_png to self.make_image() as I'm pretty sure that's what was
> meant to be - and if I hadn't the introduction of my new keyword
> argument would have resulted in a zero size image.)
>
> By returning a magnification of dpi/72.0, the PS backend is able to
> instruct the image instances to create larger images which it then
> scales by an appropriate value on output to give the requested dpi.
>
> This patch, or something like it, is vital for me at the moment because
> the low 72 dpi output used by matplotlib at the moment gives rise to
> some fairly significant distortion to my results. =A0I imagine others will
> come across the same problem.
>
> I hope this patch is useful,
> Nicholas Young

>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
 Manuel> would be nice. Or, if I write something like this myself,
 Manuel> is there any chance to add this to matplotlib ?
certainly.

Hi,
when I try to plot a line that contains circles, I obtain this error:
/usr/lib/python2.4/site-packages/matplotlib/lines.py in
_draw_circle(self, renderer, gc, xt, yt, point)
 616 for (x,y) in zip(xt, yt):
 617 renderer.draw_arc(gc, rgbFace,
--> 618 x, y, w, w, 0.0, 360.0, 0.0)
TypeError: draw_arc() takes exactly 9 arguments (10 given)
I guess there is an extra '0.0' argument.
I found this error in matplotlib-0.87.5 (using gtk backend).
Regards
Marco 
-- 
"I videogiochi non influenzano i bambini. Voglio dire, se Pac-Man avesse
influenzato la nostra generazione, staremmo tutti saltando in sale
scure, masticando pillole magiche e ascoltando musica elettronica
ripetitiva."
"Videogames do not influence kids. I mean, if Pac-Man influenced our
generation, we were all jumping in dark rooms, chomping pills and
listening to electronic repeating music."
Kristian Wilson, Nintendo Inc. 1989

Hi,
first of all "scatter_custom_symbol.py" is great ! I really like this.
But...
May I express some idea/suggestions concerning custom symbols:
I came from supermongo to matplotlib. And I liked the way you could
define symbols in supermongo:
 PTYPE n s
where "s" gives the style of the symbol:
 s = 0 open
 s = 1 skeletal; all vectices are connected to the centre
 s = 2 starred
 s = 3 solid
and "n" is a the number of sides the polygon has. For example:
 PTYPE 4 0
creates open squares whereas
 PTYPE 4 1
creatse X-like symbol. Btw. I like those unfilled symbols because you
can plot lots of them without overcrowding your figure.
It is also possible to use
 PTYPE 0 0
which draws the smalles possible dots on a device, i.e. a single pixel
on a screen; this can also be very helpful if you want to plot lots of
datapoints.
One can also use an angle argument, e.g. transform a 'X' symbol to an
'+' symbol by rotation it about 45 degrees.
Is it possible to integrate a similar way to create custom symbols in
matplotlib? Probably something like
 verts = PolyMarker(n=4,s='open',angle=0)
would be nice. Or, if I write something like this myself, is there any
chance to add this to matplotlib ?
Manuel

It builds now. We still have to wait on a useable numpy for python2.5
and pygtk for windows/py2.5. All the other components are there or we
can build.
On 9/20/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
> Charlie> This came up on the dev list yesterday and we tried with
> Charlie> swig-1.3.29, which is the latest listed release on SF.
> Charlie> The link you provided shows this was indeed fixed after
> Charlie> the 1.3.29 release. Jon, can we give bleeding edge swig
> Charlie> a try?
>
> OK, bleeding edge SWIG versions of the agg wrappers are in svn.
>
> Good luck!
>
> JDH
>

Hi,
I sent this message to the list this time yesterday and it doesn't seem 
to have either arrived or bounced - so I'm trying again.
I've written a patch (attached) to allow the PS backend to respect the
dpi that's given to the FigureCanvasPS on initialisation when saving
images. The solution I came with to do this isn't the nicest, but I
couldn't see any significantly different way to do it without changing
the rendering process for images.
What I've done is add a get_image_magnification method to the default
backend with a default return value of 1.0. This magnification factor
is then taken by the draw method of the figure, axes or image and passed
as a keyword argument to the make_image method of the image where it
used to scale the widthDisplay and heightDisplay returned from the
bounding box. (I also changed the self.make_image(False) call in
Image.write_png to self.make_image() as I'm pretty sure that's what was
meant to be - and if I hadn't the introduction of my new keyword
argument would have resulted in a zero size image.)
By returning a magnification of dpi/72.0, the PS backend is able to
instruct the image instances to create larger images which it then
scales by an appropriate value on output to give the requested dpi.
This patch, or something like it, is vital for me at the moment because
the low 72 dpi output used by matplotlib at the moment gives rise to
some fairly significant distortion to my results. I imagine others will
come across the same problem.
I hope this patch is useful,
Nicholas Young

On 9/19/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
> Charlie> Could someone please regenerated the swig wrappings with
> Charlie> swig-1.3.29 instead of swig-1.3.27 and commit?
>
> I just did this -- give it a test drive.
It still appears. Googling the error leads me to this post:
http://permalink.gmane.org/gmane.comp.programming.swig/8498
I don't have a linux machine handy at the moment to try this stuff. I
don't want to mess with swig on windows either. There probably isn't
a rush on this since numpy doesn't compile under 2.5 yet anyway.