BUG: process Int64 as ints for preservable ops, not as float64

[qwhelan]

Calling .min() or .max() on pd.Int64 data returns integers, but uses float64 as an intermediate representation, leading to data corruption.

This PR attempts to whitelist them to be processed entirely as Int64s. Also add a test that verifies this behavior, as existing tests failed to detect the bug.

• closes DataFrame with Int64 columns casts to float64 with .max()/.min() #32651
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

[jorisvandenbossche]

@qwhelan thanks for looking into this!

I am personally not fully convinced this is the best approach long term (I rather see us looking into #30982, but there is still discussion on the way forward). So short term this can certainly fix the issue at hand.

[qwhelan]

@jorisvandenbossche Yeah, I agree this isn't the long-term approach. The issue is that df[df[col] == df[col].max()] is a fairly popular idiom and fails when the left side is an Int64 and the right side is a float64 (if not for type reasons, for the latter losing precision).

[jreback]

so would be ok with this for only min/max right now.

[jreback]

this invades way toomuch on group/frame ops. this should all be pushed back down to the EA ops. So this might require multiple PRs to handle this.

[qwhelan]

@jreback Updated to the bare minimum to fix IntegerArray.min/max

[jreback]

we are likey to merge: #30982 shortly. Happy to take this as a followon using that approach.

[jbrockmendel]

@qwhelen does #30982 affect the implementation here?

[qwhelan]

@jbrockmendel Looks like this is unnecessary now, closing