Choosing a num* library

It seems to me that most of the machinery about selecting which numerical package to import can be removed, correct? This is mainly in numerix/__init__.py. The rcParam can be kept around, but maybe we should warn if it's not set to numpy since it ain't gonna do what you asked...

It's not just "dead code" -- Leaving it in means that mpl will attempt to import numarray in the event that a stale .matplotlibrc file asks for it... It was the source of a real head-scratcher in a recent internal support request I got.

Thought I'd check on the list before I started, because I know the "numpification" process has some complexities I'm not too familiar with.

Cheers,
Mike

···

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm not 100% sure what you are referring to....

We decided to leave numerix as is for users who wrote scripts around it, eg

  import matplotlib.numerix as nx
  x = nx.arange(10).
  plot(x)

Of cource, mpl will use numpy under the hood, and should not import
numerix itself anywhere in mpl, but we did not want to break the code
of users who depended on it. If they set numerix to numarray, numerix
will give them numarray, but mpl will convert it to numpy in the
asarray calls. As long as the Numeric, numarray or numpy they are
using supports the array protocol we should have no troubles.

Or are you talking about something completely different?

JDH

···

On Dec 6, 2007 12:14 PM, Michael Droettboom <mdroe@...31...> wrote:

It seems to me that most of the machinery about selecting which
numerical package to import can be removed, correct? This is mainly in
numerix/__init__.py. The rcParam can be kept around, but maybe we
should warn if it's not set to numpy since it ain't gonna do what you
asked...

John Hunter wrote:

It seems to me that most of the machinery about selecting which
numerical package to import can be removed, correct? This is mainly in
numerix/__init__.py. The rcParam can be kept around, but maybe we
should warn if it's not set to numpy since it ain't gonna do what you
asked...

I'm not 100% sure what you are referring to....

We decided to leave numerix as is for users who wrote scripts around it, eg

  import matplotlib.numerix as nx
  x = nx.arange(10).
  plot(x)

Of cource, mpl will use numpy under the hood, and should not import
numerix itself anywhere in mpl, but we did not want to break the code
of users who depended on it. If they set numerix to numarray, numerix
will give them numarray, but mpl will convert it to numpy in the
asarray calls. As long as the Numeric, numarray or numpy they are
using supports the array protocol we should have no troubles.

Or are you talking about something completely different?

I think we're talking about the same thing, but I'm glad I asked.

The problem the user ran into was that they had "numerix: numarray" in matplotlibrc, but numarray wasn't installed. So importing matplotlib threw an ImportError attempting to import numarray. (pylab.py imports numerix.npyma, which imports numerix/__init__.py, which imports numarray). Not really a bug with matplotlib as such -- it's user error for setting numerix to numarray.

I had thought that since core matplotlib is "numpy" pure, the potential for others making this mistake could be removed by simply not having any code that imports numarray. However, as you seem to suggest, as long as there are reasons that someone would want numerix to wrap numarray, while matplotlib uses numpy, then I agree it should be left as is.

Cheers,
Mike

···

On Dec 6, 2007 12:14 PM, Michael Droettboom <mdroe@...31...> wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA