[SciPy-dev] numpy - dual.py problems
oliphant.travis at ieee.org
Sat Jan 7 21:58:32 CST 2006
Arnd Baecker wrote:
>A typical scenario for "end-users" is the following:
>- people will have Numeric/numarray + old scipy/old new scipy
> on their machines.
> In many cases this is the system-wide installation as done by
> the root-user (eg. via some package manager)
> The "end-user" has no root rights.
>- The "end-user" hears about the great progress wrt numpy/scipy combo
> and wants to test it out.
> He downloads numpy and installs it to some place in his
> homedirectory via
> python setup.py install --prefix=<~/somewhere>
> and sets his PYTHONPATH accordingly
>- Then `import numpy` will work, but a
> `numpy.test(10)` will fail because `dual.py`
> picks his old scipy (which will be visible from the
> traceback, if he looks carefully at the path names).
>- Consequence, the "end-user" will either ask a question on the
> mailing list or just quit his experiment and continue
> to work with his old installation.
This has been fixed now so that it will only use scipy if it can find
version 0.4.4 or higher...
>Later on Travis' wrote:
>"""The solution is that now to get at functions that are in both numpy and
>scipy and you want the scipy ones first and default to the numpy ones if
>scipy is not installed, there is a numpy.dual module that must be
>loaded separately that contains all the overlapping functions."""
>I think this is fine, if a user does this in his own code,
>but I have found the following `from numpy.dual import`s within numpy
> core/defmatrix.py: from numpy.dual import inv
> lib/polynomial.py: from numpy.dual import eigvals, lstsq
> lib/mlab.py:from numpy.dual import eig, svd
> lib/function_base.py: from numpy.dual import i0
BTW, these are all done inside of a function call. I want to be able
to use the special.i0 method when its available inside numpy (for kaiser
window). I want to be able to use a different inverse for matrix
inverses and better eig and svd for polynomial root finding.
So, I don't see this concept of enhancing internal functions going
away. Now, I don't see the current numpy.dual approach as the
*be-all*. I think it can be improved on. In fact, I suppose some
mechanism for registering replacement functions should be created
instead of giving special place to SciPy. SciPy could then call these
functions. This could all be done inside of numpy.dual. So, I think
the right structure is there....
More information about the Scipy-dev