# mpl command-line utilities

Hello,

the same calling signature as graph?

I think the most important question is: would it be useful?

Yes, this would certainly be useful! I think there are people
unfamiliar with Python, but rather excited about MPL's plotting
capabilities.

I personally would want it to read data from white-space separated text
files (np.loadtxt()), probably CSV files, and HDF5 files (e.g. using
h5py, if available).

To be useful for different purposes, I'd want the tool to be able to use
different backends (producing e.g. PNG output in case you need a figure
to send via e-mail or PGF output in case you are preparing a LaTeX
document). Matplotlibrc should be hidden from the user.

As Gnuplot was specifically mentioned in another e-mail in this thread,
let me use that opportunity to mention that MPL falls behind Gnuplot in
terms of line styles. Using MPL, I found ls="-" and maybe ls="--" to be
useful, whereas Gnuplot offers 9 linestyles that are easy to
distinguish visually. Compare e.g. the figure linked in
http://www.der-schnorz.de/2010/09/gnuplot-colors-presentations-papers-and-contrast/
In case this is of general interest, we might discuss that in a new

As a side note, personally, for text file visualisation, I often use
this dirty MPL plotting plugin for the text editor of my choice (Geany):
https://github.com/aeberspaecher/GeanyPlot
A command line tool would of course be preferred.

Cheers

Alex

···

On Wed, 17 Oct 2012 11:38:27 +0100 Damon McDougall <damon.mcdougall@...287...> wrote:

Ok wow, awesome feedback! I started on this yesterday morning to see
how it would go, and I've already got something working that mimics
the command-line syntax of GNU's graph (except it currently only
supports one data file as input).

I'm currently just developing on a local feature branch in the
matplotlib repository, but I'm happy to pull it out to a different
repo and announce it here once I make some more ground on it. I
haven't pushed anything yet. If I do I'll make an announcement here.

One thing I have noticed is that GNU's graph is rather fast.
Compared to matplotlib, GNU's graph blows matplotlib out of the
water when it comes to speed. Though, in my opinion, matplotlib wins
when it comes to output quality. As far as I'm concerned, quality wins
over speed but I realise that there needs to be some speed
improvements in matplotlib's backends. I have noticed that text takes
quite a while to process in the backend (currently using Agg for PDF
and PNG output).

Regarding input data file-type, I agree, supporting those formats
would expand our userbase considerably. There are already some helper
functions in matplotlib.cbook for reading csv-type files. One downside
of supporting lots of different file-types is that there will be more
(optional) dependencies.

Personally, when I just want to see statistics from a computational
run, I think I will find this rather helpful.

I think I should be able to make this public fairly soon. Furthermore,
it will be trivial to install (copy and paste to the /usr/local/bin
directory). The command-line utility is literally just a python script
(with executable permissions) that parses command-line arguments and
sets up plot and figure parameters. Of course, it may be the case in
the future that it gets rather large and needs to be made more
modular.

Right-o, back to more procrastinating. Thanks for all the encouragement!

···

On Thu, Oct 18, 2012 at 10:10 AM, Alexander Eberspaecher <alexander.eberspaecher@...3273...> wrote:

Hello,

On Wed, 17 Oct 2012 11:38:27 +0100 > Damon McDougall <damon.mcdougall@...287...> wrote:

the same calling signature as graph?

I think the most important question is: would it be useful?

Yes, this would certainly be useful! I think there are people
unfamiliar with Python, but rather excited about MPL's plotting
capabilities.

I personally would want it to read data from white-space separated text
files (np.loadtxt()), probably CSV files, and HDF5 files (e.g. using
h5py, if available).

To be useful for different purposes, I'd want the tool to be able to use
different backends (producing e.g. PNG output in case you need a figure
to send via e-mail or PGF output in case you are preparing a LaTeX
document). Matplotlibrc should be hidden from the user.

As Gnuplot was specifically mentioned in another e-mail in this thread,
let me use that opportunity to mention that MPL falls behind Gnuplot in
terms of line styles. Using MPL, I found ls="-" and maybe ls="--" to be
useful, whereas Gnuplot offers 9 linestyles that are easy to
distinguish visually. Compare e.g. the figure linked in
http://www.der-schnorz.de/2010/09/gnuplot-colors-presentations-papers-and-contrast/
In case this is of general interest, we might discuss that in a new

As a side note, personally, for text file visualisation, I often use
this dirty MPL plotting plugin for the text editor of my choice (Geany):
https://github.com/aeberspaecher/GeanyPlot
A command line tool would of course be preferred.

Cheers

Alex

--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Ok wow, awesome feedback! I started on this yesterday morning to see
how it would go, and I've already got something working that mimics
the command-line syntax of GNU's graph (except it currently only
supports one data file as input).

Great!

Using e.g. optparse, multiple data files shouldn't be too complicated.

I might need to look into GNU graph. I was ignorant about it's
existence till it was mentioned here on the MPL list.

> I'm currently just developing on a local feature branch in the
matplotlib repository, but I'm happy to pull it out to a different
repo and announce it here once I make some more ground on it. I
haven't pushed anything yet. If I do I'll make an announcement here.

Looking forward!

I think a separate repository might be the best option as you probably
do not want to modify MPL in any way, but rather build your scripts on
top of it.

One thing I have noticed is that GNU's graph is rather fast.
Compared to matplotlib, GNU's graph blows matplotlib out of the
water when it comes to speed. Though, in my opinion, matplotlib wins
when it comes to output quality. As far as I'm concerned, quality wins
over speed but I realise that there needs to be some speed
improvements in matplotlib's backends. I have noticed that text takes
quite a while to process in the backend (currently using Agg for PDF
and PNG output).

The good thing is that any command-line "frontend" certainly does not
need to care about backend specifics. The problem is completely
separable.

Regarding input data file-type, I agree, supporting those formats
would expand our userbase considerably. There are already some helper
functions in matplotlib.cbook for reading csv-type files. One downside
of supporting lots of different file-types is that there will be more
(optional) dependencies.

I typically "try:" to import relevant packages and set a flag in case
that doesn't work. Using this approach, all dependencies really remain
optional.

I think I should be able to make this public fairly soon. Furthermore,
it will be trivial to install (copy and paste to the /usr/local/bin
directory). The command-line utility is literally just a python script
(with executable permissions) that parses command-line arguments and
sets up plot and figure parameters. Of course, it may be the case in
the future that it gets rather large and needs to be made more
modular.

In case your approach looks right, I am pretty sure you'll find
contributors quickly.

Good luck!

Cheers

Alex

···

On Thu, 18 Oct 2012 10:45:24 +0100 Damon McDougall <damon.mcdougall@...287...> wrote:

For the record optparse is deprecated so use argparse. This might also be helpful http://www.youtube.com/watch?v=pXhcPJK5cMc, my apologies if it's already been mentioned.

···

On 18/10/2012 12:54, Alexander Eberspaecher wrote:

On Thu, 18 Oct 2012 10:45:24 +0100 > Damon McDougall <damon.mcdougall@...287...> wrote:

Using e.g. optparse, multiple data files shouldn't be too complicated.

--
Cheers.

Mark Lawrence.

Oh. My. God. That is unworldly.

\begin{opinons}
optparse is awful, and deprecated
argparse is better, but has *serious* limitations
\end{opinions}

Thank you *so* much for posting that.

···

On Thu, Oct 18, 2012 at 8:13 PM, Mark Lawrence <breamoreboy@...225...> wrote:

On 18/10/2012 12:54, Alexander Eberspaecher wrote:

On Thu, 18 Oct 2012 10:45:24 +0100 >> Damon McDougall <damon.mcdougall@...287...> wrote:

Using e.g. optparse, multiple data files shouldn't be too complicated.

For the record optparse is deprecated so use argparse. This might also

--
Cheers.

Mark Lawrence.

--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Along these lines, it would be nice to have some built in data sets to show off matplotlib's features--maybe just another library with a bunch of CSV strings, or lists. I am thinking of the built-in data sets for R that allow a new user to experiment without having to make up data each time. Although, I see that already I am suggesting more unneeded complexities into something that should be simple. Just a thought.

Paul

···

On 10/18/12 5:45 AM, Damon McDougall wrote:

On Thu, Oct 18, 2012 at 10:10 AM, Alexander Eberspaecher > <alexander.eberspaecher@...3273...> wrote:

Hello,

On Wed, 17 Oct 2012 11:38:27 +0100 >> Damon McDougall <damon.mcdougall@...287...> wrote:

the same calling signature as graph?

I think the most important question is: would it be useful?

Yes, this would certainly be useful! I think there are people
unfamiliar with Python, but rather excited about MPL's plotting
capabilities.

I personally would want it to read data from white-space separated text
files (np.loadtxt()), probably CSV files, and HDF5 files (e.g. using
h5py, if available).

To be useful for different purposes, I'd want the tool to be able to use
different backends (producing e.g. PNG output in case you need a figure
to send via e-mail or PGF output in case you are preparing a LaTeX
document). Matplotlibrc should be hidden from the user.

As Gnuplot was specifically mentioned in another e-mail in this thread,
let me use that opportunity to mention that MPL falls behind Gnuplot in
terms of line styles. Using MPL, I found ls="-" and maybe ls="--" to be
useful, whereas Gnuplot offers 9 linestyles that are easy to
distinguish visually. Compare e.g. the figure linked in
http://www.der-schnorz.de/2010/09/gnuplot-colors-presentations-papers-and-contrast/
In case this is of general interest, we might discuss that in a new

As a side note, personally, for text file visualisation, I often use
this dirty MPL plotting plugin for the text editor of my choice (Geany):
https://github.com/aeberspaecher/GeanyPlot
A command line tool would of course be preferred.

Cheers

Alex

Ok wow, awesome feedback! I started on this yesterday morning to see
how it would go, and I've already got something working that mimics
the command-line syntax of GNU's graph (except it currently only
supports one data file as input).

I'm currently just developing on a local feature branch in the
matplotlib repository, but I'm happy to pull it out to a different
repo and announce it here once I make some more ground on it. I
haven't pushed anything yet. If I do I'll make an announcement here.

One thing I have noticed is that GNU's graph is rather fast.
Compared to matplotlib, GNU's graph blows matplotlib out of the
water when it comes to speed. Though, in my opinion, matplotlib wins
when it comes to output quality. As far as I'm concerned, quality wins
over speed but I realise that there needs to be some speed
improvements in matplotlib's backends. I have noticed that text takes
quite a while to process in the backend (currently using Agg for PDF
and PNG output).

Regarding input data file-type, I agree, supporting those formats
would expand our userbase considerably. There are already some helper
functions in matplotlib.cbook for reading csv-type files. One downside
of supporting lots of different file-types is that there will be more
(optional) dependencies.