DEPR: float_precision in read_csv

[jbrockmendel]

We have "high" (the default), "legacy", and "round_trip". When it was introduced in #8044, using the "high" precision apparently came with a performance penalty, but that changed by 2017 (#17154 (comment)) so the default was changed from "legacy" to "high" in #36228. I can't think of any reason why anyone would use "legacy".

I'm not aware of anyone who uses this parameter at all. Let's deprecate it and simplify the code+API.

Update: I patched the code to always use precision="high" to see whether it broke any tests. Aside from a test specifically asserting that "legacy" is inaccurate, the only test that broke was test_precise_conversion (4 cases out of 42) where we parse 1.700000000000000177635684 to 1.7. I'm fine with this level of rounding (though I think using fast_float might improve it to 1.7000000000000002 which is what pyarrow gives). I'd also be OK with saying "round_trip" level precision is only for the python engine (though that engine also gives 1.7)

[spider-yamet]

Hi @jbrockmendel Thanks for reporting this issue, can I resolve this issue?

[jbrockmendel]

Wait until there's discussion and consensus this is something we want to do.

[jorisvandenbossche]

I would say we can certainly already deprecate the "legacy" option? (there doesn't seem to be much point in using that now it is no longer the default).

For "round_trip", it does give a better accuracy. Did you check the performance for that case; I assume that is a lot slower?

Would using fast_float potentially be able to replace both `"high" and "round_trip" by being as precise as "round_trip" and as fast as "high"?

[jbrockmendel]

Yes, round_trip is much slower. In all our existing tests, using fast_float gives the same results as round_trip and has performance within the margin of error of "high". I think we should replace all three of our current implementations with fast_float, at which point the keyword will have no effect, so we can definitely deprecate it.