[SciPy-user] gplot documentation

Fernando Perez Fernando.Perez at colorado.edu
Mon Aug 16 12:09:18 CDT 2004

gpajer at rider.edu wrote:

>>>On Sat, 14 Aug 2004, Fernando Perez apparently wrote:
>>contains examples of a fairly complex code which integrates mayavi, pyx
>>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 

% Packages to get good-looking PDFs


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...

>>plots and figures you find there are actually methods built into my
>>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'
> 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.


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.



More information about the SciPy-user mailing list