Python Graphing Utilities.

K

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
 
B

Bill Mill

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
 
T

Thomas Lotze

Kenneth said:
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/>.
 
G

Grant Edwards

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

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
 
G

Grant Edwards

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

Ron Adam

Kenneth said:
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
 
F

Fernando Perez

Bill said:
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
 
K

Kenneth Miller

Unix, not windows ><
Ron Adam said:
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
 
K

Kenneth Miller

Beleive i'm going to try out PyX.

Fernando Perez said:
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
 
T

Torsten Bronger

Hallöchen!

Fernando Perez said:
[...]

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
 
B

Bill Mill

Hallöchen!

Fernando Perez said:
[...]

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
 
T

Torsten Bronger

Hallöchen!

Bill Mill said:
Fernando Perez said:
[...]

[...] 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.
 
B

Bill Mill

Hallöchen!

Bill Mill said:
[...]

[...] 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
 
R

Robert Kern

Bill said:
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
(e-mail address removed)

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

Torsten Bronger

Hallöchen!

Robert Kern said:
[...]

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

Fernando Perez

Torsten said:
Hallöchen!

Fernando Perez said:
[...]

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
 
T

Torsten Bronger

Hallöchen!

Fernando Perez said:
[...]

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

Robert Kern

Torsten said:
Hallöchen!



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
(e-mail address removed)

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top