Minimum denormal or ** bug

[KevinBraun]

BPO	37787
Nosy	@tim-one, @pfmoore, @tjguk, @zware, @zooba

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-08-07.17:40:20.503>
created_at = <Date 2019-08-07.15:32:45.667>
labels = ['interpreter-core', 'type-bug', 'OS-windows']
title = 'Minimum denormal or ** bug'
updated_at = <Date 2019-08-07.17:45:42.037>
user = 'https://bugs.python.org/KevinBraun'

bugs.python.org fields:

activity = <Date 2019-08-07.17:45:42.037>
actor = 'steve.dower'
assignee = 'none'
closed = True
closed_date = <Date 2019-08-07.17:40:20.503>
closer = 'tim.peters'
components = ['Interpreter Core', 'Windows']
creation = <Date 2019-08-07.15:32:45.667>
creator = 'Kevin Braun'
dependencies = []
files = []
hgrepos = []
issue_num = 37787
keywords = []
message_count = 6.0
messages = ['349168', '349171', '349172', '349177', '349180', '349181']
nosy_count = 7.0
nosy_names = ['tim.peters', 'paul.moore', 'tim.golden', 'SilentGhost', 'zach.ware', 'steve.dower', 'Kevin Braun']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue37787'
versions = []

[KevinBraun]

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:
>>> 2**-1074==2**-1075
True
>>> (2**-1074).hex()
'0x0.0000000000001p-1022'
>>> (2**-1075).hex()
'0x0.0000000000001p-1022'

And, the above is not consistent with the following:
>>> (2**-1074)/2
0.0
>>> (2**-1074)/2 == 2**-1075
False
>>> 1/2**1075
0.0
>>> 1/2**1075 == 2**-1075
False

Given the above observations, I suspect there is a bug in **.

[SilentGhost]

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.

[tim-one]

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 is one.

>>> import math
>>> math.pow(2.0, -1075.0)
5e-324
>>> math.pow(2.0, -1074.0) # same thing
5e-324

To avoid intermediate libm rounding errors, use ldexp instead:

>>> math.ldexp(1, -1074) # 2.0 ** -1074
5e-324
>>> math.ldexp(1, -1075) # 2.0 ** -1075
0.0

[zooba]

I have nothing to contribute here. Tim's right.

(I would love Python to have infinite precision float by default...)

[tim-one]

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 to be very slow, and, e.g., testing two of them for equality is, in general, undecidable even in theory. Here's one such:

https://www.chiark.greenend.org.uk/~sgtatham/spigot/

[zooba]

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 really provides it either, so it's more of a dream than a plan :)