[issue39484] time_ns() and time() cannot be compared on windows

Eryk Sun added the comment: > I'm not sure what you're suggesting here. I shouldn't try to understand > how floating-point numbers are stored? No, that's the furthest thought from my mind. I meant only that I would not recommend using one's own understanding of floating-point numbers

[issue39484] time_ns() and time() cannot be compared on windows

Larry Hastings added the comment: > Anyway, it's better to leave it to the experts: I'm not sure what you're suggesting here. I shouldn't try to understand how floating-point numbers are stored? -- ___ Python tracker

[issue39484] time_ns() and time() cannot be compared on windows

Eryk Sun added the comment: A binary float has the form (-1)**sign * (1 + frac) * 2**exp, where sign is 0 or 1, frac is a rational value in the range [0, 1), and exp is a signed integer (but stored in non-negative, biased form). The smallest value of frac is epsilon, and the smallest

[issue39484] time_ns() and time() cannot be compared on windows

Larry Hastings added the comment: Aha! The crucial distinction is that IEEE 754 doubles have 52 bits of storage for the mantissa, but folks (e.g. Wikipedia, Mark Dickinson) describe this as "53 bits of precision" because that's easier saying "52 bits but you don't have to store the leading

[issue39484] time_ns() and time() cannot be compared on windows

Mark Dickinson added the comment: Here's another way to see it. Let's get the Unix timestamp for right now: >>> from datetime import datetime >>> epoch = datetime(1970, 1, 1) >>> now = (datetime.now() - epoch).total_seconds() >>> now 1581261916.910558 Now let's figure out the resolution, by

[issue39484] time_ns() and time() cannot be compared on windows

Mark Dickinson added the comment: > Yes, but you get the first 1 bit for free. Not really. :-) That's a detail of how floating-point numbers happen to be stored; it's not really relevant here. It doesn't affect the fact that IEEE 754 binary64 floats have 53 bits of *precision*, so using 31

[issue39484] time_ns() and time() cannot be compared on windows

Larry Hastings added the comment: Yes, but you get the first 1 bit for free. So it actually only uses 30 bits of storage inside the double. This is apparently called "leading bit convention": https://en.wikipedia.org/wiki/IEEE_754#Representation_and_encoding_in_memory --

[issue39484] time_ns() and time() cannot be compared on windows

Mark Dickinson added the comment: [Larry] > It takes *30* bits to store the non-fractional seconds part of the current > time in a double I make it 31. :-) >>> from datetime import datetime >>> time_since_epoch = datetime.now() - datetime(1970, 1, 1) >>>

[issue39484] time_ns() and time() cannot be compared on windows

Larry Hastings added the comment: p.s. for what it's worth: I re-checked my math and as usual I goofed. It takes *30* bits to store the non-fractional seconds part of the current time in a double, leaving 23 bits for the fractional part, so we're *7* bits short. --

[issue39484] time_ns() and time() cannot be compared on windows

STINNER Victor added the comment: > No, int/int is more accurate here. Should _PyFloat_FromPyTime() implementation be modified to reuse long_true_divide()? -- ___ Python tracker

[issue39484] time_ns() and time() cannot be compared on windows

Change by Vincent Michel : Added file: https://bugs.python.org/file48883/comparing_conversions.py ___ Python tracker ___ ___

[issue39484] time_ns() and time() cannot be compared on windows

Vincent Michel added the comment: @mark.dickinson > To be clear: the following is flawed as an accuracy test, because the > *multiplication* by 1e9 introduces additional error. Interesting, I completely missed that! But did you notice that the full conversion might still perform better

[issue39484] time_ns() and time() cannot be compared on windows

Mark Dickinson added the comment: To be clear: the following is flawed as an accuracy test, because the *multiplication* by 1e9 introduces additional error. # int/int: int.__truediv__(int) >>> abs(t - int(t/10**9 * 1e9)) 172 Try this instead, which uses the Fractions module to get the exact

[issue39484] time_ns() and time() cannot be compared on windows

Mark Dickinson added the comment: > int/int is less accurate than float/float for t=1580301619906185300 No, int/int is more accurate here. If a and b are ints, a / b is always correctly rounded on an IEEE 754 system, while float(a) / float(b) will not necessarily give a correctly rounded

[issue39484] time_ns() and time() cannot be compared on windows

Vincent Michel added the comment: @serhiy.storchaka > 1580301619906185300/10**9 is more accurate than 1580301619906185300/1e9. I don't know exactly what `F` represents in your example but here is what I get: >>> r = 1580301619906185300 >>>

[issue39484] time_ns() and time() cannot be compared on windows

STINNER Victor added the comment: I compare nanoseconds (int): >>> t=1580301619906185300 # int/int: int.__truediv__(int) >>> abs(t - int(t/10**9 * 1e9)) 172 # int/float: float.__rtruediv__(int) >>> abs(t - int(t/1e9 * 1e9)) 84 # float/int: float.__truediv__(int) >>> abs(t -

[issue39484] time_ns() and time() cannot be compared on windows

Serhiy Storchaka added the comment: >>> 1580301619906185300/10**9 1580301619.9061854 >>> 1580301619906185300/1e9 1580301619.9061852 >>> float(F(1580301619906185300/10**9) * 10**9 - 1580301619906185300) 88.5650634765625 >>> float(F(1580301619906185300/1e9) * 10**9 - 1580301619906185300)

[issue39484] time_ns() and time() cannot be compared on windows

STINNER Victor added the comment: I'm not sure which kind of problem you are trying to solve here. time.time() does lose precision because it uses the float type. Comparing time.time() and time.time_ns() tricky because of that. If you care of nanosecond precision, avoid float whenever

[issue39484] time_ns() and time() cannot be compared on windows

Serhiy Storchaka added the comment: But they are not single-digit integers. And more, int(float(a)) != a. -- ___ Python tracker ___

[issue39484] time_ns() and time() cannot be compared on windows

Larry Hastings added the comment: > The problem is that there is a double rounding in > time = float(time_ns) / 1e9 > 1. When convert time_ns to float. > 2. When divide it by 1e9. I'm pretty sure that in Python 3, if you say c = a / b and a and b are both "single-digit" integers, it

[issue39484] time_ns() and time() cannot be compared on windows

Vincent Michel added the comment: > The problem is that there is a double rounding in [...] Actually `float(x) / 1e9` and `x / 1e9` seems to produce the same results: ``` import time import itertools now = time.time_ns()

[issue39484] time_ns() and time() cannot be compared on windows

Serhiy Storchaka added the comment: The problem is that there is a double rounding in time = float(time_ns) / 1e9 1. When convert time_ns to float. 2. When divide it by 1e9. The formula time = time_ns / 10**9 may be more accurate. -- nosy: +lemburg, mark.dickinson,

[issue39484] time_ns() and time() cannot be compared on windows

STINNER Victor added the comment: Yeah, time.time(), time.monotonic() and time.perf_counter() can benefit of a note suggestion to use time.time_ns(), time.monotonic_ns() or time.perf_counter_ns() to better precision. -- ___ Python tracker

[issue39484] time_ns() and time() cannot be compared on windows

Vincent Michel added the comment: Thanks for your answers, that was very informative! > >>> a/10**9 > 1580301619.9061854 > >>> a/1e9 > 1580301619.9061852 > > I'm not sure which one is "correct". Originally, I thought `a/10**9` was more precise because I ran into the following case while

[issue39484] time_ns() and time() cannot be compared on windows

Change by Vincent Michel : Added file: https://bugs.python.org/file48881/comparing_errors.py ___ Python tracker ___ ___ Python-bugs-list

[issue39484] time_ns() and time() cannot be compared on windows

Larry Hastings added the comment: (Oh, wow, Victor, you wrote all that while I was writing my reply. ;-) -- ___ Python tracker ___

[issue39484] time_ns() and time() cannot be compared on windows

Larry Hastings added the comment: I don't think this is fixable, because it's not exactly a bug. The problem is we're running out of bits. In converting the time around, we've lost some precision. So the times that come out of time.time() and time.time_ns() should not be considered

[issue39484] time_ns() and time() cannot be compared on windows

STINNER Victor added the comment: By the way, I wrote an article about the history on how Python rounds time... https://vstinner.github.io/pytime.html I also wrote two articles about nanoseconds in Python: * https://vstinner.github.io/python37-pep-564-nanoseconds.html *

[issue39484] time_ns() and time() cannot be compared on windows

STINNER Victor added the comment: Another way to understand the problem: nanosecond (int) => seconds (float) => nanoseconds (int) roundtrip looses precison. >>> a=1580301619906185300 >>> a/1e9*1e9 1.5803016199061852e+18 >>> b=int(a/1e9*1e9) >>> b 1580301619906185216 >>> a - b 84 The best

[issue39484] time_ns() and time() cannot be compared on windows

STINNER Victor added the comment: See also bpo-39277 which is similar issue. I proposed a fix which uses nextafter(): https://github.com/python/cpython/pull/17933 -- ___ Python tracker

[issue39484] time_ns() and time() cannot be compared on windows

STINNER Victor added the comment: >>> a / 10**9 <= b False Try to use a/1e9 <= b. -- The C code to get the system clock is the same for time.time() and time.time_ns(). It's only the conversion of the result which is different: static PyObject * time_time(PyObject *self, PyObject

[issue39484] time_ns() and time() cannot be compared on windows

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39484] time_ns() and time() cannot be compared on windows

Change by Raymond Hettinger : -- nosy: +larry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39484] time_ns() and time() cannot be compared on windows

Change by Terry J. Reedy : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39484] time_ns() and time() cannot be compared on windows

Vincent Michel added the comment: I thought about it a bit more and I realized there is no way to recover the time in hundreds of nanoseconds from the float produced by `time.time()` (since the windows time currently takes 54 bits and will take 55 bits in 2028). That means `time()` and

[issue39484] time_ns() and time() cannot be compared on windows

New submission from Vincent Michel : On windows, the timestamps produced by time.time() often end up being equal because of the 15 ms resolution: >>> time.time(), time.time() (1580301469.6875124, 1580301469.6875124) The problem I noticed is that a value produced by time_ns() might