BUG: assert_series_equal ignores atol/rtol when comparing integer and float dtypes with check_dtype=False

[Parth1353]

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

left = pd.Series([2**60 + 1], dtype="int64")
right = pd.Series([float(2**60)], dtype="float64")  # exactly 2**60, so the two values are 1 apart

pd.testing.assert_series_equal(
    left, right, check_dtype=False, check_exact=False, rtol=0, atol=0.5
)
# no AssertionError, even though the values are 1 apart and atol is 0.5

Issue Description

With check_dtype=False and check_exact=False, comparing an integer Series against a float Series ignores atol and rtol completely.

assert_almost_equal short-circuits on array_equivalent before any tolerance logic runs. array_equivalent casts the two arrays to a common dtype, so 2**60 + 1 becomes float(2**60), the arrays compare equal, and the elementwise comparison that would apply rtol/atol is never reached.

The same thing happens with the nullable dtypes (Int64 vs Float64), and through assert_frame_equal and assert_index_equal.

This is the same symptom as #66400 but a different code path. #66400 was the double cast inside assert_almost_equal itself, which is fixed in #66696; this one happens earlier, before that code is reached, so it is not covered by that PR.

Worth noting that array_equivalent also backs Index.equals and DataFrame.equals, where casting to a common dtype is reasonable, so a fix likely needs to be scoped to the testing path rather than changing array_equivalent itself.

Expected Behavior

atol=0.5 should not accept two values that are 1 apart. The tolerance should be applied to the actual values.

Installed Versions

Details

Reproduced on main at commit 44ae066.

[vetrovk]

I'd like to investigate this and work on a focused fix. I'll be using AI-assisted tooling and will fully review and validate any proposed changes.

[Parth1353]

Sounds good, it's all yours I'm not working on a fix for this.

One thing that might save you some time: the array_equivalent call is only a fast-path short-circuit, so the tolerance comparison below it is unreachable whenever it returns True. Gating that short-circuit (on the dtypes matching, or on no explicit tolerance having been passed) leaves Index.equals and DataFrame.equals untouched, which is where I'd expect pushback if array_equivalent itself were changed.

For context, #66696 fixes the same-dtype integer case inside assert_almost_equal, this issue is the path that never reaches that code in the first place.