[Python-Dev] PEP 564: Add new time functions with nanosecond resolution

Wes Turner wes.turner at gmail.com
Sun Oct 22 16:42:40 EDT 2017


On Sunday, October 22, 2017, David Mertz <mertz at gnosis.cx> wrote:

> I worked at a molecular dynamics lab for a number of years. I advocated
> switching all our code to using attosecond units (rather than fractional
> picoseconds).
>
> However, this had nothing whatsoever to do with the machine clock speeds,
> but only with the physical quantities represented and the scaling/rounding
> math.
>
> It didn't happen, for various reasons. But if it had, I certainly wouldn't
> have expected standard library support for this. The 'time' module is about
> wall clock out calendar time, not about *simulation time*.
>
> FWIW, a very long simulation might cover a millisecond of simulated
> time.... we're a very long way from looking at molecular behavior over 104
> days.
>

Maybe that's why we haven't found any CTCs (closed timelike curves) yet.

Aligning simulation data in context to other events may be enlightening: is
there a good library for handing high precision time units in Python
(and/or CFFI)?

...

http://opendata.cern.ch/

http://opendata.cern.ch/getting-started/CMS


>
>
> On Oct 22, 2017 8:10 AM, "Wes Turner" <wes.turner at gmail.com
> <javascript:_e(%7B%7D,'cvml','wes.turner at gmail.com');>> wrote:
>
>
>
> On Saturday, October 21, 2017, Nick Coghlan <ncoghlan at gmail.com
> <javascript:_e(%7B%7D,'cvml','ncoghlan at gmail.com');>> wrote:
>
>> On 22 October 2017 at 09:32, Victor Stinner <victor.stinner at gmail.com>
>> wrote:
>>
>>> Le 21 oct. 2017 20:31, "francismb" <francismb at email.de> a écrit :
>>>
>>> I understand that one can just multiply/divide the nanoseconds returned,
>>> (or it could be a factory) but wouldn't it help for future enhancements
>>> to reduce the number of functions (the 'pico' question)?
>>>
>>>
>>> If you are me to predict the future, I predict that CPU frequency will
>>> be stuck below 10 GHz for the next 10 years :-)
>>>
>>
>> There are actually solid physical reasons for that prediction likely
>> being true. Aside from the power consumption, heat dissipation, and EM
>> radiation issues that arise with higher switching frequencies, you also
>> start running into more problems with digital circuit metastability ([1],
>> [2]): the more clock edges you have per second, the higher the chances of
>> an asynchronous input changing state at a bad time.
>>
>> So yeah, for nanosecond resolution to not be good enough for programs
>> running in Python, we're going to be talking about some genuinely
>> fundamental changes in the nature of computing hardware, and it's currently
>> unclear if or how established programming languages will make that jump
>> (see [3] for a gentle introduction to the current state of practical
>> quantum computing). At that point, picoseconds vs nanoseconds is likely to
>> be the least of our conceptual modeling challenges :)
>>
>
> There are current applications with greater-than nanosecond precision:
>
> - relativity experiments
> - particle experiments
>
> Must they always use their own implementations of time., datetime.
> __init__, fromordinal, fromtimestamp ?!
>
> - https://scholar.google.com/scholar?q=femtosecond
> - https://scholar.google.com/scholar?q=attosecond
> - GPS now supports nanosecond resolution
> -
>
> https://en.wikipedia.org/wiki/Quantum_clock#More_accurate_ex
> perimental_clocks
>
> > In 2015 JILA <https://en.m.wikipedia.org/wiki/JILA> evaluated the
> absolute frequency uncertainty of their latest strontium-87
> <https://en.m.wikipedia.org/wiki/Isotopes_of_strontium> optical lattice
> clock at 2.1 × 10−18, which corresponds to a measurable gravitational
> time dilation
> <https://en.m.wikipedia.org/wiki/Gravitational_time_dilation> for an
> elevation change of 2 cm (0.79 in)
>
> What about bus latency (and variance)?
>
> From https://www.nist.gov/publications/optical-two-way-time-and-
> frequency-transfer-over-free-space :
>
> > Optical two-way time and frequency transfer over free space
> > Abstract
> > The transfer of high-quality time-frequency signals between remote
> locations underpins many applications, including precision navigation and
> timing, clock-based geodesy, long-baseline interferometry, coherent radar
> arrays, tests of general relativity and fundamental constants, and future
> redefinition of the second. However, present microwave-based time-frequency
> transfer is inadequate for state-of-the-art optical clocks and oscillators
> that have femtosecond-level timing jitter and accuracies below 1 × 10−17.
> Commensurate optically based transfer methods are therefore needed. Here we
> demonstrate optical time-frequency transfer over free space via two-way
> exchange between coherent frequency combs, each phase-locked to the local
> optical oscillator. We achieve 1 fs timing deviation, residual instability
> below 1 × 10−18 at 1,000 s and systematic offsets below 4 × 10−19,
> despite frequent signal fading due to atmospheric turbulence or
> obstructions across the 2 km link. This free-space transfer can enable
> terrestrial links to support clock-based geodesy. Combined with
> satellite-based optical communications, it provides a path towards
> global-scale geodesy, high-accuracy time-frequency distribution and
> satellite-based relativity experiments.
>
> How much wider must an epoch-relative time struct be for various realistic
> time precisions/accuracies?
>
> 10-6 micro µ
> 10-9 nano n -- int64
> 10-12 pico p
> 10-15 femto f
> 10-18 atto a
> 10-21 zepto z
> 10-24 yocto y
>
> I'm at a loss to recommend a library to prefix these with the epoch; but
> future compatibility may be a helpful, realistic objective.
>
> Natural keys with such time resolution are still unfortunately likely to
> collide.
>
>
>>
>> Cheers,
>> Nick.
>>
>> [1] https://en.wikipedia.org/wiki/Metastability_in_electronics
>> [2] https://electronics.stackexchange.com/questions/14816/what-i
>> s-metastability
>> [3] https://medium.com/@decodoku/how-to-program-a-quantum-comput
>> er-982a9329ed02
>>
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> <javascript:_e(%7B%7D,'cvml','Python-Dev at python.org');>
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%
> 40gnosis.cx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171022/72a961f2/attachment.html>


More information about the Python-Dev mailing list