[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:
>
>
>>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
More information about the SciPy-user
mailing list