wasm-demo/demo/ermis-f/python_m/cur/0382

55 lines
1.9 KiB
Plaintext

From: olipt at mayo.edu (Travis Oliphant)
Date: Wed, 28 Apr 1999 08:42:18 -0500
Subject: Bug or Feature?
In-Reply-To: <m3wvyxgtwr.fsf@pcrm.win.tue.nl>
References: <37208E69.4B022E0C@mediaone.net> <7fr3eg$bqr@world1.bellatlantic.net> <m3ogkbx0s8.fsf@pcrm.win.tue.nl> <7g4jkg$llc@ds2.acs.ucalgary.ca> <m3wvyxgtwr.fsf@pcrm.win.tue.nl>
Message-ID: <Pine.LNX.4.04.9904280837320.1836-100000@us2.mayo.edu>
Content-Length: 1455
X-UID: 382
On 28 Apr 1999, Stephan Houben wrote:
> nascheme at ucalgary.ca (Neil Schemenauer) writes:
>
> > I think the Numeric array should be added as a standard module.
> > This is on the Python TODO list. I may do it myself it I get
> > time. I don't know how much of Numeric should be added. Any
> > comments?
>
> That would be cool.
Here, here.
> As you see, the "Numerical" part is by far the biggest, and if you make it
> a standard part of Python, you increase the size of the standard distribution
> by quite much. So that might be a reason not to do it.
>
> On the other hand, the biggest parts of "Numeric" are the blas lite and the
> lapack lite, which together make up 1503K. So perhaps you could rely on
> a preinsatalled BLAS and LAPACK, just as the standard Python distribution
> relies on the readline library.
>
Having the Numeric extensions as part of the core would be excellent. I'd
be interested to here from knowledgeable people (people who decide these
things, i.e. Guido) what the arguments against doing so are.
Not including blas and lapack in the core is fine as long as the user is
informed of the need to get BLAS and LAPACK on their machine. It would be
nice if you could count on someone using Numeric to have a full
implementation of BLAS and LAPACK on their machine. Quite a few other
libraries out there that would be nice extensions to Numeric depend on
subroutines in those libraries.
Travis Oliphant