Titus Brown <titus at caltech.edu> wrote: > > -> > 1067760 -- float-->long conversion on fileobj.seek calls, rather than > -> > float-->int. Permits larger floats (2.0**62) to match large > -> > int (2**62) arguments. rhettinger marked as "won't fix" in > -> > the original bug report; this seems like a clean solution, > -> > tho. Recommend apply. > -> > -> Wouldn't this cause subtle errors when the float -> long conversion is > -> no longer precise? Or is this a non issue because it could only happen > -> when seeking on impossibly large files? > > When would the float --> long conversion not be precise? The docs > say PyLong_FromDouble takes the integer part, so it's like doing > a floor(), yes? Precision. >>> 2.0**52 4503599627370496.0 >>> 2.0**52+1 4503599627370497.0 >>> 2.0**53 9007199254740992.0 >>> 2.0**53+1 9007199254740992.0 Anything above float(2**53-1) (one must be careful about the order of float conversions) are basically useless for offsets into files. > The current behavior is to convert directly from float to int, even > though seek() can take longs as an argument. Thus 2.0**31 works, > 2**31 works, 2**62 works, but 2.0**62 doesn't. This seems mildly > inconsistent and prompted the guy to submit a bug report, and then > a patch. "works" and "doesn't work" aren't precise. "doesn't raise an exception" and "does raise an exception" are precise. Note the above float precision precision example about why even non-exceptions may not "work". - Josiah
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4