Menu
▾
▴
matplotlib-users
|
From: Alexander E. <ale...@ov...> - 2012-10-18 09:27:12
|
Hello, On Wed, 17 Oct 2012 11:38:27 +0100 Damon McDougall <dam...@gm...> wrote: > How do people feel about perhaps adding a matplotlib version, mocking > 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 thread. 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 |
|
From: Damon M. <dam...@gm...> - 2012-10-18 09:45:35
|
On Thu, Oct 18, 2012 at 10:10 AM, Alexander Eberspaecher <ale...@ov...> wrote: > Hello, > > On Wed, 17 Oct 2012 11:38:27 +0100 > Damon McDougall <dam...@gm...> wrote: > >> How do people feel about perhaps adding a matplotlib version, mocking >> 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 > thread. > > 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. 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! :) -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom |
|
From: Paul T. <pau...@gm...> - 2012-10-18 23:24:21
|
On 10/18/12 5:45 AM, Damon McDougall wrote: > On Thu, Oct 18, 2012 at 10:10 AM, Alexander Eberspaecher > <ale...@ov...> wrote: >> Hello, >> >> On Wed, 17 Oct 2012 11:38:27 +0100 >> Damon McDougall <dam...@gm...> wrote: >> >>> How do people feel about perhaps adding a matplotlib version, mocking >>> 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 >> thread. >> >> 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. > > 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 |
|
From: Alexander E. <ale...@ov...> - 2012-10-18 11:54:13
|
On Thu, 18 Oct 2012 10:45:24 +0100 Damon McDougall <dam...@gm...> 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). 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 |
|
From: Mark L. <bre...@ya...> - 2012-10-18 19:13:45
|
On 18/10/2012 12:54, Alexander Eberspaecher wrote: > On Thu, 18 Oct 2012 10:45:24 +0100 > Damon McDougall <dam...@gm...> 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 be helpful http://www.youtube.com/watch?v=pXhcPJK5cMc, my apologies if it's already been mentioned. -- Cheers. Mark Lawrence. |
|
From: Damon M. <dam...@gm...> - 2012-10-18 20:25:22
|
On Thu, Oct 18, 2012 at 8:13 PM, Mark Lawrence <bre...@ya...> wrote: > On 18/10/2012 12:54, Alexander Eberspaecher wrote: >> On Thu, 18 Oct 2012 10:45:24 +0100 >> Damon McDougall <dam...@gm...> 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 > be helpful http://www.youtube.com/watch?v=pXhcPJK5cMc, my apologies if > it's already been mentioned. > > -- > Cheers. > > Mark Lawrence. Oh. My. God. That is unworldly. \begin{opinons} optparse is awful, and deprecated argparse is better, but has *serious* limitations getopt is also pretty bad \end{opinions} Thank you *so* much for posting that. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom |
