Jeremy Martin wrote:
List,
Im new to using Scipy and was wondering where to look for documentation on gplot. Ive looked at the gnuplot webpage but havent found any sections that resemble the functions in the plotting tutorial.
With no offense to the core scipy team (I'm an avid user of scipy for all my work _except_ plotting), I think you'd be better served right now with another alternative. Scipy has been slowly developing a very ambitious graphics framework called Chaco, but the project isn't really useful to end users yet. I personally have been using Gnuplot.py (with the additions provided by ipython, which IMHO are absolutely critical to real-world efficient use, especially interactively). But I have been keeping a close eye on matplotlib, and with the latest release (from this past Monday), I think it passed a turning point in usability. Now, I've started promoting it to my coworkers who didn't have tons of gnuplot-based scripts like I do. I will probably transition more slowly, but I'm already working on giving ipython gtk-threading support so it integrates nicely with all of matplotlib's backends. In case you are curious, the key additions to matplotlib which just made it pass _my_ criteria were: 1. Mathtext (latex equations) support in the PS/EPS backend. This is absolutely critical for our regular latex-based workflow. 2. Zooming/panning in the interactive plot windows. I pestered John to add to matplotlib these features in the manner which gnuplot 4.0 supports (I use them constantly, and they are critical to my daily workflow). He was extremely receptive to all my suggestions, and they were available in short order. I _really_ like matplotlib, because it provides today a system which matches the various usage scenarios I need: - concise, efficient syntax for quick interactive use. One-off plots of data when developing code, where you need zero fancy features, but you need to do them quickly and with the _absolute_ minimum amount of typing possible. plot(x) should simply plot the x array against its indices. - a real object-oriented framework for more complex things where the plots are generated by a program. There, extreme conciseness is not the key feature. Instead, a clean object model with programmatic access to all parts of the graph is critical. - the ability to plot either to screen or to generate many plots to eps on disk without ever opening a gui. I have automated test suites which need to run without opening a plotting window, but make many plots as they go. - the same library also exposes its functionality as widgets for wxpython. This means that making a gui program which needs sophisticated plotting is not a problem anymore (that's simply impossible with gnuplot, which was never conceived for such purposes). Besides, it has: - easy generation of all common image formats - array plotting as colormaps. For image processing and even a lot of linear algebra things, this is very useful and non-existent in gnuplot (I think there are patches around for it, but it's not in mainline). Matplotlib still has a few rough edges, but it's improving steadily and I see the overall foundations as being solid enough, that I'm willing to bet my own time by working on ipython support for it. I think that the following trio of systems makes an extremely good base for the graphical side of scientific work today in python: - Matplotlib: regular 2d plots (interactive or scripted), array/image plots, gui-building. - MayaVi: sophisticated 3d visualization, volumetric rendering, etc. - PyX: algorithmic generation of high-quality postscript diagrams with latex equations. Replacing matplotlib with gnuplot at this moment, I have incorporated these tools into fairly complex codes in a very smooth way. After having fought the hell of IDL (matlab is probably similar), the power these tools provide, and their simplicity and elegance, are really a pleasure. I hope this is useful. Best, f
On Sat, 14 Aug 2004, Fernando Perez apparently wrote:
I think that the following trio of systems makes an extremely good base for the graphical side of scientific work today in python: - Matplotlib: regular 2d plots (interactive or scripted), array/image plots, gui-building. - MayaVi: sophisticated 3d visualization, volumetric rendering, etc. - PyX: algorithmic generation of high-quality postscript diagrams with latex equations.
This post was extremely useful. One ambiguity remained for me: are you suggested PyX remains better than Matplotlib if you need LaTeX equations in your EPS files? Thank you, Alan Isaac
"Alan" == Alan G Isaac <aisaac@american.edu> writes:
Alan> This post was extremely useful. One ambiguity remained for Alan> me: are you suggested PyX remains better than Matplotlib if Alan> you need LaTeX equations in your EPS files? matplotlib and pyx take different approaches to mathtext. PyX uses TeX to typeset the mathematical expressions, and so by definition has full TeX support and awesome rendering. matplotlib uses a custom parser and layout engine, and does not support the full range of TeX expressions (eg there is no \frac command yet). Also, TeX does superior layout - I don't pretend to be Donald Knuth, nor did I spend 10 years working on it :-) So if you need the full power of TeX, only need ps/eps output, and have access to a TeX install on all the platforms on which you work, PyX will be the better choice. What matplotlib offers vis-a-vis mathtext that pyx doesn't is * totally self contained solution - no extra packages required. Cross platform, etc. * mathtext for non-PS outputs (PNG, GUI window) in addition to PS/EPS. Thus you can use mathtext anywhere in your figure in any GTK/WX/Tkinter/FLTK application or save it to hardcopy PNG, eg for a powerpoint presentation. matplotlib uses the computer modern fonts, so the equations will look very similar to TeX equations. And while there is nothing like full TeX support, there is nonetheless substantial support: almost all of the TeX symbols, over/under subscripting with {} groups, fonts, ... see http://matplotlib.sourceforge.net/matplotlib.mathtext.html for more info. Hope this helps, JDH
On Sun, 15 Aug 2004, John Hunter apparently wrote:
So if you need the full power of TeX, only need ps/eps output, and have access to a TeX install on all the platforms on which you work, PyX will be the better choice.
What matplotlib offers vis-a-vis mathtext that pyx doesn't is * totally self contained solution - no extra packages required. Cross platform, etc. * mathtext for non-PS outputs (PNG, GUI window) in addition to PS/EPS. Thus you can use mathtext anywhere in your figure in any GTK/WX/Tkinter/FLTK application or save it to hardcopy PNG, eg for a powerpoint presentation.
matplotlib uses the computer modern fonts, so the equations will look very similar to TeX equations. And while there is nothing like full TeX support, there is nonetheless substantial support: almost all of the TeX symbols, over/under subscripting with {} groups, fonts, ... see http://matplotlib.sourceforge.net/matplotlib.mathtext.html for more info.
Very helpful! I've decide to give matplotlib a try. I probably should note that the earlier discussion showing that matplotlib allows an object oriented approach to plot generation was important to this decision. Thanks, Alan Isaac
"Alan" == Alan G Isaac <aisaac@american.edu> writes:
Alan> Very helpful! I've decide to give matplotlib a try. I Alan> probably should note that the earlier discussion showing Alan> that matplotlib allows an object oriented approach to plot Alan> generation was important to this decision. Great! Thanks for letting me know - I'll be sure to emphasize the OO usage in the users guide, which I'm hoping to have it ready by SciPy. We shall see... JDH
Hi all If someone happens to use Mark Rivers' mpfit (http://cars.uchicago.edu/software) for (constrained) Levenberg-Marquardt fitting instead of scipy.optimize.leastsq (both are based on MINPACK) there is a bug regarding 'mpmaxstep' (set the max iteration step length): around line 930 it reads wh = Numeric.nonzero((qmin!=0.) & (qmax!=0.)) but should rather be something like wh = Numeric.nonzero((qmax!=0.)) Maybe this helps someone to save a _lot_ of time wondering why nothing happens :) bye steve -- If you can't beat your computer at chess, try kickboxing. -- Superg�nstige DSL-Tarife + WLAN-Router f�r 0,- EUR* Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl
Hi In addition line 1186 seems also to be incorrect: mrat = max(Numeric.take(nwa1, whmax) / Numeric.take(maxstep, whmax)) I changed it to mrat = max(abs(Numeric.take(nwa1, whmax)) / abs(Numeric.take(maxstep, whmax))) The latter version also works for negative parameter changes (towards the lower limit). bye steve -- If you can't beat your computer at chess, try kickboxing. -- NEU: Bis zu 10 GB Speicher f�r e-mails & Dateien! 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail
Hi all, There is a critical bug in scipy, about *very* basic operations between arrays, under MS Windows. Here's the facts : import scipy a=scipy.arange( N, typecode='F' ) c=a*a crashes with N = 258168. The same code does not crash for N = 258167. So 258168 is a kind of limit, because for any lower value, it is OK. This is no memory problem (258168 is not a big value and I have 512 Mb RAM !-). Moreover, if I change scipy for Numeric, the problem disappears ! Also, the interpreter crashes with no error message at all, as if some 'exit()' code was encountered somewhere. What's going on ? How to solve this ? To me it is a very important bug. We can deal on this list about the color of graphics or about some weird special function... but here we're dealing about the integrity of simple computations. Could the readers of this mail try the code on their windows box and tell me if they can reproduce the bug. Any idea to overcome this problem, or just a hint is welcome, because I'm completely stuck !!!!! Thanks in advance, C. Grimault
On Mon, 30 Aug 2004, christophe grimault apparently wrote:
import scipy a=scipy.arange( N, typecode='F' ) c=a*a crashes with N = 258168. The same code does not crash for N = 258167. Could the readers of this mail try the code on their windows box and tell me if they can reproduce the bug.
Confirmed: crash in Scipy, no crash in Numeric. Cheers, Alan Isaac
Alan G Isaac wrote:
On Mon, 30 Aug 2004, christophe grimault apparently wrote:
import scipy a=scipy.arange( N, typecode='F' ) c=a*a crashes with N = 258168. The same code does not crash for N = 258167. Could the readers of this mail try the code on their windows box and tell me if they can reproduce the bug.
Confirmed: crash in Scipy, no crash in Numeric.
Cheers, Alan Isaac
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
BTW, it works fine on Linux Python 2.3.3 (#1, Apr 6 2004, 01:47:39) [GCC 3.3.3 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import scipy scipy.__version__ '0.3.1_283.4228' N = 258168 a=scipy.arange( N, typecode='F' ) c = a*a
Nils
Thanks for the test on Linux. I already knew this however, because I'm porting an application from Linux to Windows. That's why I came across this annoying bug. It is true that everything works fine on linux. So what is different in scipy-linux from scipy windows ? Because I don't believe that the problem is in python (2.3 BTW), nor in Numeric ... Nils Wagner wrote:
Alan G Isaac wrote:
On Mon, 30 Aug 2004, christophe grimault apparently wrote:
import scipy a=scipy.arange( N, typecode='F' ) c=a*a crashes with N = 258168. The same code does not crash for N = 258167. Could the readers of this mail try the code on their windows box and tell me if they can reproduce the bug.
Confirmed: crash in Scipy, no crash in Numeric.
Cheers, Alan Isaac
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
BTW, it works fine on Linux
Python 2.3.3 (#1, Apr 6 2004, 01:47:39) [GCC 3.3.3 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import scipy scipy.__version__ '0.3.1_283.4228' N = 258168 a=scipy.arange( N, typecode='F' ) c = a*a
Nils
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
christophe grimault wrote:
Thanks for the test on Linux. I already knew this however, because I'm porting an application from Linux to Windows. That's why I came across this annoying bug.
It is true that everything works fine on linux. So what is different in scipy-linux from scipy windows ? Because I don't believe that the problem is in python (2.3 BTW), nor in Numeric ...
How about your scipy version ? Nils
Nils Wagner wrote:
Alan G Isaac wrote:
On Mon, 30 Aug 2004, christophe grimault apparently wrote:
import scipy a=scipy.arange( N, typecode='F' ) c=a*a crashes with N = 258168. The same code does not crash for N = 258167. Could the readers of this mail try the code on their windows box and tell me if they can reproduce the bug.
Confirmed: crash in Scipy, no crash in Numeric.
Cheers, Alan Isaac
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
BTW, it works fine on Linux
Python 2.3.3 (#1, Apr 6 2004, 01:47:39) [GCC 3.3.3 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import scipy scipy.__version__ '0.3.1_283.4228' N = 258168 a=scipy.arange( N, typecode='F' ) c = a*a
Nils
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
-- Dr.-Ing. Nils Wagner Institut A für Mechanik Universität Stuttgart Pfaffenwaldring 9 D-70550 Stuttgart Tel.: (+49) 0711 685 6262 Fax.: (+49) 0711 685 6282 E-mail: nwagner@mecha.uni-stuttgart.de
My version number is 0.3.0_266.4242 Nils Wagner wrote:
christophe grimault wrote:
Thanks for the test on Linux. I already knew this however, because I'm porting an application from Linux to Windows. That's why I came across this annoying bug.
It is true that everything works fine on linux. So what is different in scipy-linux from scipy windows ? Because I don't believe that the problem is in python (2.3 BTW), nor in Numeric ...
How about your scipy version ?
Nils
Nils Wagner wrote:
Alan G Isaac wrote:
On Mon, 30 Aug 2004, christophe grimault apparently wrote:
import scipy a=scipy.arange( N, typecode='F' ) c=a*a crashes with N = 258168. The same code does not crash for N = 258167. Could the readers of this mail try the code on their windows box and tell me if they can reproduce the bug.
Confirmed: crash in Scipy, no crash in Numeric.
Cheers, Alan Isaac
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
BTW, it works fine on Linux
Python 2.3.3 (#1, Apr 6 2004, 01:47:39) [GCC 3.3.3 (SuSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import scipy scipy.__version__ '0.3.1_283.4228' N = 258168 a=scipy.arange( N, typecode='F' ) c = a*a
Nils
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
On Mon, 30 Aug 2004, Nils Wagner apparently wrote:
'0.3.1_283.4228'
Could be. I've got '0.3.0_266.4242' Can I just install the update, if available for Windoes, over the previous installation? Thanks, Alan Isaac
Do you think that there is change in the CVS version, from 0.3.0_266.4242 to 0.3.1_283.422, that could explain this ? If someone using the latest version (0.3.1_283.422) could try to reproduce the bug (with the 3 lines just below), and tell me about it, it would be helpfull ... Thanks in advance, christophe grimault wrote:
Hi all,
There is a critical bug in scipy, about *very* basic operations between arrays, under MS Windows. Here's the facts :
import scipy a=scipy.arange( N, typecode='F' ) c=a*a
crashes with N = 258168. The same code does not crash for N = 258167. So 258168 is a kind of limit, because for any lower value, it is OK. This is no memory problem (258168 is not a big value and I have 512 Mb RAM !-). Moreover, if I change scipy for Numeric, the problem disappears !
Also, the interpreter crashes with no error message at all, as if some 'exit()' code was encountered somewhere.
What's going on ? How to solve this ?
To me it is a very important bug. We can deal on this list about the color of graphics or about some weird special function... but here we're dealing about the integrity of simple computations.
Could the readers of this mail try the code on their windows box and tell me if they can reproduce the bug. Any idea to overcome this problem, or just a hint is welcome, because I'm completely stuck !!!!!
Thanks in advance,
C. Grimault
------------------------------------------------------------------------
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
Hi I get the following (PIII, Win2k, Python 2.3.2) these are the N values where the error begins. SciPy Numeric typecode='D' typecode='D' N=258144 FAIL N=258140 FAIL typecode='F' typecode='F' N=258140 FAIL N=258140 FAIL scipy.__version__ = '0.3.1_283.4226' Numeric.__version__ = '23.3' Both compiled with MinGW GCC 3.3.3 Hope this helps Brett
If someone using the latest version (0.3.1_283.422) could try to reproduce the bug (with the 3 lines just below), and tell me about it, it would be helpfull ...
Thanks in advance,
christophe grimault wrote:
Hi all,
There is a critical bug in scipy, about *very* basic operations between arrays, under MS Windows. Here's the facts :
import scipy a=scipy.arange( N, typecode='F' ) c=a*a
-- Brett G. Olivier (bgoli at sun dot ac dot za ) Triple-J Group for Molecular Cell Physiology, Stellenbosch University http://glue.jjj.sun.ac.za/~bgoli Tel +27-21-8085871 Fax +27-21-8085863 Mobile +27-82-7329306
Brett G. Olivier wrote:
Hi
I get the following (PIII, Win2k, Python 2.3.2) these are the N values where the error begins.
SciPy Numeric typecode='D' typecode='D' N=258144 FAIL N=258140 FAIL
typecode='F' typecode='F' N=258140 FAIL N=258140 FAIL
scipy.__version__ = '0.3.1_283.4226' Numeric.__version__ = '23.3' Both compiled with MinGW GCC 3.3.3
Hope this helps Brett
I've changed some things in CVS to address this problem. I think the problem is due to calling a function that returns a structure (Py_complex) that was compiled with one compiler (MSVC) from another compiler (mingw32). This came up before but I thought we addressed the problem --- apparently a few slipped through. I've placed all needed complex functions in fastumath so that Python functions previously defined are not called. This seemed to fix the problem. I would like feedback from others however... Thanks, -Travis O.
Hi Thanks, using scipy.__version__ = '0.3.1_284.4247' works for me as well with both types D, F and +-*/ operations. Regards Brett
I've changed some things in CVS to address this problem.
I think the problem is due to calling a function that returns a structure (Py_complex) that was compiled with one compiler (MSVC) from another compiler (mingw32). This came up before but I thought we addressed the problem --- apparently a few slipped through.
I've placed all needed complex functions in fastumath so that Python functions previously defined are not called. This seemed to fix the problem.
I would like feedback from others however...
Thanks,
-Travis O.
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
-- Brett G. Olivier (bgoli at sun dot ac dot za ) Triple-J Group for Molecular Cell Physiology, Stellenbosch University http://glue.jjj.sun.ac.za/~bgoli Tel +27-21-8085871 Fax +27-21-8085863 Mobile +27-82-7329306
Hi In addition line 1186 seems also to be incorrect: mrat = max(Numeric.take(nwa1, whmax) / Numeric.take(maxstep, whmax)) I changed it to mrat = max(abs(Numeric.take(nwa1, whmax)) / abs(Numeric.take(maxstep, whmax))) The latter version also works for negative parameter changes (towards the lower limit). bye steve -- If you can't beat your computer at chess, try kickboxing. -- NEU: Bis zu 10 GB Speicher f�r e-mails & Dateien! 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail
Quoting Alan G Isaac <aisaac@american.edu>:
I think that the following trio of systems makes an extremely good base for the graphical side of scientific work today in python: - Matplotlib: regular 2d plots (interactive or scripted), array/image
On Sat, 14 Aug 2004, Fernando Perez apparently wrote: plots,
gui-building. - MayaVi: sophisticated 3d visualization, volumetric rendering, etc. - PyX: algorithmic generation of high-quality postscript diagrams with latex equations.
This post was extremely useful. One ambiguity remained for me: are you suggested PyX remains better than Matplotlib if you need LaTeX equations in your EPS files?
John already addressed the key points better than I can, so just let me add a few details, since I realize my original post wasn't too clear on this point. I think what I meant is best explained with a real world example: http://amath.colorado.edu/faculty/fperez/tmp/04_03_ams_athens.pdf contains examples of a fairly complex code which integrates mayavi, pyx and gnuplot (read matplotlib for future uses, this was done months ago). All the plots and figures you find there are actually methods built into my function and operator objects, which makes interactive work a dream. They call whichever library is best suited for a given task, whether it's 2d plots (gnuplot/matplotlib), 3d surfaces (mayavi) or what I call 'diagrams' (pyx). The distinction between what pyx does and tools like gnuplot/matplotlib is best seen by looking at diagrams like those on pages numbered 6 and 8 (pyx diagrams) vs the more common plots of page 5, for example. Those diagrams, which represent adaptive decompositions of domains in 1 and 2d, don't really fit into the normal definition of a 'plot', so they'd be very hard to generate with a tool like gnuplot or matplotlib. Yet pyx, which is more of an object-oriented frontend to Postscript, makes it very easy to produce them. You get a canvas, and you can say 'put blue squares of this size at all these coordinates, an arrow here, a label here, red squares here, fill these in, etc'. Perhaps matplotlib also offers tools for this task; with gnuplot it would definitely be a major uphill battle to get it done. I'm sure you _could_, but you would feel like you were beating your tool into doing something it wasn't really designed for. PyX, on the other hand makes it very natural. A good example of this is on the pyx page: the code to produce a beautiful Sierpinski triangle is just a few lines, because the problem is so simple to express algorithmically. For a 'plotting' program this would be a far less natural task, I think. I hope this clarifies where I see the two tools complementing each other, in addition to John's comments. Best, f
"Fernando" == Fernando Perez <Fernando.Perez@colorado.edu> writes:
Fernando> Perhaps matplotlib also offers tools for this task; with Fernando> gnuplot it would definitely be a major uphill battle to Fernando> get it done. I'm sure you _could_, but you would feel Fernando> like you were beating your tool into doing something it Fernando> wasn't really designed for. PyX, on the other hand Fernando> makes it very natural. A good example of this is on the Fernando> pyx page: the code to produce a beautiful Sierpinski Fernando> triangle is just a few lines, because the problem is so Fernando> simple to express algorithmically. For a 'plotting' Fernando> program this would be a far less natural task, I think. I second this. While it is possible to draw block/state diagrams in gnuplot/matplotlib/your-favorite plotting package because you can create all the primitives (lines, text, rectangles, polygons) it's not easy w/o some dedicated code to support the task. One could certainly add them, eg when John Gill wrote a table class for matplotlib, creating a Cell and Table class to do the layout, but as Fernando says, w/o this extra support, these diagrams won't come naturally. Some day some enterprising young soul will probably come along and add support, but until then pyx, graphviz, omnigrafflle, or any one of the many latex macro packages will serve better. JDH
Quoting John Hunter <jdhunter@nitace.bsd.uchicago.edu>:
Some day some enterprising young soul will probably come along and add support, but until then pyx, graphviz, omnigrafflle, or any one of the many latex macro packages will serve better.
Let me add that I don't view this as a limitation of matplotlib in any way. I think that pyx and matplotlib address different problem domains (albeit with some overlap, since pyx also has normal 'plotting'). I'm happy to have _both_ tools, and I just use the one that is best suited to the task at hand. Best, f
Quoting Alan G Isaac <aisaac@american.edu>:
On Sat, 14 Aug 2004, Fernando Perez apparently wrote:
http://amath.colorado.edu/faculty/fperez/tmp/04_03_ams_athens.pdf
contains examples of a fairly complex code which integrates mayavi, pyx and gnuplot (read matplotlib for future uses, this was done months ago).
This pdf along with your description of your computing environment (posted a few days ago) are priceless. A few questions about the presentation: I assume the equations were generated in TeX. What font is that? Did you generate the presentation in PowerPoint, or a LaTeX (or ConTeXt?) presentation style? Or OpenOffice.org? [Wait ... wouldn't be PowerPoint ... you're on Linux ...] Or did you use PyX to generate the equations?
All the plots and figures you find there are actually methods built into my function and operator objects, which makes interactive work a dream. They call whichever library is best suited for a given task, whether it's 2d plots (gnuplot/matplotlib), 3d surfaces (mayavi) or what I call 'diagrams' (pyx).
I'm not sure I understand, but I'm more than a little interested in making "interactive work a dream". Could you elaborate a bit: What do your functions and objects do? Do you mean that the function and operator objects have "side effect" (in distinction from methods that I might call "primary" in the sense that they do mathematical processing and whatnot) methods that create appropriate plots? And much thanks for your contributions to the community. -gary
gpajer@rider.edu wrote:
On Sat, 14 Aug 2004, Fernando Perez apparently wrote:
http://amath.colorado.edu/faculty/fperez/tmp/04_03_ams_athens.pdf
contains examples of a fairly complex code which integrates mayavi, pyx and gnuplot (read matplotlib for future uses, this was done months ago).
This pdf along with your description of your computing environment (posted a few days ago) are priceless.
A few questions about the presentation:
I assume the equations were generated in TeX. What font is that? Did you generate the presentation in PowerPoint, or a LaTeX (or ConTeXt?) presentation style? Or OpenOffice.org? [Wait ... wouldn't be PowerPoint ... you're on Linux ...] Or did you use PyX to generate the equations?
The document is latex, but it was actually written using LyX. My preamble contains: % Packages to get good-looking PDFs \usepackage[T1]{fontenc} \usepackage{ae,aecompl} \usepackage{mathpazo,courier,euler} \usepackage[scaled=.95]{helvet} The last two select the fonts for math you are asking about. I prefer them over Computer Modern for presentations, because many lines in the CM fonts are extremely thin and display very poorly on typical 1024x768 LCD projectors. This Euler font has thicker lines, and results in more readable presentations on low-resolution displays. Incidentally, this is the font used by Knuth in his Discrete Math text, so it's not only a screen font, it's just much less well known than the CM family. The CM fonts print very well, but a laser printer has MUCH more resolution than an LCD projector. On a side note, lyx is a very pleasant environment for scientific document creation, esp. when combined with pybliographic for bibliography management (accidentally another remarkable python program, see the trend ? :). And some in the Lyx team have been very receptive to the idea of having a mathematica-like environment (I'm talking about the notebook interface, not the symbolic capabilities) for python use based on Lyx. But this is a topic for another day...
All the plots and figures you find there are actually methods built into my function and operator objects, which makes interactive work a dream. They call whichever library is best suited for a given task, whether it's 2d plots (gnuplot/matplotlib), 3d surfaces (mayavi) or what I call 'diagrams' (pyx).
I'm not sure I understand, but I'm more than a little interested in making "interactive work a dream".
Could you elaborate a bit: What do your functions and objects do? Do you mean that the function and operator objects have "side effect" (in distinction from methods that I might call "primary" in the sense that they do mathematical processing and whatnot) methods that create appropriate plots?
Exactly. They either have methods which directly generate plots when appropriate, or which return other objects suitable for plotting. For example, a Poisson kernel has things like: poisson.plot_kernel_err -> plots the error in the approximation of the kernel poisson.norm2sc_table -> return a dict of arrays which can be plotted directly with the plot2() routine included in ipython's gnuplot extensions (this allows plotting of dicts of arrays, with an auto-generated legend by key, extremely useful for many of my codes). poisson.info, poisson.info_norm, poisson.info_ranges -> these print various useful information about many mathematical details of the object, useful in debugging and benchmarkig. etc... The idea is that instead of writing monolithic codes which are meant to be only run in batch mode, I create objects whose methods (by calling mayavi, gnuplot, pyx, or simply printing out stuff) make them very flexible and convenient at the interactive prompt. Combined with ipython, which gives me via @run and @pdb a rapid test/debug/profile environment, I find that I can work in a way which is far more flexible and pleasant than the style with traditional 'big' C/Fortran codes. Note that since all of these methods are inside the objects, they can still be used in batch mode if needed, by simply redirecting the plots to files instead of to the screen. This way, the library automatically comes with builtin, 'smart' plotting (smart in the sense that each plotting method knows how to generate the appropriate plot, scale the axes, labels, etc. This is better than spitting out plain text files and relying on a jumble of semi-random external plotting scripts which _always_ get lost or fall out of sync with the core code). I hope this is useful. Your questions have given me an idea about my next talk at scipy'04. Instead of talking only about the mathematical side of this stuff, I may include a bit on this workflow. It may not necessarily be obvious to everybody how efficient this combination can be. I still see people using python as a regular write/compile/run language, just with the convenience that the compilation step is automatic for them. In my opinion, this is a dramatic underuse of python's potential for scientific development.
And much thanks for your contributions to the community.
Thanks for the feedback, I'm glad you've found my stuff useful. Best, f
"FP" == Fernando Perez <Fernando.Perez@colorado.edu> writes:
[snip] I'm honestly surprised that more folks don't use this kind of workflow. All the interactive work for my PhD was via IPython and several classes and Python scripts I wrote. For plots I used Grace with Nathan Gray's gracePlot.py and MayaVi for the 3D stuff. FP> Your questions have given me an idea about my next talk at FP> scipy'04. Instead of talking only about the mathematical side FP> of this stuff, I may include a bit FP> on this workflow. It may not necessarily be obvious to FP> everybody how FP> efficient this combination can be. I still see people using FP> python as a regular write/compile/run language, just with the FP> convenience that the compilation step is automatic for them. Most of my talk will focus on showing how Python (plus several useful modules) combined with C/C++/Fortran is one hell of a combination for scientific computation. I think the math part is fun. However it is not as generally useful (to the audience) as a good demonstration of the amazing power of Python for scientific computing. FP> In my opinion, this is a dramatic underuse of python's FP> potential for scientific development. Absolutely. cheers, prabhu
Prabhu Ramachandran wrote:
"FP" == Fernando Perez <Fernando.Perez@colorado.edu> writes:
[snip]
I'm honestly surprised that more folks don't use this kind of workflow. All the interactive work for my PhD was via IPython and several classes and Python scripts I wrote. For plots I used Grace with Nathan Gray's gracePlot.py and MayaVi for the 3D stuff.
Well, that's my view as well, but I wonder if it's universally known or not. Do you think it's worth presenting this to a large audience, or will we just get yawns about the obviousness of it all? f
"FP" == Fernando Perez <Fernando.Perez@colorado.edu> writes:
FP> Prabhu Ramachandran wrote: >>>>>>> "FP" == Fernando Perez <Fernando.Perez@colorado.edu> >>>>>>> writes: >> [snip] >> >> I'm honestly surprised that more folks don't use this kind of >> workflow. All the interactive work for my PhD was via IPython >> and several classes and Python scripts I wrote. For plots I >> used Grace with Nathan Gray's gracePlot.py and MayaVi for the >> 3D stuff. FP> Well, that's my view as well, but I wonder if it's universally FP> known or not. Do you think it's worth presenting this to a FP> large audience, or will we just get yawns about the FP> obviousness of it all? No clue. I guess some section of the audience will yawn one way or another (hopefully not either way though). ;-) cheers, prabhu
"FP" == Fernando Perez <Fernando.Perez@colorado.edu> writes:
FP> Prabhu Ramachandran wrote: >>>>>>> "FP" == Fernando Perez <Fernando.Perez@colorado.edu> >>>>>>> writes: >> [snip] >> >> I'm honestly surprised that more folks don't use this kind of >> workflow. All the interactive work for my PhD was via IPython >> and several classes and Python scripts I wrote. For plots I >> used Grace with Nathan Gray's gracePlot.py and MayaVi for the >> 3D stuff.
FP> Well, that's my view as well, but I wonder if it's universally FP> known or not. Do you think it's worth presenting this to a FP> large audience, or will we just get yawns about the FP> obviousness of it all?
No clue. I guess some section of the audience will yawn one way or another (hopefully not either way though). ;-)
Here's a clue: It's obvious to me that I'm underutilizing the interactive capabilities of python. It's not obvious to me what combination of facilities will put me in that state of being "one with the system". There are a lot of combinations and permutations, each with a learning curve to get through even before you can make a judgement. I've been going through this process of exploration for a year or so, trying to find my way out of the write/compile/run rut. I'm grateful to anyone who can point out shortcuts or workflow/structure ideas. I don't think you would generate yawns in a presentation to a wide audience. The landscape is rather rich with possibilities, and I'm sure no one in the audience will have constructed the same system. Everyone would get something out of such a talk.
cheers, prabhu
_______________________________________________ SciPy-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
gpajer@rider.edu wrote:
I don't think you would generate yawns in a presentation to a wide audience. The landscape is rather rich with possibilities, and I'm sure no one in the audience will have constructed the same system. Everyone would get something out of such a talk.
Good enough, thanks. I'll include some of this then. It seems to me like there's a need for a solid book/tutorial on scientific computing with python which combines: - description of existing tools, but making a justified choice of a suitable 'best' one for real-life work. Laundry lists are semi-useless because they leave to the users the task of trying everything out there. - documenting the scipy core in detail. The existing tutorial is good, but missing parts. This would obviously mean extending, not rewriting, the existing docs. - presenting workflow suggestions, with real-world examples of how to achieve this efficiently. This includes interactive work, C/C++/Fortran integration, plotting/visualization, making all of this batch and gui-less-friendly, etc. And then, we need to build a mathematica-notebook-like environment for python, so we can work, write text and equations, plot and print finished documents, all from within a single system. So much to do, so little time... Best, f
participants (11)
-
Alan G Isaac -
Brett G. Olivier -
christophe grimault -
Fernando Perez -
Fernando.Perez＠colorado.edu
-
gpajer＠rider.edu -
John Hunter -
Nils Wagner -
Prabhu Ramachandran -
Steve Schmerler -
Travis Oliphant