Scientific Libraries in Python
Travis Oliphant
oliphant at ee.byu.edu
Mon Nov 26 22:27:46 CET 2001
> > Now... licensing. While the top two projects are both less...restrictive,
> > I reluctantly have to concede that these lists have an awful lot of GPL
> > code that would be difficult or impossible to do without. The eventual
> > license, therefore, looks like GPL or (if we're lucky) LGPL. I can even
> > live with that if it'll get me a coherent scientific library, but others
> > might have a different viewpoint. What would those viewpoints be?
>
> As regards the MayaVi license, MayaVi was developed for the community
> so I didn't want someone to take the MayaVi codebase, use it for their
> own purposes and not give back anything in terms of code to the
> community. That is why I chose the GPL. However, the GPL does force
> everyone else who links to it to be GPL. I guess LGPL might also work
> but I really don't know. I'll try to give it some thought. Anyway, I
> am not sure you want to put all packages into one huge super package.
> It would be a nightmare to package/distribute! I'd really pity the
> person who'd have to maintain such a beast.
> prabhu
The LGPL does what it seems like you want you want (doesn't allow people
to take your particular code, alter it slightly and make it proprietary),
but it also allows people to release a larger application which only links
to your code under a non-GPL license.
My understanding is that if you keep the GPL, then folks could build an
interface, but they could not distribute mayavi with the interface under
anything but the GPL.
That's why I much prefer the LGPL to the GPL for tools which could be
"hooked together."
As to the packaging issue, it is true that maintainance can be a problem
to set up intially. While a "distribution" could be considered that
includes all of the important programs, I think the right solution is to
define a set of interfaces in various problem domains which other packages
can use.
SciPy is aiming to be as complete as possible --- but this really means, a
complete set of interfaces and defined user-interactions, with reference
implementations, and tests, and a packaging structure that allows other
packages to be inserted in and potentially maintained by other people.
Enthought is also interested in distributing an "everything included"
distribution which contains many of the above packages you mentioned, but
to distribute such a beast which all worked together dynamically, my
understanding is that none of the included packages could be GPL (LGPL
would be O.K.)
THE GSL
=============
Many of the GSL routines are already in SciPy. Here is a detailed list:
The outline parallels the GSL reference.
Mathematical Functions:
* Constants: Constants are easily defined, but presently
pi, e, inf, nan, are defined.
* Elementary Functions: from Numeric
* Small integer powers: from Numeric
* Testing the sign of numbers: sign
* Testing for odd and even numbers: x % 2 == 0
* Maximum and minimum functions: max, min, amax, amin
Complex Numbers: all handled by Numeric including inverse hyperbolic
functions
Roots of Polynomials:
polynomials are represented by sequences of coefficients
* Polynomial Evaluations: polyval, polyder
* Quadratic Equations: (not specifically) --- see roots
* Cubic equations: (not specificially) --- see roots
* General polynomial: roots
Special Functions: (all defined over arrays for Numeric).
(using special.general_function any function which returns a
scalar can be converted to broadcast over arrays).
* Airy functions: yes (no zeros)
* Bessel functions: yes (no zeros, or spherical bessel)
* Clausen functions: not specifically (but dilogarithm is there --
not for complex numbers though, spence.)
* Coulomb functions: no
* Coupling Coefficients: no
* Dawson function: dawsn
* Debye Functions: no
* Dilogarithm: spence (no complex argument)
* Elliptic integrals: yes
* Elliptic functions: yes
* Error functions: yes
* Exponential functions: yes
* Exponential integrals: yes
* Fermi-Dirac integrals: don't think so
* Gamma functions: yes
* Gegenbauer functions: yes (through scipy.integrate.orthogonal)
* Hypergeometric functions: yes
* Laguerre functions: yes (through scipy.integrate.orthogonal)
* Lambert W Functions: no
* Legendre Functions: yes
* Spherical Harmonics: (not directly)
* Logarithm: yes
* Power functions: yes
* Psi (digamma): yes
* Synchrotron: no
* Transport: no
* Trigonometric: yes
* Zeta: yes
Vectors and Matrices: Numeric (Matrix)
Permutations: Not specifically
Sorting: sort, argsort
BLAS interface: linalg.cblas, linalg.fblas
Linear Algebra: (linalg) --- interface to LAPACK
* LU: yes
* QR: yes
* SVD: yes
* Cholesky: yes
* Tridiagonal decomposition (Schur): yes
* Bidiaonlization: not sure (is this in LAPACK?)
* Householder solve (through lapack)
* tridiagonal systems: no
Eigensystems: yes
Fast Fourier Transforms: yes
Numerical Integration: yes (all)
Random Number Generation: yes (RandomArray)
Quasi-Random Sequences: (random in standard library?)
Random Number Distributions: many (RandomArray) -- not all
Statistics: most of these and more
Histograms: yes (not 2-D though)
N-tuples: yes, from Python
Monte-Carlo Integration: no
Simulated Annealing: no
Ordinary Differential equations: yes
Interpolation: yes
Numerical Differentition: yes
Chebyshev Approximations: no
Series Accelerations: no
Discrete Hankel Transforms: no
Root-Finding: yes (multi-dimensional)
Optimization: yes (multi-dimensional)
Least-squares fitting: yes
Nonlinear least-squares fitting: yes
Physical constants: no (easily defined)
IEEE floating-point arithmetic: relies on platform
So, asided from a few specialized applications, most everything in the
GSL is already included in SciPy. It wouldn't take long to add the extra
functionality if there were a demand for it.
Any takers?
-Travis
More information about the Python-list
mailing list