perry at stsci.edu
Wed Feb 9 09:26:32 CST 2005
Travis Oliphant wrote:
> > It's interesting that SciPy and matplotlib really do have much the
> > same goal, but taken from different tacks: SciPy focused on the
> > computational functionality, and matplotlib on the plotting. However,
> > what's become really clear in this discussion is that a good
> > scientific math environment really needs both, and they need to be
> > well integrated.
> The problem was that we needed someone like John to join us on the scipy
> effort to get the plotting working well. Our team lacked someone with
> his skill. All of us working on SciPy would have loved to work with
> him. So, I have nothing but respect for John and his efforts. I just
> wish we at SciPy were better recruiters :-)
In John's defense, there was already a scipy-related plotting project
underway (chaco). It wouldn't be surprising for someone to conclude
that an alternative plotting project wouldn't be all that welcome
(and John has already explained why he didn't get involved with
> 4) The numarray C-API seems way too big. There are so many, seemingly
> repeated calls that seem to do the same thing. Are all of these API
> calls really necessary?
I'm guessing you are talking all the various ways of accessing elements
in an array. It's not clear to us that these are needed either (I have a
feeling that no one is using some of the alternatives). The reasons
behind them were to allow C programs a way of accessing arrays with
byteswapped or misaligned values without having to do those operations
explicitly themselves. Various options were provided so that one could
trade off memory usage against speed (e.g., macros vs function call/pixel).
I think the reasons are fairly well given in the manual. I don't know
if that justifies the existence of all of them and we've considered
removing some of them.
More information about the Numpy-discussion