[Numpy-discussion] numpy/scipy transition

[Arnd Baecker]

Hi Chris,

On Wed, 15 Feb 2006, Christopher Barker wrote:

> Arnd Baecker wrote:
> > - we need scipy.xplt
> >   (matplotlib is still no option at this point)
>
> Why not? just curious.

That's a slightly longer story, but since you asked ;-):

First, I should emphasize that I really think that matplotlib
is extremely good, the quality of the plots is superb!
Also it is used a lot in our group for research.

However, in our opinion we cannot use matplotlib for our course
for the following two main reasons
  (a) some (for us crucial) bugs
  (b) speed

Concerning (a), the most crucial problem is the double-buffering
problem. This did not exist with matplotlib 0.82
and has been reported several times, the last one being
   http://sourceforge.net/mailarchive/forum.php?thread_id=9559204&forum_id=33405
The presently suggested work-around is to use TkAgg as backend.
However, the TkAgg backend is slower than any other backend.

We cannot tell our students to use TkAgg for one problem
and switch to WXAgg for another problem - they already
struggle enough with learning python
(there are several first-time-programmers as well)
and the hard physics problems we give them ;-).
To us this double-buffering problem is the show-stopper number one.
Unfortunately, I don't understand the internals of matplotlib
well enough to help with tracking this one down.

There are a couple of further problems which we reported,
but have fallen through the cracks - no complaint,
that's how things are. But it is (from our point of view)
not worth talking about them again as long as the
double-buffering problem is still there.

On the speed side (b): we have been using scipy.xplt
and even that (though generally considered to be really fast)
is not as fast as for example pgplot ;-).
In addition many of our students run older maschines
starting from PIIIs (I think the PIIs are gone by now,
but two years ago quite a few still used them).
So this is something to be kept in mind when talking
about speed.

We hired a student to do the conversion of our exercises
from scipy.xplt to matplotlib and look into some of the speed issues.
With John Hunters help this got pretty far,
  http://sourceforge.net/mailarchive/forum.php?thread_id=8153459&forum_id=33405
  http://sourceforge.net/mailarchive/forum.php?thread_id=8185639&forum_id=33405
  http://sourceforge.net/mailarchive/forum.php?thread_id=8243168&forum_id=33405
  http://sourceforge.net/mailarchive/forum.php?thread_id=8346924&forum_id=33405
  http://sourceforge.net/mailarchive/forum.php?thread_id=8498518&forum_id=33405
  http://sourceforge.net/mailarchive/forum.php?thread_id=8728580&forum_id=33405

I think that there was no further message after this and
the whole approach has not yet been incorporated into MPL.
To me it made the impression that it was very close to a good
solution, and I would be willing to take up this issue again
if there is a chance that it gets integrated into MPL.

So, presumably many of the speed issues could be resolved
The price to be paid is in some cases a factor of two more
lines of code for the plotting (compared to scipy.xplt).
By using a bit more encapsulation, this could surely be overcome.

Ok, I hope I could roughly explain why we think that
we cannot yet use Matplotlib -  it is really almost there,
so I remain very optimistic that at least next year we will
be using it as the default plotting environment.

Best, Arnd