[issue37787] Minimum denormal or ** bug

Steve Dower added the comment: Only half serious ;) I'd settle for "reliable, consistent and easy to explain rounding", which is unfortunately not what IEEE 754 provides (unless you assume significant amounts of CS background that most Python users do not have). But then, nothing else

[issue37787] Minimum denormal or ** bug

Tim Peters added the comment: Since this depends on the platform libm implementation of pow(), I'm closing this as "won't fix". Steve, on the chance you're serious ;-) , there are implementations of the "constructive reals", which indeed act like infinite-precision floats. But they tend

[issue37787] Minimum denormal or ** bug

Steve Dower added the comment: I have nothing to contribute here. Tim's right. (I would love Python to have infinite precision float by default...) -- ___ Python tracker ___

[issue37787] Minimum denormal or ** bug

Tim Peters added the comment: Python delegates exponentiation with a Python float result to the platform C's double precision `pow()` function. So this is just what the Windows C pow(2.0, -1075.0) returns. All native floating point operations are subject various kinds of error, and this

[issue37787] Minimum denormal or ** bug

SilentGhost added the comment: This seems like a Windows-specific issues. Using the same version of python built with gcc 8.3, I get the results inline with your expectations and all the comparisons yield exactly opposite values. -- components: +Windows nosy: +SilentGhost,

[issue37787] Minimum denormal or ** bug

New submission from Kevin Braun : Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05) [MSC v.1916 64 bit (AMD64)] I believe 2**-1074 is the smallest denormalized number for Python on my system (Windows), so I would expect 2**-1075 to yield 0.0, but it does not. Instead: >>>