On Sunday, October 22, 2017, David Mertz <me...@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.tur...@gmail.com > <javascript:_e(%7B%7D,'cvml','wes.tur...@gmail.com');>> wrote: > > > > On Saturday, October 21, 2017, Nick Coghlan <ncogh...@gmail.com > <javascript:_e(%7B%7D,'cvml','ncogh...@gmail.com');>> wrote: > >> On 22 October 2017 at 09:32, Victor Stinner <victor.stin...@gmail.com> >> wrote: >> >>> Le 21 oct. 2017 20:31, "francismb" <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_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 | ncogh...@gmail.com | Brisbane, Australia >> > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > <javascript:_e(%7B%7D,'cvml','Python-Dev@python.org');> > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz% > 40gnosis.cx > >
_______________________________________________ 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
