On 10/18/12 5:45 AM, Damon McDougall wrote: > On Thu, Oct 18, 2012 at 10:10 AM, Alexander Eberspaecher > <alexander.eberspaec...@ovgu.de> wrote: >> Hello, >> >> On Wed, 17 Oct 2012 11:38:27 +0100 >> Damon McDougall <damon.mcdoug...@gmail.com> 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 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
