numarray, numpy, numeric, numerix, scipy,...

Community matplotlib-users
1

I don't have one and I don't think it's good design for my

    > software installer to go creating one for people as part of
    > a larger software installation. I think that sniffing would
    > be a better (complementary, not replacement) solution, so
    > that whichever the user decides to install, it just works.

You have a few options. You can set the rc parameters inside your
script, you do not need to change a system wide rc file

  from matplotlib import rcParams
  rcParams['numerix'] = 'numpy'
  #...now import matplotlib.numerix, pylab, etc...

You can also provide per directory configuration files. Ie, you can
create a matplotlibrc file (http://matplotlib.sf.net/matplotlibrc) in
the same dir as your main-level script, and it will respect that one
so you need not worry about overriding a system rc file when you
install your software.

    > For now I will select numpy. Is that the one that Matplotlib
    > looks for first?

There are two issues here: build time configuration and run time
configuration. We used to do neither, now at built time we try and
find one of numpy/numarray/Numeric (in that order) and then generate
an rc file with the found one as the default.

We could also do run time dynamic imports. I'm of two minds here: the
more we try and do automatically, the harder it is to detect and fix
bugs and problems when they arise. The setup is already pretty
complex, if we are automatically choosing numerix and backend
settings, I could see some difficulties in debugging problems. But I
can see the advantages to it as well...

JDH

2

John Hunter wrote:

    > I don't have one and I don't think it's good design for my
    > software installer to go creating one for people as part of
    > a larger software installation. I think that sniffing would
    > be a better (complementary, not replacement) solution, so
    > that whichever the user decides to install, it just works.

You have a few options. You can set the rc parameters inside your
script, you do not need to change a system wide rc file

  from matplotlib import rcParams
  rcParams['numerix'] = 'numpy'
  #...now import matplotlib.numerix, pylab, etc...
  

That's what I'm currently using, actually (see start of this thread).

You can also provide per directory configuration files. Ie, you can
create a matplotlibrc file (http://matplotlib.sf.net/matplotlibrc) in
the same dir as your main-level script, and it will respect that one
so you need not worry about overriding a system rc file when you
install your software.
  

I already have a config file for our application, if I did anything like this it would be to add an extra option to our existing config file, not create an additional one. Although this one was nice to know.

    > For now I will select numpy. Is that the one that Matplotlib
    > looks for first?

There are two issues here: build time configuration and run time
configuration. We used to do neither, now at built time we try and
find one of numpy/numarray/Numeric (in that order) and then generate
an rc file with the found one as the default.

We could also do run time dynamic imports. I'm of two minds here: the
more we try and do automatically, the harder it is to detect and fix
bugs and problems when they arise. The setup is already pretty
complex, if we are automatically choosing numerix and backend
settings, I could see some difficulties in debugging problems. But I
can see the advantages to it as well...
  

I'm thinking that *if* a preference has been specified, that should be used (and possibly throw and error if it fails). But if no preference is specified, then a sniffing approach should work, something like the following, which has worked for me without any issues so far, on a number of different platforms. This approach would facilitate debugging, knowing that you can force a particular numeric-array import.

try:
    import psyco
    psyco.full()
    print "Running with PSYCO optimisation..."
except ImportError:
    pass

···

--
John Pye
Department of Mechanical and Manufacturing Engineering
University of New South Wales, Sydney, Australia

3

Hi John

I implemented the sniffing for num* libraries in our own code, which
maybe is of interest to other users:
https://pse.cheme.cmu.edu/svn-view/ascend/code/trunk/pygtk/interface/gtkbrowser.py?rev=578&view=markup

It's in about the second screenful there.

I can see the reasoning for not having this code inside matplotlib, but
for me, this does help to ease installation headaches for endusers.

Cheers
JP

John Hunter wrote:

···

We could also do run time dynamic imports. I'm of two minds here: the
more we try and do automatically, the harder it is to detect and fix
bugs and problems when they arise. The setup is already pretty
complex, if we are automatically choosing numerix and backend
settings, I could see some difficulties in debugging problems. But I
can see the advantages to it as well...

4

John Pye wrote:

I implemented the sniffing for num* libraries in our own code, which
maybe is of interest to other users:

I did something similar for my wxPython FloatCanvas, but I've been thinking that it should do something different:

Rather than a pre-defined hierarchy of preference for package, perhaps it could start by check if any of the num* packages are loaded already. That way a user could so:

import Numeric
import matplotlib

and MPL would use the Numeric that was already imported, rather than another.

Just a thought.

-Chris

PS: I'm really looking forward to when we all just use numpy!

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

5

+1 on this way of working.
I think you'd only want to trigger this if numerix was set to something like 'imported' or 'automatic'.
However, if there's going to be a mass movement to numpy in the near future, I think this change should be a low priority.
Gary R.

Christopher Barker wrote:

···

John Pye wrote:

I implemented the sniffing for num* libraries in our own code, which
maybe is of interest to other users:

I did something similar for my wxPython FloatCanvas, but I've been thinking that it should do something different:

Rather than a pre-defined hierarchy of preference for package, perhaps it could start by check if any of the num* packages are loaded already. That way a user could so:

import Numeric
import matplotlib

and MPL would use the Numeric that was already imported, rather than another.

Just a thought.

-Chris

PS: I'm really looking forward to when we all just use numpy!