Issue 1:
Original ticket http://projects.scipy.org/numpy/ticket/1064 on 2009-03-23 by trac user changimeno, assigned to @charris.

interp(x, xp, fp, left=None, right=None)

the "right"--parameter option does not work properly.

Example:

In [2]: x = arange(4)*2 + 2

In [3]: y=x**2
In [4]: xx = arange(11)

In [5]: x
Out[5]: array([2, 4, 6, 8])

In [6]: y
Out[6]: array([ 4, 16, 36, 64])

In [7]: xx
Out[7]: array([ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10])

In [14]: numpy.interp(xx,x,y)
Out[14]: array([ 4., 4., 4., 10., 16., 26., 36., 50., 64., 64., 64.]) #---->>>> RIGHT!!!!

In [15]: numpy.interp(xx,x,y,left=0.)
Out[15]: array([ 0., 0., 4., 10., 16., 26., 36., 50., 64., 64., 64.]) #---->>>> RIGHT!!!!

In [16]: numpy.interp(xx,x,y,left=0.,right=0.)
Out[16]: array([ 0., 0., 4., 10., 16., 26., 36., 50., 0., 0., 0.]) #---->>>> WRONG!!!!

numpy.interp set the vales of the interpolated array (yy) for "xx[i] >= x[len(x)-1]" to the given RIGHT value. So, the last GOOD value (xx[i] == x[len(x)-1]) is wrongly set to the RIGHT value instead of the proper value yy[i] = y[len(x)-1].

I edited the file numpy/lib/src/_compiled_base.c and fixed this bug (see attachment). Now

In [19]: numpy.interp(xx,x,y,0.,0.)
Out[19]: array([ 0., 0., 4., 10., 16., 26., 36., 50., 64., 0., 0.]) #---->>>> RIGHT!!!!

My only worry is that I modified "binary_search" together with "arr_interp" and I do not know if this function is called by other routines and whether this modification can alter the results.

diff
> /* sgg */
> else if (dval > dlist [len-1])
> result = len ;
> /* sgg */
448c454,455
< else if (indx >= lenxp - 1)

---
> /*sgg else if (indx >= lenxp - 1) */
> else if (indx > lenxp - 1)

Cheers,

Chan

Issue 2:
Cross-compiling scipy and other projects that depend on numpy's distutils is a huge pain right now, because to do it [in addition to lots of other details that you have to get right] you have to have both a native and cross-compiled version of numpy installed. It seems pretty unreasonable that I need a native version of numpy installed to compile scipy. One might ask, why is this needed?

Well, scipy's setup.py uses numpy's distutils fork for the fortran support (I think). Because numpy.distutils is a subpackage of numpy, if you're working with a cross-compiled version of numpy, it eventually tries to import some .so that wasn't compiled for your host and everything dies -- thus you have to have a native numpy installed to allow numpy.distutils to import correctly.

As far as I can tell, numpy's distutils fork is pure python and doesn't actually use anything else in numpy itself, and so is completely separable from numpy. If it were its own top-level package that scipy et al could use, then cross-compiling would be significantly less tricky.

The mechanics of this would work like so:

contents of numpy.distutils would be moved to 'numpy_distutils' package

importing numpy.distutils would raise a deprecation warning and redirect to numpy_distutils, probably using import hook magic

scipy and other packages would now utilize numpy_distutils instead of numpy.distutils at build time

Initially, I considered proposing creating a separate pypi package for numpy_distutils, but I expect that would be more trouble than it's worth. One could also propose creating a new PEP 517 build backend, or move to cmake, or other huge changes, but those also seem more trouble than they're worth.

Thanks for your consideration.