On Saturday, October 21, 2017, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 22 October 2017 at 09:32, Victor Stinner <victor.stin...@gmail.com > <javascript:_e(%7B%7D,'cvml','victor.stin...@gmail.com');>> wrote: > >> Le 21 oct. 2017 20:31, "francismb" <franci...@email.de >> <javascript:_e(%7B%7D,'cvml','franci...@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_experimental_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-is-metastability > [3] https://medium.com/@decodoku/how-to-program-a-quantum- > computer-982a9329ed02 > > > -- > Nick Coghlan | ncogh...@gmail.com > <javascript:_e(%7B%7D,'cvml','ncogh...@gmail.com');> | Brisbane, > Australia >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
