BUG: RangeIndex.searchsorted() when using a negative step

[michaelpradel]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import pandas as pd
ri = pd.RangeIndex(10, 0, -1)
result = ri.searchsorted(5)
print(result) # prints 5 in current main branch, but 0 in pandas 2.2.2

Issue Description

The behavior of the above example has changed with #58376, which was supposed to only improve performance. My understanding of the API documentation is that the new behavior is correct, i.e., #58376 coincidentally fixed this bug.

However, the bug is still present in the latest version (2.2.2). It may be worth backporting a fix into the 2.2.x branch.

Expected Behavior

The index is [10, 9, 8, 7, 6, 5, 4, 3, 2, 1] . Since the RangeIndex is sorted in descending order, searchsorted(5) should return the index where 5 would fit, which is 5. However, pandas 2.2.2 returns 0.

Installed Versions

INSTALLED VERSIONS ------------------ commit : d9cdd2e python : 3.11.6.final.0 python-bits : 64 OS : Linux OS-release : 6.5.0-28-generic Version : #29-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 28 23:46:48 UTC 2024 machine : x86_64 processor : x86_64 byteorder : little LC_ALL : None LANG : en_US.UTF-8 LOCALE : en_US.UTF-8

pandas : 2.2.2
numpy : 1.26.4
pytz : 2024.1
dateutil : 2.9.0.post0
setuptools : 68.1.2
pip : 23.2
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : None
pandas_datareader : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
python-calamine : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2024.1
qtpy : None
pyqt5 : None

[Aloqeely]

This is indeed fixed on main.

@mroeschke what are your thoughts on this and #58644? And if a backport is appropriate then should we change the whatsnew entry from a performance improvement to a bug fix?

[mroeschke]

Thanks for the suggestion. Unfortunately I don't think #58376 is likely to be backported to 2.2.x since it was not a regression bug fix.

Additionally, it's looking like there may not be another release 2.x and that 3.0 (which includes this fix) will be the next release

[michaelpradel]

Okay, makes sense.

Nit: You may want to update the "whatsnew" of #58376 to let people know that it's more than a performance improvement, but also a fix to this bug.