matplotlib-users Mailing List for matplotlib

On Jul 2, 2010, at 2:15 PM, Nicolas Bigaouette wrote:
> Hi all,
>
> I don't really know where to ask, so here it is.
>
> I was able to vectorize the normalization calculation in quantum 
> mechanics: <phi|phi>. Basically it's a volume integral of a scalar 
> field. Using:
> norm = 0.0
> for i in numpy.arange(len(dx)-1):
> for j in numpy.arange(len(dy)-1):
> for k in numpy.arange(len(dz)-1):
> norm += psi[k,j,i]**2 * dx[i] * dy[j] * dz[k]
> if dead slow. I replaced that with:
> norm = (psi**2 * dx*dy[:,numpy.newaxis]*dz 
> [:,numpy.newaxis,numpy.newaxis]).sum()
> which is almost instantanious.
>
> I want to do the same for the calculation of the kinetic energy: 
> <phi|p^2|phi>/2m. There is a laplacian in the volume integral which 
> complicates things:
> K = 0.0
> for i in numpy.arange(len(dx)-1):
> for j in numpy.arange(len(dy)-1):
> for k in numpy.arange(len(dz)-1):
> K += -0.5 * m * phi[k,j,i] * (
> (phi[k,j,i-1] - 2.0*phi[k,j,i] + phi[k,j,i+1]) / 
> dx[i]**2
> + (phi[k,j-1,i] - 2.0*phi[k,j,i] + phi[k,j+1,i]) / 
> dy[j]**2
> + (phi[k-1,j,i] - 2.0*phi[k,j,i] + phi[k+1,j,i]) / 
> dz[k]**2
> )
>
> My question is, how would I vectorize such loops? I don't know how 
> I would manage the "numpy.newaxis" code-foo with neighbours 
> dependency... Any idea?
>
I would first create a 3d array of the integrand, probably using 
scipy.signal.convolve to convolve phi with a kernel such as
[[[0,0,0],[0,1,0],[0,0,0]],
 [[0,1,0],[1,-6,1],[0,1,0]],
 [[0,0,0],[0,1,0],[0,0,0]]]
Then just multiply by whatever factors of dx, dy, dz, and m, and sum 
the 3d integrand. If dx,dy,dz are non-uniform, it is a harder problem...
Hope that helps,
-Jeff
P.S. Careful, the code you wrote will multiply by the mass instead of 
dividing by it.

Hi all,
I don't really know where to ask, so here it is.
I was able to vectorize the normalization calculation in quantum mechanics:
<phi|phi>. Basically it's a volume integral of a scalar field. Using:
> norm = 0.0
> for i in numpy.arange(len(dx)-1):
> for j in numpy.arange(len(dy)-1):
> for k in numpy.arange(len(dz)-1):
> norm += psi[k,j,i]**2 * dx[i] * dy[j] * dz[k]
>
if dead slow. I replaced that with:
> norm = (psi**2 *
> dx*dy[:,numpy.newaxis]*dz[:,numpy.newaxis,numpy.newaxis]).sum()
>
which is almost instantanious.
I want to do the same for the calculation of the kinetic energy:
<phi|p^2|phi>/2m. There is a laplacian in the volume integral which
complicates things:
> K = 0.0
> for i in numpy.arange(len(dx)-1):
> for j in numpy.arange(len(dy)-1):
> for k in numpy.arange(len(dz)-1):
> K += -0.5 * m * phi[k,j,i] * (
> (phi[k,j,i-1] - 2.0*phi[k,j,i] + phi[k,j,i+1]) / dx[i]**2
> + (phi[k,j-1,i] - 2.0*phi[k,j,i] + phi[k,j+1,i]) / dy[j]**2
> + (phi[k-1,j,i] - 2.0*phi[k,j,i] + phi[k+1,j,i]) / dz[k]**2
> )
>
My question is, how would I vectorize such loops? I don't know how I would
manage the "numpy.newaxis" code-foo with neighbours dependency... Any idea?
Thanx!

On Tue, Jun 29, 2010 at 8:25 AM, John Hunter <jd...@gm...> wrote:
> This issue is new and not related to the issue on the cookbook, I'm
> pretty sure. I have the same problem on my box at work, and it was
> introduced when I upgraded to CXX6. I have spent some time on it but
> haven't found the fix yet. I guess it's my bug :-(
>
> I've added it to the tracker:
>
> https://sourceforge.net/tracker/?func=detail&aid=3022815&group_id=80706&atid=560720
>
I have a fix in that appears to work. Comments from the tracker
below. If anyone sees a problem with my fix, let me know::
The CXX/WrapPython.h header has the following code to deal with the swab
issue
// Prevent multiple conflicting definitions of swab from stdlib.h and
unistd.h
#if defined(__sun) || defined(sun)
#if defined(_XPG4)
#undef _XPG4
#endif
#endif
See
http://cxx.svn.sourceforge.net/viewvc/cxx/trunk/CXX/CXX/WrapPython.h?revision=198&content-type=text%2Fplain
The header of stdlib.h on the sage tracker and on my solaris system say
this:
/*
* swab() has historically been in <stdlib.h> as delivered from AT&T
* and continues to be visible in the default compilation environment.
* As of Issue 4 of the X/Open Portability Guides, swab() was declared
* in <unistd.h>. As a result, with respect to X/Open namespace the
* swab() declaration in this header is only visible for the XPG3
* environment.
*/
Ie, the swab declaration is visible for the XPG3 environment but
WrapperPython.h is only unsetting XPG$. The proposed fix is to also unset
XPG3 in this environment. I don't pfully understand all these macros, but
this seems consistent with the comments in stdlib and with what WrapPython
is trying to do, and it works (mpl compiles and passes tests).
So I am committing the following change to mpl's CXX (this should also be
pushed upstream into CXX where we might get better feedback on whether this
change is indeed correct).
// Prevent multiple conflicting definitions of swab from stdlib.h and
unistd.h
#if defined(__sun) || defined(sun)
#if defined(_XPG4)
#undef _XPG4
#endif
#if defined(_XPG3)
#undef _XPG3
#endif
#endif
JDH

On Fri, Jul 2, 2010 at 12:10 PM, Christoph Gohlke <cg...@uc...> wrote:
> The second enhancement, a quick fix for placing images of extreme aspect
> ratio, is to allow 'panchor' and 'fraction' arguments in colorbar().
> http://sourceforge.net/tracker/?func=detail&aid=3016948&group_id=80706&atid=560723
I assigned this patch to me -- my only request is that you also update
the appropriate docstrings so it is clear that these keywords can be
passed in and what they mean.

On Fri, Jul 2, 2010 at 12:10 PM, Christoph Gohlke <cg...@uc...> wrote:
> Hello,
>
> may I suggest two enhancements for the upcoming matplotlib 1.0 release.
>
> The first is related to bug #3011650 and fix r8379.
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=8379
>
> Texmanager.py, which is imported during the import of matplotlib, does call
> subprocess.Popen('dvipng'...) on every import. This can significantly add to
> the startup time of scripts. Given that most scripts don't use TeX, can the
> Popen() call be deferred to runtime? On my system (Python 2.6 for Windows,
> mpl 1.0rc1, MiKTeX 2.8) the 'backend_driver.py agg' tests are run about 8%
> (20s) faster with the following patch.
>
> Index: lib/matplotlib/texmanager.py
> ===================================================================
> --- lib/matplotlib/texmanager.py    (revision 8481)
> +++ lib/matplotlib/texmanager.py    (working copy)
> @@ -91,7 +91,7 @@
>   if not os.path.exists(texcache):
>     os.mkdir(texcache)
>
> -  _dvipng_hack_alpha = dvipng_hack_alpha()
> +  _dvipng_hack_alpha = None
>
>   # mappable cache of
>   rgba_arrayd = {}
> @@ -516,6 +516,8 @@
>       if rcParams['text.dvipnghack'] is not None:
>         hack = rcParams['text.dvipnghack']
>       else:
> +        if self._dvipng_hack_alpha is None:
> +          self._dvipng_hack_alpha = dvipng_hack_alpha()
>         hack = self._dvipng_hack_alpha
>
>       if hack:
>
patch 1 is entirely reasonable and harmless so I committed it to trunk
JDH

Hello,
may I suggest two enhancements for the upcoming matplotlib 1.0 release.
The first is related to bug #3011650 and fix r8379.
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=8379
Texmanager.py, which is imported during the import of matplotlib, does 
call subprocess.Popen('dvipng'...) on every import. This can 
significantly add to the startup time of scripts. Given that most 
scripts don't use TeX, can the Popen() call be deferred to runtime? On 
my system (Python 2.6 for Windows, mpl 1.0rc1, MiKTeX 2.8) the 
'backend_driver.py agg' tests are run about 8% (20s) faster with the 
following patch.
Index: lib/matplotlib/texmanager.py
===================================================================
--- lib/matplotlib/texmanager.py (revision 8481)
+++ lib/matplotlib/texmanager.py (working copy)
@@ -91,7 +91,7 @@
 if not os.path.exists(texcache):
 os.mkdir(texcache)
- _dvipng_hack_alpha = dvipng_hack_alpha()
+ _dvipng_hack_alpha = None
 # mappable cache of
 rgba_arrayd = {}
@@ -516,6 +516,8 @@
 if rcParams['text.dvipnghack'] is not None:
 hack = rcParams['text.dvipnghack']
 else:
+ if self._dvipng_hack_alpha is None:
+ self._dvipng_hack_alpha = dvipng_hack_alpha()
 hack = self._dvipng_hack_alpha
 if hack:
The second enhancement, a quick fix for placing images of extreme aspect 
ratio, is to allow 'panchor' and 'fraction' arguments in colorbar().
http://sourceforge.net/tracker/?func=detail&aid=3016948&group_id=80706&atid=560723
Thanks,
Christoph

On Jul 2, 2010, at 7:43 AM, John Hunter wrote:
> On Thu, Jul 1, 2010 at 6:17 PM, Russell E. Owen <ro...@uw...> wrote:
> 
>> matplotlib-0.99.3-Apple-py2.6-macosx10.6.dmg
>> for your existing binary, and
>> matplotlib-0.99.3-python-py2.5-macosx10.4.dmg
>> matplotlib-0.99.3-python-py2.6-macosx10.4.dmg
> 
> OK, this is done. Thanks for the builds and naming suggestions. Do
> you think we should replace the eggs on the site with your builds and
> names as well, and importantly, if so, are you able to build them? My
> OSX builds were initially curtailed when my powerbook died. William
> Stein and the sage project gave me remote access to one of their OSX
> build boxes and that was working for a while but then they upgraded to
> 10.6 64bit and that broke the build environment again for a while and
> I don't have an easy way to configure that machine with the various
> builds of python and associated tools that I need. In short, I am not
> the best person to do the OSX builds and am wondering if you would be
> interested in doing the OSX binaries for upcoming releases. We are
> working to get 1.0 out ASAP -- possibly over the weekend or early next
> week depending on our efforts to quash a couple of remaining bugs.
> Would you be able to do the OSX binary builds for 1.0 too?
> 
> Thanks,
> JDH
I would be happy to make the Mac binary builds for matplotlib (at least the ones I know how to make -- for python.org 32-bit).
I personally suggest not building Mac eggs -- at least until easy_install gets really cleaned up. Right now it tends to try to download stuff it has no business downloading and it doesn't check for compatibility. The binary installer is much safer. But if you insist and have easy instructions I will do it.
I suspect I didn't fully answer your question, but I'm not sure what else you want to know so I'll ask you to rephrase any remaining issues.
I'm a bit worried about what will happen when I eventually upgrade my work computer to 10.6 (it's our last remaining 10.5 machine at the moment). But since I have ready access to 10.6 computers I should see if I can do a working build on 10.6 with the binaries I already created on 10.5. (That is likely to work, and may save a lot of trouble -- at least until those versions of libfreetype, etc. get old enough to need upgrading). I don't see myself going to 64-bit for a long time since I have to keep my work machine as compatible as possible.
It is very exciting to hear that matplotlib 1.0 is so close.
Regards,
-- Russell

On Fri, Jul 2, 2010 at 10:34 AM, Russell Owen <ro...@uw...> wrote:
> I would be happy to make the Mac binary builds for matplotlib (at least the ones I know how to make -- for python.org 32-bit).
>
> I personally suggest not building Mac eggs -- at least until easy_install gets really cleaned up. Right now it tends to try to download stuff it has no business downloading and it doesn't check for compatibility. The binary installer is much safer. But if you insist and have easy instructions I will do it.
>
I won't insist -- I have personally found eggs are more trouble than
their worth. Others may ask for them, so we can deal with this on as
as needed basis.
> I suspect I didn't fully answer your question, but I'm not sure what else you want to know so I'll ask you to rephrase any remaining issues.
>
You answered my two questions: should we build eggs (no) and will you
do the builds (yes). Perfect.
> I'm a bit worried about what will happen when I eventually upgrade my work computer to 10.6 (it's our last remaining 10.5 machine at the moment). But since I have ready access to 10.6 computers I should see if I can do a working build on 10.6 with the binaries I already created on 10.5. (That is likely to work, and may save a lot of trouble -- at least until those versions of libfreetype, etc. get old enough to need upgrading). I don't see myself going to 64-bit for a long time since I have to keep my work machine as compatible as possible.
>
If need be, perhaps I can do the 10.6 64 bit binaries on the sage
machine. I just need to figure out the apple python vs python.org
python problem on that platform.
> It is very exciting to hear that matplotlib 1.0 is so close.
Yep -- long time coming :-)
Thanks for your help,
JDH

On Fri, Jul 2, 2010 at 6:20 AM, ninjasmith <hen...@gm...> wrote:
> ok made some prgoress with this so thought I'd update
>
> the following script works on widnows
>
> '''
> Created on Jul 1, 2010
>
> @author: henrylindsaysmith
> '''
> # $Id: $
>
> #test interactive matplotlib plotting
>
> import threading
> import numpy as np
> import sys
> import matplotlib
> matplotlib.use('TkAgg')
> import matplotlib.pylab as pyp
>
>
> class MyThread(threading.Thread):
>
>  def __init__ (self, data, label):
>    self.data = data
>    self.label = label
>    threading.Thread.__init__ ( self )
>
>  def run(self):
>    pyp.plot(self.data)
>    pyp.xlabel('%s' % self.label)
>    pyp.show()
>
> a = np.array([0, 4, 5, 5, 3, 4, 5])
> MyThread(a,'first x label').start()
> print ("please input x label")
> input = sys.stdin.readline()
> MyThread(a,input).start()
>
>
> so basically abandoning interactive mode and running in a thread works. the
> first show shows the plot which I can then interact with. After I input
> from the keyboard the second plot updates the figure.
>
> BUT
>
> on mac I get the following errors
>
> 1) the figure window appears but has no content
> 2) after the keyboard input the xlabel updates and the figure content
> displays and I get the following error
>
> Exception in thread Thread-2:
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py",
> line 525, in __bootstrap_inner
>  self.run()
> File "threadedMatplotLIb.py", line 28, in run
>  pyp.show()
> File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/backends/backend_tkagg.py",
> line 79, in show
>  Tk.mainloop()
> File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py",
> line 325, in mainloop
>  _default_root.tk.mainloop(n)
> RuntimeError: Calling Tcl from different appartment
>
> I tried the backend macosx and the results were worse!! I'd rather use mac
> if I can due to scikits.audiolab not installing in windows.
>
> anyone shed any lights on the thread problem?
A lot of GUI toolkits don't permit multi-threaded access to their
event loops. What you really want is to integrate your interaction
into that loop itself, so that the GUI handles things for you. Try
looking at the examples here:
http://matplotlib.sourceforge.net/examples/event_handling/
Specifically:
http://matplotlib.sourceforge.net/examples/event_handling/keypress_demo.html
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Jul 1, 2010 at 6:17 PM, Russell E. Owen <ro...@uw...> wrote:
> matplotlib-0.99.3-Apple-py2.6-macosx10.6.dmg
> for your existing binary, and
> matplotlib-0.99.3-python-py2.5-macosx10.4.dmg
> matplotlib-0.99.3-python-py2.6-macosx10.4.dmg
OK, this is done. Thanks for the builds and naming suggestions. Do
you think we should replace the eggs on the site with your builds and
names as well, and importantly, if so, are you able to build them? My
OSX builds were initially curtailed when my powerbook died. William
Stein and the sage project gave me remote access to one of their OSX
build boxes and that was working for a while but then they upgraded to
10.6 64bit and that broke the build environment again for a while and
I don't have an easy way to configure that machine with the various
builds of python and associated tools that I need. In short, I am not
the best person to do the OSX builds and am wondering if you would be
interested in doing the OSX binaries for upcoming releases. We are
working to get 1.0 out ASAP -- possibly over the weekend or early next
week depending on our efforts to quash a couple of remaining bugs.
Would you be able to do the OSX binary builds for 1.0 too?
Thanks,
JDH

Hello
I am trying to change the font of the ticklabels, this does not work the
'normal' rc-way, so what I did was (example):
import matplotlib.pyplot as pl
ffont={'family' : 'sans-serif', 'sans-serif' : ['Arial'], 'size' : 15,
'weight' : 'bold'}
fig = pl.figure(1)
ax = fig.add_subplot(111)
ax.set_xticklabels(ax.get_xticks(),ffont)
ax.plot([1,2,3])
pl.show()
pl.draw()
when I run this and in the figure pan/zoom the plot the ticklabels does not
change (?), the ticks move, but the labels jump to be in the same place.
What am I doing wrong?
Cheers,
Magnus
-- 
View this message in context: http://old.nabble.com/Formatted-ticklabels-going-haywire--tp29056856p29056856.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

> ipython does this, I believe, when you call it with the -pylab option, but
I have never tried it with a script.
Ben Root
ok made some prgoress with this so thought I'd update
the following script works on widnows
'''
Created on Jul 1, 2010
@author: henrylindsaysmith
'''
# $Id: $
#test interactive matplotlib plotting
import threading
import numpy as np
import sys
import matplotlib
matplotlib.use('TkAgg')
import matplotlib.pylab as pyp
class MyThread(threading.Thread):
 
 def __init__ (self, data, label):
 self.data = data
 self.label = label
 threading.Thread.__init__ ( self )
 
 def run(self):
 pyp.plot(self.data)
 pyp.xlabel('%s' % self.label)
	pyp.show()
a = np.array([0, 4, 5, 5, 3, 4, 5])
MyThread(a,'first x label').start()
print ("please input x label")
input = sys.stdin.readline()
MyThread(a,input).start()
so basically abandoning interactive mode and running in a thread works. the
first show shows the plot which I can then interact with. After I input
from the keyboard the second plot updates the figure.
BUT
on mac I get the following errors
1) the figure window appears but has no content
2) after the keyboard input the xlabel updates and the figure content
displays and I get the following error
Exception in thread Thread-2:
Traceback (most recent call last):
 File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py",
line 525, in __bootstrap_inner
 self.run()
 File "threadedMatplotLIb.py", line 28, in run
 pyp.show()
 File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/matplotlib/backends/backend_tkagg.py",
line 79, in show
 Tk.mainloop()
 File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py",
line 325, in mainloop
 _default_root.tk.mainloop(n)
RuntimeError: Calling Tcl from different appartment
I tried the backend macosx and the results were worse!! I'd rather use mac
if I can due to scikits.audiolab not installing in windows.
anyone shed any lights on the thread problem?
 
 
-- 
View this message in context: http://old.nabble.com/matplotlib-in-interactive-mode-from-a-script-tp29023641p29055179.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi all,
On Tue, Jun 29, 2010 at 22:36, John Hunter <jd...@gm...> wrote:
> We have uploaded a tarball and Windows and OSX binaries of
> matplotlib-1.0rc for testing
>
> http://drop.io/xortel1#
I just prepared the Debian package for 1.0rc1 and it went quite
smoothly. I gave it a fast test rebuilding all the images of my book,
and they all renders good (also, the conturf() problem that colored
zones with a bit of overlapping is finally gone).
The package still needs a bit of work, and probably I'll upload next
week to our "experimental" branch (so, at least for now, it won't be
targetting the next Debian stable release).
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Yadin Bocuma Rivas te ha dejado un mensaje...
El mensaje y la persona que lo envió solo te será mostrado a ti y borrarlo en cualquier momento. Puedes responder a través del sistema de intercambio de mensajes. Para descubrir quién te escribió, sigue el siguiente link:
http://eu1.badoo.com/0175921239/in/rsb1Fn-PxvA/?lang_id=7
Más gente que también te está esperando:
Mike (Larnaca, Chipre)
Nena (Malabo, Guinea Ecuatorial)
Manolin (Malabo, Guinea Ecuatorial)
http://eu1.badoo.com/0175921239/in/rsb1Fn-PxvA/?lang_id=7
Si al pulsar el enlace de este mensaje no funciona, copia y pégalo en la barra de tu navegador.
Este email es parte del procedimiento del sistema para el envío de mensajes enviados por Yadin Bocuma Rivas. Si has recibido este mensaje por error, ignora este email. Tras un corto periodo de tiempo, será eliminado del sistema.
¡Divértete!
El equipo de Badoo
Has recibido este email porque un usuario de Badoo te ha dejado un mensaje en Badoo. Este mensaje es automático. Las respuestas a este mensaje no estan controladas y no serán contestadas. Si no quieres recibir más mensajes de Badoo, háznoslo saber:
http://eu1.badoo.com/impersonation.phtml?lang_id=7&mail_code=21&email=matplotlib-users%40lists.sourceforge.net&secret=&invite_id=473679&user_id=175921239 

On Thu, Jul 1, 2010 at 10:42 AM, ninjasmith <hen...@gm...>wrote:
>
>
>
> >
> > Hi,
> >
> > I think what you are after is the interactive mode of matplotlib. You can
> > turn
> > is on by "ion" and redraw the current figure using "draw". In ipythons
> > "pylab"
> > mode this is done implicit. I attached some example lines which guide you
> > to
> > the right direction. I'm not sure why I need two draws in my attached
> > script,
> > but at least it seems to do the job.
> > For more infos you may visit:
> >
> http://matplotlib.sourceforge.net/users/shell.html#controlling-interactive-
> > updating
> >
> > Kind regards,
> > Matthias
> >
> >
> > import numpy as np
> > import sys
> > import matplotlib.pylab as pyp
> >
> > a = np.array([0, 4, 5, 5, 3, 4, 5])
> > pyp.ion()
> > pyp.figure()
> > pyp.plot(a)
> > pyp.draw()
> > pyp.draw()
> >
> > input = sys.stdin.readline()
> > print "input 1 : %s " % (input)
> > pyp.xlabel('my xlabel %s' % input)
> > pyp.draw()
> > pyp.draw()
> >
> > input = sys.stdin.readline()
> > print "input 2 : %s " % (input)
> >
> > pyp.ioff()
> > pyp.show()
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
>
> that almost fixes it. I can now plot and re draw during the execution of
> my
> script. However I cannot interact with the plots. i.e. I can't zoom in on
> an area. when the script gets to the point where pyp.show() is called then
> I'm able to do this. I'm thinking there may be no way round this?
>
> or is there some way to run matplot lib plot in a different thread?
>
>
> ipython does this, I believe, when you call it with the -pylab option, but
I have never tried it with a script.
Ben Root