[SciPy-dev] numpy - dual.py problems

[Travis Oliphant]

Arnd Baecker wrote:

>Hi,
>
>
>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....

-Travis