There are some compatibility and doc issues and perhaps a bug in numarray.searchsorted. The compatibility issue is that Numeric.searchsorted(a, v) accepts either a sequence or scalar value for v. Numarray.searchsorted accepts only sequence values. Second, the doc issue. The docstring for numarray.searchsorted states:: searchsorted(bins, values) searchsort(bins, values) returns the array of greatest indices 'i' such that each values[i] <= bins[i]. I assume that should really read something more like:: searchsorted(bins, values) searchsort(bins, values) returns the array A[j] of greatest indices 'i' such that each values[j] <= bins[i]. Third, the possible bug: # na = numarray, np = NumPy
na.searchsorted([1,2,3,4], [2.5, 3.5]) array([1, 2]) np.searchsorted([1,2,3,4], [2.5, 3.5]) array([2, 3])
Hmmm. It appears that numarray result does match the numarray docs, (at least as I read them), but I like the Numeric behaviour better. The Numeric behaviour also matches the behaviour of the bisect module, which is described as:: bisect = bisect_right(a, x, lo=0, hi=None) Return the index where to insert item x in list a, assuming a is sorted. The return value i is such that all e in a[:i] have e <= x, and all e in a[i:] have e > x. So if x already appears in the list, i points just beyond the rightmost x already there. Optional args lo (default 0) and hi (default len(a)) bound the slice of a to be searched. I'd recomend matching the behaviour of the two existing modules (bisect and Numeric). -tim