-
- Notifications
You must be signed in to change notification settings - Fork 19.2k
Description
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 s = pd.Series([1, 2, 3, 4], index=[2**63 - 1, 2**63 - 10, 2**63 - 100, 2**63 - 1000]) for i in [1, 10, 100, 1000]: index = 2**63 - i findex = float(index) # lossy for fidx, iidx in ((findex, index), ([findex], [index])): try: value = s.loc[fidx] print(f"Found {fidx} (2**63 - {i})") print(f"Got\n{value}") print(f"Expect\n{s.loc[iidx]}") except KeyError: print(f"Didn't find {fidx} (2**63 - {i})")Issue Description
Running this produces:
Didn't find 9.223372036854776e+18 (2**63 - 1) Found [9.223372036854776e+18] (2**63 - 1) Got 9223372036854775708 3 dtype: int64 Expect 9223372036854775807 1 dtype: int64 Didn't find 9.223372036854776e+18 (2**63 - 10) Found [9.223372036854776e+18] (2**63 - 10) Got 9223372036854775708 3 dtype: int64 Expect 9223372036854775798 2 dtype: int64 Didn't find 9.223372036854776e+18 (2**63 - 100) Found [9.223372036854776e+18] (2**63 - 100) Got 9223372036854775708 3 dtype: int64 Expect 9223372036854775708 3 dtype: int64 Didn't find 9.223372036854775e+18 (2**63 - 1000) Found [9.223372036854775e+18] (2**63 - 1000) Got 9223372036854774808 4 dtype: int64 Expect 9223372036854774808 4 dtype: int64 When asking for a single scalar float, since the conversion is lossy, no .loc produces an answer (in the guts, there's an overflow-error when casting from the float back to an integer, since the nearest integer to float(2**63-1) is 2**63, similarly for -10 and -100, whereas float(2**63 - 1000) is representable as an integer, but is not 2**63 - 1000).
This is the behaviour I would expect, since the index does not contain the requested keys.
In contrast when indexing with a singleton list of the same values, indexing is always successful but only produces the correct answer for 2**63 - 100 and 2**63 - 1000. For 2**63 - 1 and 2**63 - 10 the entry for 2**63 - 100 is returned instead.
Aside: note that this is not symmetric: if the index is floats and we ask for an integer key with loc the behaviour is as if the key is cast to float first and then looked for.
Expected Behavior
Looking for a key that doesn't exist should consistently produce a keyerror. At the very least, these two broadly equivalent ways of indexing should have the same semantics.
FWIW, I would argue that the best thing is to deprecate lossy casting (e.g. cross-kind) in label-based indexing, and remove it in pandas 3. The semantics of the indexing are already hard enough to understand without having to have intimate knowledge of the behaviour of numpy's type promotion rules and their interaction with numeric representations. [Yes, I know that Python hashes small ints and small integral floats the same, I also think that was a bad decision]
Installed Versions
INSTALLED VERSIONS
commit : 37ea63d
python : 3.11.3.final.0
python-bits : 64
OS : Linux
OS-release : 5.19.0-41-generic
Version : #42~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 18 17:40:00 UTC 2
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_GB.UTF-8
LOCALE : en_GB.UTF-8
pandas : 2.0.1
numpy : 1.24.3
pytz : 2023.3
dateutil : 2.8.2
setuptools : 67.7.2
pip : 23.1.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 : 8.13.2
pandas_datareader: None
bs4 : None
bottleneck : None
brotli : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
snappy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2023.3
qtpy : None
pyqt5 : None