Skip to content

BUG: loc-based indexing with float keys fails inconsistently if index is integer close to numeric limits #53290

@wence-

Description

@wence-

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugClosing CandidateMay be closeable, needs more eyeballsIndexingRelated to indexing on series/frames, not to indexes themselves

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions