On Tue, Apr 17, 2012 at 2:48 PM, Cameron Simpson <cs at zip.com.au> wrote: > On 16Apr2012 01:25, Victor Stinner <victor.stinner at gmail.com> wrote: > | I suppose that most people don't care that "resolution" and > | "precision" are different things. > > If we're using the same definitions we discussed offline, where > > - resolution is the units the clock call (underneath) works in (for > example, nanoseconds) > > - precision is the effective precision of the results, for example > milliseconds > > I'd say people would care if they knew, and mostly care about > "precision". Meaning that resolution is a matter of format and API, not of clock. If you take a C clock API that returns a value in nanoseconds and return it as a Python float, you've changed the resolution. I don't think resolution matters much, beyond that (for example) nanosecond resolution allows a clock to be subsequently upgraded as far as nanosecond precision without breaking existing code, even if currently it's only providing microsecond precision. But it makes just as much sense for your resolution to be 2**64ths-of-a-second or quarters-of-the-internal-CPU-clock-speed as it does for nanoseconds. As long as it's some fraction of the SI second, every different resolution is just a fixed ratio away from every other one. ChrisA
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4