[sugar] On Matplotlib on the XO

[Arjun Sarwal]

Fernando, John,

I do believe that something like Matplotlib would be very useful in
the context of the various graphing/plotting functions that I was
looking for doing. Measure captures electrical signals and also logs
signal values at specified intervals.

Graphical representation of both kinds of information can quite
wonderfully be carried out using Matplotlib. The size (matplotlib and
related dependencies, the only one that isn't already on the XO being
pytz) issue is one that I had been thinking about, but I see you have
put quite a lot of thought and work into that, so I guess we should be
able to take care of that.

Thinking a little further and discussing with the author of Acoustic
Measure Activity (that calculates the distance between 2 XOs)-Benjamin
Schwartz (cced here), we believe that the functionality of such a tool
would extend to be useful for graphing/plotting any data -- be it
generated from Measure or from Acoustic Measure Activity ( a log of
distance recordings at various points of time) or any other Activity
in the future.

The general idea that emerges is that it'd be very useful to have a
spreadsheet like interface which loads the csv file generated by say
Measure or Acoustic Measure and one can subsequently, from within the
spreadsheet interface, select data sets and generate various
plots/graphs using matplotlib.

I have also cced Manusheel Gupta here who is leading the efforts on
the Spreadsheet Activity and I would like to see this conversation go
further.

best regards,
Arjun



> From: Ivan Krsti? <krstic at solarsail.hcs.harvard.edu>
> Subject: Re: [sugar] On Matploblib for the XO
> To: Fernando Perez <Fernando.Perez at colorado.edu>
> Cc: John Hunter <jdh2358 at gmail.com>, Sugar ml <sugar at lists.laptop.org>
> Message-ID:
>         <076EE637-8027-4787-9E3D-7900A4F17051 at solarsail.hcs.harvard.edu>
> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes
>
> Hi Fernando, John,
>
> I wanted to restart the discussion around Matplotlib, IPython, and the
> entire scientific/mathematical environment idea on OLPC laptops. I
> responded to the mail below previously, but I'm not sure what happened
> after that.
>
> Arjun Sarwal, who is the author of the Measure activity that I
> demonstrated at SciPy, has recently been looking into plotting
> libraries for the XO, and (understandably) Matplotlib caught his eye.
> Arjun and others -- I'm forwarding Fernando's original e-mail below
> for your reference.
>
> I am in full support of the Matplotlib/sympy/IPython combo getting up
> and running on the XO, on the way to an awesome complete sci/math
> environment. I hope Fernando and John will still consider giving us a
> hand.
>
> Thanks!
>
> Cheers,
> Ivan.
>
>
>
> On Aug 19, 2007, at 10:38 PM, Fernando Perez wrote:
> > In order to estimate the sizes one could expect to see with a
> > matplotlib build for the OLPC, I tried to build it with only the GTK
> > Cairo backend (though AGG still needs to be built for internal use,
> > since it's everywhere) and then added GTKAgg as well.  These were the
> > sizes I got:
> >
> > tlon[build]> d *.tgz
> > /home/installers/src/scipy/matplotlib/build
> > -rw-r--r-- 1 fperez 4674627 2007-08-19 19:43 mpl_cairo_only.tgz
> > -rw-r--r-- 1 fperez 5555121 2007-08-19 20:25 mpl_with_gtkagg.tgz
> >
> > However, the Cairo backend is still not very mature and doesn't
> > perform very well; in particular it lacks proper transparency support,
> > so using GTK+Agg might be a better alternative.  These sizes are what
> > I got from doing a build and quickly removing some obvious things (as
> > well as deactivating support for Qt, Tk and WX).  It's quite likely
> > that John might suggest how to trim it further, I was afraid of
> > cutting things I shouldn't so I went in conservatively.
> >
> > John will correct me if I'm wrong, but I think that since you already
> > ship a real GTK, the GTKAgg backend should work just fine.  Agg is
> > very fast, has extremely high quality, and the GTKAgg backend is
> > probably the most mature and widely tested one of all.  If 5.5 MB is
> > an acceptable size for you, here are the numbers for the other pieces
> > of the puzzle.
> >
> > For IPython:
> >
> > -rw-r--r-- 1 fperez 713456 2007-08-19 21:18
> > ipython_installed_nodocs.tgz
> > -rw-r--r-- 1 fperez 808717 2007-08-19 21:16 ipython_installed.tgz
> >
> > IPython comes in at a bit under 1MB, keeping the source and HTML
> > manual but removing the PDF docs.  Removing the HTML manual saves
> > about 100k.
> >
> > As for sympy, I just installed it and tarred it:
> >
> > -rw-r--r--  1 fperez 1686428 2007-08-19 21:21 sympy_installed.tgz
> >
> > I'm not familiar enough with it to know what can be cut out, though I
> > know their 3d plotting is OpenGL based, so that can probably go.
> > You'd need to get the sympy team involved, though Ondrej sounded
> > enthusiastic when I spoke with him.
> >
> >
> > So it looks like the ipython/matplotlib/sympy combo would cost you
> > around 8MB total.  That's not counting numpy, but you told me you'd
> > already decided to include that for other reasons (matplotlib can't
> > run without numpy, nor can one do many key numerical operations
> > without it at reasonable speeds).
> >
> > One final question: have you run any numpy code on the olpc to get an
> > idea for its floating-point performance?  Here are a couple of
> > reference points and an easy way to get some timing info:
> >
> > On my 5 1/2 year old laptop, a Pentium-III at 1.13 GHz with only SSE
> > (no SSE2) instructions, a typical test time for numpy is:
> >
> > maqroll[~]> time python -c "import numpy;numpy.test(10)" > & /dev/null
> > 3.484u 0.196s 0:03.73 98.3%     0+0k 0+0io 0pf+0w
> >
> > On my desktop, a dual-core Athlon 4400 (2.2GHz clock):
> >
> > tlon[~/tmp]> time python -c "import numpy;numpy.test(10)" > & /dev/
> > null
> > 1.420u 0.144s 0:01.56 100.0%    0+0k 0+0io 0pf+0w
> >
> >
> > My laptop is perfectly usable as a matplotlib/numpy computing
> > environment at these speed, and you could probably take a factor of 4
> > hit on performance and still be OK for the numerics.  The graphics may
> > get a little unpleasant if your box is much more than 2-4 times slower
> > than my laptop, I suspect, but it might be OK. Also, I think that if
> > one disables Agg and uses only the plain GTK backend, things go faster
> > (John will correct me if I'm wrong).
> >
> >
> > In any case, I hope you find this useful.  Feel free to forward it to
> > those on your team you deem appropriate.
>
> --
> Ivan Krsti? <krstic at solarsail.hcs.harvard.edu> | http://radian.org
>