Python Graphing Utilities.

[Kenneth Miller]

Hello All,

I am new to Python and i was wondering what graphing utlities would be
available to me. I have already tried BLT and after weeks of unsuccesful
installs i'd like to find something else. Anything someone would recommend?

Regards,
Ken

[Fredrik Lundh]

Kenneth Miller wrote:

I am new to Python and i was wondering what graphing utlities would be
available to me. I have already tried BLT and after weeks of unsuccesful
installs i'd like to find something else. Anything someone would recommend?

start here:

http://www.python.org/moin/NumericAn...tific/Plotting
http://starship.python.net/crew/jhauser/plot-res.html

or roll your own:

http://effbot.org/zone/wckgraph.htm

</F>

[Bill Mill]

On 5/10/05, Kenneth Miller <ke********@entouch.net> wrote:

Hello All,

I am new to Python and i was wondering what graphing utlities would be
available to me. I have already tried BLT and after weeks of unsuccesful
installs i'd like to find something else. Anything someone would recommend?

matplotlib is awesome:

http://matplotlib.sourceforge.net/

and gnuplot.py is passable:

http://gnuplot-py.sourceforge.net/

(a better version of gnuplot.py is available with the excellent
ipython interpreter at http://ipython.scipy.org/)

All of the above are cross-platform to at least linux and windows.

Peace
Bill Mill
bill.mill at gmail.com

[Thomas Lotze]

Kenneth Miller wrote:

I am new to Python and i was wondering what graphing utlities would be
available to me. I have already tried BLT and after weeks of unsuccesful
installs i'd like to find something else. Anything someone would
recommend?

You might also want to check out PyX: <http://pyx.sf.net/>.

--
Thomas

[Grant Edwards]

On 2005-05-10, Kenneth Miller <ke********@entouch.net> wrote:

I am new to Python and i was wondering what graphing utlities
would be available to me.

Exactly what do you mean by "graphing"? I think pygnuplot
pretty much kicks for the graphs and plots I do.

--
Grant Edwards grante Yow! FIRST, I'm covering
at you with OLIVE OIL and
visi.com PRUNE WHIP!!

[Kenneth Miller]

Ahh Thanks for the quick replies. I'm having a look through them now. What
would you consider the best for real time applications? The idea here is to
stream in the results from an A/D converter onto a 2d chart.

Regards,
Ken

[Grant Edwards]

On 2005-05-10, Kenneth Miller <ke********@entouch.net> wrote:

Ahh Thanks for the quick replies. I'm having a look through
them now. What would you consider the best for real time
applications?
That depends on how fast "real time" is. I use gnuplot-py for
1 Hz update rates with no issues. 2Hz worked OK but much
faster than that probably isn't the best application for
gnuplot.
The idea here is to stream in the results from an A/D
converter onto a 2d chart.

--
Grant Edwards grante Yow! Why is everything
at made of Lycra Spandex?
visi.com

[Ron Adam]

Kenneth Miller wrote:

Hello All,

I am new to Python and i was wondering what graphing utlities would be
available to me. I have already tried BLT and after weeks of unsuccesful
installs i'd like to find something else. Anything someone would recommend?

Regards,
Ken

BLT doesn't install in the correct directories on Windows. I found this
helpful.

1. Install BLT 2.4u into C:/Python23/tcl, using BLT's installer
(the one for Tcl/Tk 8.3). This gives you bin, include, and lib
subdirectories of C:/Python23/tcl, with all the BLT stuff in them.
2. Copy C:/Python23/tcl/lib/blt2.4 into C:/Python23/tcl/tcl8.3.
3. Put the BLT DLLs in a directory on your PATH (not necessarily a
system directory, it just has to be on your PATH)

Clipped from: http://heim.ifi.uio.no/~hpl/scripting/software.html
Cheers,
_Ron

[Fernando Perez]

Bill Mill wrote:

On 5/10/05, Kenneth Miller <ke********@entouch.net> wrote:

Hello All,

I am new to Python and i was wondering what graphing utlities would be
available to me. I have already tried BLT and after weeks of unsuccesful
installs i'd like to find something else. Anything someone would recommend?

matplotlib is awesome:

http://matplotlib.sourceforge.net/

and gnuplot.py is passable:

http://gnuplot-py.sourceforge.net/

(a better version of gnuplot.py is available with the excellent
ipython interpreter at http://ipython.scipy.org/)

Just to clarify: with ipython, you still need the default gnuplot-py package,
it's just that ipython enhances it a bit.

And I'd also second the matplotlib suggestion, to which I've by now fully
switched after years of faithful gnuplot usage. Matplotlib is very good, has
an active development community, and it is designed from the ground up not
only as a library for rendering plots to screen/disk, but also for embedding
into guis (with support for Tk, WX, GTK, QT and FLTK). So it should satisfy
the OP's needs well, and if he has any problems with it, feel free to stop by
the user list which is fairly active.

As a disclaimer, while I've added support in ipython for interactive matplotlib
usage with most backends (except FLTK), I'm not a full-time developer. So I
feel it's OK to cheer JDH's and all the rest of the team's excellent work on
matplotlib.

Best,

f

[Kenneth Miller]

Unix, not windows ><
"Ron Adam" <rr*@ronadam.com> wrote in message
news:ma**************************************@pyth on.org...

Kenneth Miller wrote:

Hello All,

I am new to Python and i was wondering what graphing utlities would be available to me. I have already tried BLT and after weeks of unsuccesful
installs i'd like to find something else. Anything someone would recommend?
Regards,
Ken

BLT doesn't install in the correct directories on Windows. I found this
helpful.

1. Install BLT 2.4u into C:/Python23/tcl, using BLT's installer
(the one for Tcl/Tk 8.3). This gives you bin, include, and lib
subdirectories of C:/Python23/tcl, with all the BLT stuff in them.
2. Copy C:/Python23/tcl/lib/blt2.4 into C:/Python23/tcl/tcl8.3.
3. Put the BLT DLLs in a directory on your PATH (not necessarily a
system directory, it just has to be on your PATH)

Clipped from: http://heim.ifi.uio.no/~hpl/scripting/software.html
Cheers,
_Ron

[Kenneth Miller]

Beleive i'm going to try out PyX.

"Fernando Perez" <fp********@gmail.com> wrote in message
news:ma**************************************@pyth on.org...

Bill Mill wrote:

On 5/10/05, Kenneth Miller <ke********@entouch.net> wrote:

Hello All,

I am new to Python and i was wondering what graphing utlities would be available to me. I have already tried BLT and after weeks of unsuccesful installs i'd like to find something else. Anything someone would

recommend?
matplotlib is awesome:

http://matplotlib.sourceforge.net/

and gnuplot.py is passable:

http://gnuplot-py.sourceforge.net/

(a better version of gnuplot.py is available with the excellent
ipython interpreter at http://ipython.scipy.org/)
Just to clarify: with ipython, you still need the default gnuplot-py

package, it's just that ipython enhances it a bit.

And I'd also second the matplotlib suggestion, to which I've by now fully
switched after years of faithful gnuplot usage. Matplotlib is very good, has an active development community, and it is designed from the ground up not
only as a library for rendering plots to screen/disk, but also for embedding into guis (with support for Tk, WX, GTK, QT and FLTK). So it should satisfy the OP's needs well, and if he has any problems with it, feel free to stop by the user list which is fairly active.

As a disclaimer, while I've added support in ipython for interactive matplotlib usage with most backends (except FLTK), I'm not a full-time developer. So I feel it's OK to cheer JDH's and all the rest of the team's excellent work on matplotlib.

Best,

f

[Torsten Bronger]

Hallöchen!

Fernando Perez <fp********@gmail.com> writes:

[...]

And I'd also second the matplotlib suggestion, to which I've by
now fully switched after years of faithful gnuplot usage.
Matplotlib is very good, has an active development community, and
it is designed from the ground up not only as a library for
rendering plots to screen/disk, but also for embedding into guis
(with support for Tk, WX, GTK, QT and FLTK).

Why not for Gnuplot, by the way?

On sceen, matplotlib looks extremely good, however, I still need
Gnuplot for the hardcopy version[*]. It *seems* to me that the
programming interfaces are quite different, so a Gnuplot backend for
matplotlib would be helpful for me.

Tschö,
Torsten.
[*] because of the "pslatex" backend, which means that the plot is
typeset by the same LaTeX run as your document --> consistent fonts,
TeX-quality formulae
--
Torsten Bronger, aquisgrana, europa vetus

[Bill Mill]

On 5/11/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

Hallöchen!

Fernando Perez <fp********@gmail.com> writes:

[...]

And I'd also second the matplotlib suggestion, to which I've by
now fully switched after years of faithful gnuplot usage.
Matplotlib is very good, has an active development community, and
it is designed from the ground up not only as a library for
rendering plots to screen/disk, but also for embedding into guis
(with support for Tk, WX, GTK, QT and FLTK).
Why not for Gnuplot, by the way?

On sceen, matplotlib looks extremely good, however, I still need
Gnuplot for the hardcopy version[*]. It *seems* to me that the
programming interfaces are quite different, so a Gnuplot backend for
matplotlib would be helpful for me.

By hardcopy version, I assume you mean Postscript? From
http://matplotlib.sourceforge.net/fonts.html :

Postscript
Postscript, despite its age, is still a great output format. Most
publishers accept it, it scales to arbitrary resolutions, you can
import it directly into LaTeX document, and send it directly to
postscript printers.

The only requirement to generate postscript output is the Numeric
module and some AFM fonts on your system. Even the latter is only a
quasi-requirement, because matplotlib ships with some of the most
popular font files. These are Adobe Font Metric files, which have the
'*.afm' extension. matplotlib comes with it's own AFM parser to read
these files and select the best match for the font you've chosen. If
you want additional fonts, set the AFMPATH environment variable to
point to the dir containing your AFM font files. matplotlib willl
recursively search any directory in AFMPATH, so you only need to
specify a base directory if multiple subdirectories contaning '*.afm'
files.

Peace
Bill Mill
bill.mill at gmail.com

Tschö,
Torsten.

[*] because of the "pslatex" backend, which means that the plot is
typeset by the same LaTeX run as your document --> consistent fonts,
TeX-quality formulae
--
Torsten Bronger, aquisgrana, europa vetus
--
http://mail.python.org/mailman/listinfo/python-list

[Torsten Bronger]

Hallöchen!

Bill Mill <bi*******@gmail.com> writes:

On 5/11/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

Fernando Perez <fp********@gmail.com> writes:

[...]

[...] Matplotlib is very good, has an active development
community, and it is designed from the ground up not only as a
library for rendering plots to screen/disk, but also for
embedding into guis (with support for Tk, WX, GTK, QT and FLTK).
Why not for Gnuplot, by the way?

On sceen, matplotlib looks extremely good, however, I still need
Gnuplot for the hardcopy version[*]. It *seems* to me that the
programming interfaces are quite different, so a Gnuplot backend
for matplotlib would be helpful for me.

By hardcopy version, I assume you mean Postscript?

Not really. Gnuplot's output is LaTeX with a couple of native
Postscript directives inbetween. It's inluded into my document with
"\input plot.plt" rather than "\includegraphics{plot.eps}".

I mentioned the advantages of this approach in the footnote:
[...]

[*] because of the "pslatex" backend, which means that the plot
is typeset by the same LaTeX run as your document --> consistent
fonts, TeX-quality formulae

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Bill Mill]

On 5/11/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

Hallöchen!

Bill Mill <bi*******@gmail.com> writes:

On 5/11/05, Torsten Bronger <br*****@physik.rwth-aachen.de> wrote:

Fernando Perez <fp********@gmail.com> writes:

[...]

[...] Matplotlib is very good, has an active development
community, and it is designed from the ground up not only as a
library for rendering plots to screen/disk, but also for
embedding into guis (with support for Tk, WX, GTK, QT and FLTK).

Why not for Gnuplot, by the way?

On sceen, matplotlib looks extremely good, however, I still need
Gnuplot for the hardcopy version[*]. It *seems* to me that the
programming interfaces are quite different, so a Gnuplot backend
for matplotlib would be helpful for me.

By hardcopy version, I assume you mean Postscript?

Not really. Gnuplot's output is LaTeX with a couple of native
Postscript directives inbetween. It's inluded into my document with
"\input plot.plt" rather than "\includegraphics{plot.eps}".

I mentioned the advantages of this approach in the footnote:

Tha's cool, I saw what you wrote. First off, I wasn't sure what you
meant by "hardcopy", so I thought I'd let you know that matplotlib has
PS output. Second, the page I linked to talks about all the font-type
features of matplotlib, which I thought might interest you. Having not
gotten funky with them, I cannot vouch for their quality.

Peace
Bill Mill
bill.mill at gmail.com

[Robert Kern]

Bill Mill wrote:

Tha's cool, I saw what you wrote. First off, I wasn't sure what you
meant by "hardcopy", so I thought I'd let you know that matplotlib has
PS output. Second, the page I linked to talks about all the font-type
features of matplotlib, which I thought might interest you. Having not
gotten funky with them, I cannot vouch for their quality.

They're not TeX-quality. Yet.

A pslatex backend certainly would be interesting. A Gnuplot backend
would probably not be feasible. Does it expose its raw drawing operations?

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Torsten Bronger]

Hallöchen!

Robert Kern <rk***@ucsd.edu> writes:

[...]

A pslatex backend certainly would be interesting. A Gnuplot
backend would probably not be feasible. Does it expose its raw
drawing operations?

Probably not raw enough, but I don't know how basic matplotlib
wants it to be. You could switch the axes off and draw everything
as lines using plot coordinates, but I don't know how sensible this
would be.

On the other hand, the "pslatex" output of Gnuplot is one of the
very few things that hold me there. If matplotlib produced
something equivalent, (at least) I wouldn't call for a Gnuplot
backend anymore.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Fernando Perez]

Torsten Bronger wrote:

Hallöchen!

Fernando Perez <fp********@gmail.com> writes:

[...]

And I'd also second the matplotlib suggestion, to which I've by
now fully switched after years of faithful gnuplot usage.
Matplotlib is very good, has an active development community, and
it is designed from the ground up not only as a library for
rendering plots to screen/disk, but also for embedding into guis
(with support for Tk, WX, GTK, QT and FLTK).

Why not for Gnuplot, by the way?

On sceen, matplotlib looks extremely good, however, I still need
Gnuplot for the hardcopy version[*]. It *seems* to me that the
programming interfaces are quite different, so a Gnuplot backend for
matplotlib would be helpful for me.

Well, it's true that the latex-type (called mathtext) support in matplotlib is
not really up to par with true latex (kerning is off in places, mixed
text/math doesn't work well, etc). I've been willing to live with it so far,
but an alternative option is to use the PS backend and then play psfrag
tricks. I've yet to experiment with it, but it might (with some additional
handywork) give final results identical to those of the pslatex backend in
gnuplot.

I used gnuplot for about 14 years, so I'm not about to bash it: it's a
fantastic tool. But there are a number of things it simply can't offer due to
its design as a standalone program, which matplotlib (being a library/widget
collection) can do much better. And John Hunter (matplotlib's author) has
been _extremely_ receptive to my long list of "gnuplot has this and I won't
switch to matplotlib until you add it" requests. Today, mpl has a number of
things which have been added by explicitly trying to match either features,
performance or quality against gnuplot after my repeated pestering to him.
Given these improvements (many of them quite recent), I finally made the
switch and I'm extremely happy. Even though rough edges remain (like the tex
support), I'm confident that the quality of the library and the team behind it
is such, that they'll be overcome in short order.

But again, this shouldn't be read as anything against gnuplot: it's a very good
tool, M. Haggerty's python support makes it a pleasure to use from python, and
if it does what you need, by all means use it! I just wanted to fill in a bit
the picture regarding matplotlib, just to be fair to John and his dedicated
team.

Regards,

f

[Torsten Bronger]

Hallöchen!

Fernando Perez <fp********@gmail.com> writes:

[...]

Well, it's true that the latex-type (called mathtext) support in
matplotlib is not really up to par with true latex (kerning is off
in places, mixed text/math doesn't work well, etc). I've been
willing to live with it so far, but an alternative option is to
use the PS backend and then play psfrag tricks.
The problem is that mostly, you'll have a *lot* to substitute.
I've yet to experiment with it, but it might (with some additional
handywork) give final results identical to those of the pslatex
backend in gnuplot.
What do you mean with this? Do you want to mimic TeX's quality as a
typesetter, or do you think the goal should be output in real LaTeX
format (like pslatex does)? The latter would be more useful in my
opinion, and much easier, too.
[...] But there are a number of things it simply can't offer due
to its design as a standalone program, which matplotlib (being a
library/widget collection) can do much better. [...] I finally
made the switch and I'm extremely happy.

I'm not a fanatic Gnuplot user either. I use it for 11 years, and I
like exactly two things about it: its simplicity and the pslatex
backend. I think for my thesis I'll still use it, because its
integration in a batch process that builds my thesis is much easier
than to write Python programs.

But if you have measurement programs in Python (I work in a project
making this feasible) with on-line plots with mpl, it'd be nice to
have the possibility to direct them to a file for high-quality
typesetting as well.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus

[Robert Kern]

Torsten Bronger wrote:

Hallöchen!

Fernando Perez <fp********@gmail.com> writes:

I've yet to experiment with it, but it might (with some additional
handywork) give final results identical to those of the pslatex
backend in gnuplot.

What do you mean with this? Do you want to mimic TeX's quality as a
typesetter, or do you think the goal should be output in real LaTeX
format (like pslatex does)?

Both! There is a need for mathematical typesetting in matplotlib without
a dependency on TeX. Not everyone is making plots destined for inclusion
in their LaTeX-typeset papers. However, some people, like you and me,
*are* making such plots and a pslatex-based solution would be a perfect
fit for that use case.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Fernando Perez]

Torsten Bronger wrote:

Hallöchen!

Fernando Perez <fp********@gmail.com> writes:

[...]

Well, it's true that the latex-type (called mathtext) support in
matplotlib is not really up to par with true latex (kerning is off
in places, mixed text/math doesn't work well, etc). I've been
willing to live with it so far, but an alternative option is to
use the PS backend and then play psfrag tricks.

The problem is that mostly, you'll have a *lot* to substitute.

I've yet to experiment with it, but it might (with some additional
handywork) give final results identical to those of the pslatex
backend in gnuplot.

What do you mean with this? Do you want to mimic TeX's quality as a
typesetter, or do you think the goal should be output in real LaTeX
format (like pslatex does)? The latter would be more useful in my
opinion, and much easier, too.

Easier... psfrag tricks can be done right now, while full latex output requires
writing a new matplotlib backend. It would certainly be a _great_ project,
but not one I'm about to undertake, while it's reasonable for me to use psfrag
to fix a few labels here and there to use proper latex. So while I agree with
you that in the long run a latex backend would be ideal, as a stop-gap
solution I can live with psfrag.

[...] But there are a number of things it simply can't offer due
to its design as a standalone program, which matplotlib (being a
library/widget collection) can do much better. [...] I finally
made the switch and I'm extremely happy.

I'm not a fanatic Gnuplot user either. I use it for 11 years, and I
like exactly two things about it: its simplicity and the pslatex
backend. I think for my thesis I'll still use it, because its
integration in a batch process that builds my thesis is much easier
than to write Python programs.

well, unless your batch process _is_ in python :) Mine was, so my
make_plots.py was a single script, which ironically (for this discussion) was
all gnuplot.py-based, since this was a few years ago.

Cheers,

f

[Petr Mikulik]

> A pslatex backend certainly would be interesting. A Gnuplot backend

would probably not be feasible. Does it expose its raw drawing operations?

There is a patch
[ 1027032 ] Connect gnuplot_x11 to exterior application window
http://sourceforge.net/tracker/index...55&atid=302055

which allows to "Connect gnuplot_x11 to exterior application window...".

If you test it, please write a note there and the patch can go to cvs.

---
PM

[Petr Mikulik]

> A pslatex backend certainly would be interesting. A Gnuplot backend

would probably not be feasible. Does it expose its raw drawing operations?

There is a patch
[ 1027032 ] Connect gnuplot_x11 to exterior application window
http://sourceforge.net/tracker/index...55&atid=302055

which allows to "Connect gnuplot_x11 to exterior application window...".

If you test it, please write a note there and the patch can go to cvs.

---
PM