I logged this on Source Forge. Thanks for the comments.
On Fri, 2003-09-26 at 13:06, Tim Hochberg wrote:
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])
np.searchsorted([1,2,3,4], [2.5, 3.5])
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
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).
This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Numpy-discussion mailing list Numpyemail@example.com https://lists.sourceforge.net/lists/listinfo/numpy-discussion