this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
Locked
12
12
 
|
On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing <[hidden email]> wrote:
> > This is the strict mathematical meaning of the word "monotonic", but the way it's used in relation to OS clocks, it seems to mean rather more than that. Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock. There seem to be two groups of people: 1. Those who think that "monotonic clock" means a clock that never goes backwards. These people are in the majority. After all, that's what the word "monotonic" means ¹ . However, a clock which guarantees *only* this is useless. 2. Those who think that "monotonic clock" means a clock that never jumps, and that runs at a rate approximating the rate of real time. This is a very useful kind of clock to have! It is what C++ now calls a "steady clock". It is what all the major operating systems provide. The people in class 1 are more correct, technically, and far more numerous, but the concept from 1 is a useless concept that should be forgotten. So before proceeding, we should mutually agree that we have no interest in implementing a clock of type 1. It wouldn't serve anyone's use case (correct me if I'm wrong!) and the major operating systems don't offer such a thing anyway. Then, if we all agree to stop thinking about that first concept, then we need to agree whether we're all going to use the word "monotonic clock" to refer to the second concept, or if we're going to use a different word (such as "steady clock") to refer to the second concept. I would prefer the latter, as it will relieve us of the need to repeatedly explain to newcomers: "That word doesn't mean what you think it means.". The main reason to use the word "monotonic clock" to refer to the second concept is that POSIX does so, but since Mac OS X, Solaris, Windows, and C++ have all avoided following POSIX's mistake, I think Python should too. Regards, Zooko ¹ http://mathworld.wolfram.com/MonotonicSequence.html _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
On 05Apr2012 21:07, Zooko Wilcox-O'Hearn <[hidden email]> wrote:
| On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing <[hidden email]> wrote: | > This is the strict mathematical meaning of the word "monotonic", | > but the way it's used in relation to OS clocks, it seems to mean rather | > more than that. | | Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock. Well, not for a wildly unsteady monotonic clock. | There seem to be two groups of people: | 1. Those who think that "monotonic clock" means a clock that never | goes backwards. I will always fall into this category. | These people are in the majority. After all, that's | what the word "monotonic" means ¹ . However, a clock which guarantees | *only* this is useless. Sure. I wouldn't have much use for a clock that was only monotonic, but the word "clock" implies a bit more all on its own, so I am undisturbed. | 2. Those who think that "monotonic clock" means a clock that never | jumps, and that runs at a rate approximating the rate of real time. If they're calling it "monotonic" on that basis alone, they are wrong. Pure and simple. | This is a very useful kind of clock to have! It is what C++ now calls | a "steady clock". It is what all the major operating systems provide. Sure. So _call_ it a steady clock! | The people in class 1 are more correct, technically, and far more | numerous, but the concept from 1 is a useless concept that should be | forgotten. | | So before proceeding, we should mutually agree that we have no | interest in implementing a clock of type 1. It wouldn't serve anyone's | use case (correct me if I'm wrong!) and the major operating systems | don't offer such a thing anyway. Bah! They are not disjoint sets of clocks! Linux' CLOCK_MONOTONIC_RAW is both type 1 and type 2. | Then, if we all agree to stop thinking about that first concept, then | we need to agree whether we're all going to use the word "monotonic | clock" to refer to the second concept, No. | or if we're going to use a | different word (such as "steady clock") to refer to the second | concept. I would prefer the latter, as it will relieve us of the need | to repeatedly explain to newcomers: "That word doesn't mean what you | think it means.". Yes. Resorting to The Princess Bride to resolve bad terminology is only funny in a movie, and should be a Big Clue that the term is either being misused or too badly understood. | The main reason to use the word "monotonic clock" to refer to the | second concept is that POSIX does so, but since Mac OS X, Solaris, | Windows, and C++ have all avoided following POSIX's mistake, I think | Python should too. No. If it is not monotonic, DO NOT CALL IT monotonic. Call it steady, perhaps, if it _is_ steady (within some threshold of course). But CLOCK_MONOTONIC_RAW is type 1 and 2, and is thus a "steady monotonic" clock. Probably a good choice for both. We can argue about what characteristics a useful clock has. And we can argue about what characteristics the various OS clocks possess. But please DO NOT invent a new and misleading meaning for a well defined word. "monotonic" alone is such a word, and means just one thing. "monotonic clock" means _more_, but isn't always a requirement; "steady clock" seems more commonly wanted. Except of course that some participants say "steady clock" is a nonsensical term. -- Cameron Simpson <[hidden email]> DoD#743 http://www.cskk.ezoshosting.com/cs/ Politics, n. Strife of interests masquerading as a contest of principles. - Ambrose Bierce, _The_Devil's_Dictionary_ _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
Cameron Simpson wrote:
> | The main reason to use the word "monotonic clock" to refer to the > | second concept is that POSIX does so, but since Mac OS X, Solaris, > | Windows, and C++ have all avoided following POSIX's mistake, I think > | Python should too. > > No. If it is not monotonic, DO NOT CALL IT monotonic. Call it steady, > perhaps, if it _is_ steady (within some threshold of course). Um, steady is a stronger promise than monotonic. This is a monotonic sequence: 1, 2, 99, 100, 101, 102, 103, 199, 200, 201, 999 But it isn't steady, because it jumps forward. Here is a non-monotonic sequence: 1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8 This isn't steady either, because it jumps backwards. To be steady, it MUST also be monotonic. If you think that it is appropriate to call a non-monotonic clock "steady", then I think you should tell us what you mean by "steady but not monotonic". -- Steven _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
On 06Apr2012 14:31, Steven D'Aprano <[hidden email]> wrote:
| Cameron Simpson wrote: | > | The main reason to use the word "monotonic clock" to refer to the | > | second concept is that POSIX does so, but since Mac OS X, Solaris, | > | Windows, and C++ have all avoided following POSIX's mistake, I think | > | Python should too. | > | > No. If it is not monotonic, DO NOT CALL IT monotonic. Call it steady, | > perhaps, if it _is_ steady (within some threshold of course). | | Um, steady is a stronger promise than monotonic. This is a monotonic sequence: | | 1, 2, 99, 100, 101, 102, 103, 199, 200, 201, 999 | | But it isn't steady, because it jumps forward. Sure. | Here is a non-monotonic sequence: | | 1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8 | | This isn't steady either, because it jumps backwards. | | To be steady, it MUST also be monotonic. If you think that it is appropriate | to call a non-monotonic clock "steady", then I think you should tell us what | you mean by "steady but not monotonic". I took steady to mean "never jumps more than x", for "x" being "small", and allowing small negatives. If steady implies monotonic and people agree that that is so, I'm happy too, and happy that steady is a better aspiration than merely monotonic. -- Cameron Simpson <[hidden email]> DoD#743 http://www.cskk.ezoshosting.com/cs/ I understand a fury in your words, but not your words. - William Shakespeare _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by zooko
On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:
While this is a popular view on this list and in this discussion, it is also a view that seems to contradict quite a lot that has been written on the subject, and seems contrary to the usual jargon when referring to clocks.
All clocks run at a rate approximating the rate of real time. That is very close to the definition of the word "clock" in this context. All clocks have flaws in that approximation, and really those flaws are the whole point of access to distinct clock APIs. Different applications can cope with different flaws. There seems to be a persistent desire in this discussion to specify and define these flaws out of existence, where this API really should instead be embracing the flaws and classifying them. (Victor is doing a truly amazing job with the PEP in that regard; it's already the first web search hit on every search engine I've tried for more than half of these terms.) Steadiness, in the C++ sense, only applies to most OS clocks that are given the label of "monotonic" during the run of a single program on a single computer while that computer is running at some close approximation of full power. As soon as you close your laptop lid, the property of steadiness with respect to real local time goes away; the clock stops ticking forward, and only resumes when the lid is opened again. The thing I'd like to draw attention to here is that when you get one of these clocks, you *do not* get a parallel facility that allows you to identify whether a suspend has happened (or, for that matter, when the wall clock has stepped). Or at least, nobody's proposed one for Python. I proposed one for Twisted, <http://twistedmatrix.com/trac/ticket/2424#comment:26>, but you need an event loop for that, because you need to be able to register interest in that event. I believe that the fact that these clocks are only semi-steady, or only steady with respect to certain kinds of time, is why the term "monotonic clock" remains so popular, despite the fact that mathematical monotonicity is not actually their most useful property. While these OS-provided clocks have other useful properties, they only have those properties under specific conditions which you cannot necessarily detect and you definitely cannot enforce. But they all remain monotonic in the mathematical sense (modulo hardware and OS bugs), so it is the term "monotonic" which comes to label all their other, more useful, but less reliable properties.
Technically correct; the best kind of correct! The people in class 1 are only more correct if you accept that mis-applying jargon from one field (mathematics) to replace generally-accepted terminology in another field (software clocks) is the right thing to do. I think it's better to learn the local jargon and try to apply it consistently. If you search around the web for the phrase "monotonic clock", it's applied in a sense closest to the one you mean on thousands and thousands of web pages. "steady clock" generally applies with reference to C++, and even then is often found in phrases like "is_steady indicates whether this clock is a monotonic clock". Software developers "mis"-apply mathematical terms like "isomorphic", "orthogonal", "incidental", "tangential", and "reflexive" all the time. Physicists and mathematicians also disagree on the subtleties of the same terms. Context is everything.
+1.
I don't think anything can (or should) relieve that need. I am somewhat sympathetic to your preference for "steady" as a better overall term. It does express the actually-desired property of the clock, even if that property isn't always present; steadiness is not a property that one can be tempted to synthesize, so it removes the temptation to cloud the discussion with that. Ultimately I don't prefer it, because I think its provenance is less venerable than "monotonic", just because I have a bit more respect for the POSIX committee than the C++ one :-). However, whatever choice we make in terminology, the documentation for this API must stress what it actually does, and what guarantee it actually provides. In that sense, my preferred term for this would be the "time.zfnrg_lfj_lpqq(ZFNRG_TIME | ZFNRG_SEMI_STEADY | ZFNRG_SEE_DOCUMENTATION)".
Do you just mean that the APIs don't have "monotonic" in the name? They all use different words, which strikes me as more of a failure than a success, in the realm of making mistakes about communicating things :).
_______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
On Fri, Apr 6, 2012 at 3:39 PM, Glyph Lefkowitz <[hidden email]> wrote:
> There seems to be a persistent desire in this discussion to specify and > define these flaws out of existence, where this API really should instead be > embracing the flaws and classifying them. That seems to be precisely what Cameron is advocating. > I think it's better to learn the local jargon and try to apply it > consistently. If you search around the web for the phrase "monotonic > clock", it's applied in a sense closest to the one you mean on thousands and > thousands of web pages. But is "a sense" the *same* sense on all of those pages? If not, then some people are going to be upset by anything we label a "monotonic" clock, because it will suffer from some flaw that's unacceptable in their applications for "monotonic" clocks. _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by Glyph Lefkowitz
Glyph Lefkowitz wrote:
> On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote: >> 2. Those who think that "monotonic clock" means a clock that never jumps, >> and that runs at a rate approximating the rate of real time. This is a >> very useful kind of clock to have! It is what C++ now calls a "steady >> clock". It is what all the major operating systems provide. > > All clocks run at a rate approximating the rate of real time. That is very > close to the definition of the word "clock" in this context. All clocks > have flaws in that approximation, and really those flaws are the whole > point of access to distinct clock APIs. Different applications can cope > with different flaws. I think that this is incorrect. py> time.clock(); time.sleep(10); time.clock() 0.41 0.41 -- Steven _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
On 6 April 2012 11:12, Steven D'Aprano <[hidden email]> wrote:
Blame Python's use of CPU time in clock() on Unix for that. On Windows: >>> time.clock(); time.sleep(10); time.clock() 14.879754156329385
24.879591008462793 That''s a backward compatibility issue, though - I'd be arguing that time.clock() is the best name for "normally the right clock for interval, benchmark or timeout uses as long as you don't care about oddities like suspend" otherwise. Given that this name is taken, I'd argue for time.wallclock. I'm not familiar enough with the terminology to know what to expect from terms like monotonic, steady, raw and the like.
Paul. _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by zooko
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time. > This is a very useful kind of clock to have! It is what C++ now calls > a "steady clock". It is what all the major operating systems provide. Python cannot give such guarantee. Extract of time.monotonic() function proposed in the PEP 418: "The elapsed time may or may not include time the system spends in sleep or hibernation; this depends on the operating system." The C++ Timeout Specification uses the following definition: "Objects of class steady_clock represent clocks for which values of time_point advance at a steady rate relative to real time. That is, the clock may not be adjusted." Proposed time.monotonic() doesn't respect this definition because CLOCK_MONOTONIC *is* adjusted (slewed) on Linux. We might provide a steady clock, but it would be less portable than the monotonic clock. I'm not sure that we need such clock, which use case requires a steady and not a monotonic clock? On Linux, I now prefer to use CLOCK_MONOTONIC (monotonic) than CLOCK_MONOTONIC_RAW (monotonic and steady as defined by C++) *because* its frequency is adjusted. Victor _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by Paul Moore
I'd like to veto wall clock because to me that's the clock on my wall, i.e. local time. Otherwise I like the way this thread is going. --Guido van Rossum (sent from Android phone) On Apr 6, 2012 4:57 AM, "Paul Moore" <[hidden email]> wrote:
_______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by Victor Stinner-3
This is the most amusing of discussions.
Teh key sentence here is "the clock may not be adjusted". Slewing or accelerating a clock is nerely adding to the already present error of the pace of the clock. Sometimes a clock runs fast, sometimes it runs slow. This is without any purposeful slewing or accelerating made by the OS. Notice how the C++ standard specifies nothing about the error of this steady rate, which is however always nonzero. This implies that the error in the time, or the variations of its rate, are not important to the meaning of the standard. The thing wich matters here is that the clock progresses forwards, matching the progress of real times, to some (unsopecified) precision. It must not suddenly jump backwards or forwards because someone changed the timezone. That is all that is implied. Since the error of the clock is unspecified, (that is, the error in its rate of progress) it cannot matter if this rate is temporarily adjusted by hand. K ________________________________________ Frá: python-dev-bounces+kristjan=[hidden email] [python-dev-bounces+kristjan=[hidden email]] fyrir hönd Victor Stinner [[hidden email]] Sent: 6. apríl 2012 14:32 To: Zooko Wilcox-O'Hearn Cc: Python-Dev Efni: Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) The C++ Timeout Specification uses the following definition: "Objects of class steady_clock represent clocks for which values of time_point advance at a steady rate relative to real time. That is, the clock may not be adjusted." Proposed time.monotonic() doesn't respect this definition because CLOCK_MONOTONIC *is* adjusted (slewed) on Linux. _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by Steven D'Aprano-8
This is the original reason for the original defect (issue 10278)
unix' clock() doesn't actually provide a clock in this sense, it provides a resource usage metric. K ________________________________________ Frá: python-dev-bounces+kristjan=[hidden email] [python-dev-bounces+kristjan=[hidden email]] fyrir hönd Steven D'Aprano [[hidden email]] Sent: 6. apríl 2012 10:12 To: Python-Dev Efni: Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed) I think that this is incorrect. py> time.clock(); time.sleep(10); time.clock() 0.41 0.41 -- Steven _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by Cameron Simpson
On 06Apr2012 15:19, I wrote:
| On 06Apr2012 14:31, Steven D'Aprano <[hidden email]> wrote: | | Here is a non-monotonic sequence: | | | | 1, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 8 | | | | This isn't steady either, because it jumps backwards. | | | | To be steady, it MUST also be monotonic. If you think that it is appropriate | | to call a non-monotonic clock "steady", then I think you should tell us what | | you mean by "steady but not monotonic". | | I took steady to mean "never jumps more than x", for "x" being "small", | and allowing small negatives. If steady implies monotonic and people | agree that that is so, I'm happy too, and happy that steady is a better | aspiration than merely monotonic. I've had some sleep. _Of course_ steady implies monotonic, or it wouldn't steadily move forwards. -- Cameron Simpson <[hidden email]> DoD#743 http://www.cskk.ezoshosting.com/cs/ I went to see a psychiatrist. He told me I was crazy. I told him I wanted a second opinion, so he said, "Ok, you're ugly, too." - Rodney Dangerfield _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by Kristján Valur Jónsson
On 06Apr2012 17:07, Kristj�n Valur J�nsson <[hidden email]> wrote:
| Steven D'Aprano: | > I think that this is incorrect. | > py> time.clock(); time.sleep(10); time.clock() | > 0.41 | > 0.41 | | This is the original reason for the original defect (issue 10278) | unix' clock() doesn't actually provide a clock in this sense, it provides a resource usage metric. Yeah:-( Its help says "Return the CPU time or real time since [...]". Two very different things, as demonstrated. I suppose neither goes backwards, but this seems like a classic example of the "useless monotonic clock" against which Greg Ewing railed. And why? For one thing, because one can't inspect its metadata to find out what it does. -- Cameron Simpson <[hidden email]> DoD#743 http://www.cskk.ezoshosting.com/cs/ Tens of thousands of messages, hundreds of points of view. It was not called the Net of a Million Lies for nothing. - Vernor Vinge, _A Fire Upon The Deep_ _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
> | This is the original reason for the original defect (issue 10278)
> | unix' clock() doesn't actually provide a clock in this sense, it provides a resource usage metric. > > Yeah:-( Its help says "Return the CPU time or real time since [...]". > Two very different things, as demonstrated. I suppose neither goes > backwards, but this seems like a classic example of the "useless > monotonic clock" against which Greg Ewing railed. > > And why? For one thing, because one can't inspect its metadata to find > out what it does. Should I add another key to the result of time.get_clock_info('clock')? How can we define "clock on Windows" (almost monotonic and steady clock) vs "clock on UNIX" (CPU time) with a flag or a value? Victor _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by zooko
> 2. Those who think that "monotonic clock" means a clock that never
> jumps, and that runs at a rate approximating the rate of real time. > This is a very useful kind of clock to have! It is what C++ now calls > a "steady clock". It is what all the major operating systems provide. For the "C++" part, I suppose that you are thinking to: "Objects of class steady_clock represent clocks for which values of time_point advance at a steady rate relative to real time. That is, the clock may not be adjusted." http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady I don't understand this definition. All clocks have a clock drift. This is just one exception: atomic clocks, but such clocks are rare and very expensive. http://www.clocktypes.com/buy_atomic_clocks.html "Atomic clocks can have a high price, but if you really want to buy one there is at least one place you can purchase an atomic clock. Agilent Technologies (www.agilient.com) Model number 5071A atomic clock with a long-term stability better than 1 x 10-14 price - $50,390" There is a simple "trick" to get a very cheap steady clock: adjust the clock manually. Extract of a Wikipedia article: "More advanced clocks and old mechanical clocks often have some kind of speed trimmer where one can adjust the speed of the clock and thus reduce the clock drift. For instance, in pendulum clocks the clock drift can be manipulated by slightly changing the length of the pendulum." http://en.wikipedia.org/wiki/Clock_drift Or you can use a NTP daemon to adjust automatically using a free farm of atomic clocks distributed around the world. So you can get a cheap steady clock if you accept that (OMG!) it can be adjusted. Or did I misunderstand "the clock may not be adjusted"? Victor _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by Victor Stinner-3
On Fri, Apr 6, 2012 at 11:32 PM, Victor Stinner
<[hidden email]> wrote: > On Linux, I now prefer > to use CLOCK_MONOTONIC (monotonic) than CLOCK_MONOTONIC_RAW > (monotonic and steady as defined by C++) *because* its frequency is > adjusted. I don't think that's a reason that should be considered. There just doesn't seem to be a single best clock, nor do clocks of similar character seem to be easy to find across platforms. So the reasons I'd like to see are of the form "we should provide CLOCK_MONOTONIC on Linux as one of our small selection of recommended clocks *because* the frequency adjustment makes it *most* useful in use-cases A and B, and it's a *reasonable* choice in use-case C *but* we need to document that it's a terrible choice for use-case D." Why do I ask for this kind of argument? Because there are only a few people (you, Glyph, Zooko) who seem to have studied clocks closely enough to be able to evaluate the technical issues involved in "*this* clock is good/mediocre/unusable in *that* use case." I'm happy to leave such judgments up to you guys. What the rest of us can contribute is (a) use cases to consider and (b) our opinions on the relative importance of various use cases in whether we should recommend a particular clock (ie, provide a named API in the stdlib for it). _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by Victor Stinner-3
On Sat, Apr 7, 2012 at 8:47 AM, Victor Stinner <[hidden email]> wrote:
> "Objects of class steady_clock represent clocks for which values of > time_point advance at a steady rate relative to real time. That is, > the clock may not be adjusted." > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady > > I don't understand this definition. All clocks have a clock drift. [[...]] > you can use a NTP daemon to adjust automatically using a free farm > of atomic clocks distributed around the world. That's inside the black box; C++ doesn't care about *how* the clock is made to be steady by the system. The system could incorporate an atomic clock, or it could use NTP to keep the clock closely corresponding to physical time. The C++ program doesn't ask, and the system shouldn't tell. > So you can get a cheap steady clock if you accept that (OMG!) it can > be adjusted. > > Or did I misunderstand "the clock may not be adjusted"? I think you are not keeping your context consistent with the viewpoint of the C++ committee. To the C++ committee, a steady clock may be expected to "just keep ticking" as far as the C++ program is concerned. What this means is that the clock value is incremented in sequence: it never goes backward, and it never "jumps over" a possible time value. How closely that "ticking" approximates physical time is Somebody Else's Problem; C++ simply assumes that it does. In other words, a clock adjustment in the C++ standard means that the clock's reported time values occur out of sequence. However, if the intervals between clock ticks are adjusted by NTP (or by a little old Swiss watchmaker moving the pendulum bob) in order to improve its steadiness (ie, accurate correspondence to physical time), C++ doesn't know about that, and doesn't care. Amusingly enough, various people's statements about common usage of "monotonic" notwithstanding, C++'s definition of "monotonic" was "mathematically monotonic." Cf. N3092, 20.10.1. (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf) Regards, _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by Stephen J. Turnbull
On 7 April 2012 09:12, Stephen J. Turnbull <[hidden email]> wrote:
> > I don't think that's a reason that should be considered. There just > doesn't seem to be a single best clock, nor do clocks of similar > character seem to be easy to find across platforms. So the reasons > I'd like to see are of the form "we should provide CLOCK_MONOTONIC on > Linux as one of our small selection of recommended clocks *because* > the frequency adjustment makes it *most* useful in use-cases A and B, > and it's a *reasonable* choice in use-case C *but* we need to document > that it's a terrible choice for use-case D." >From the PEP: """ Use cases: Display the current time to a human (e.g. display a calendar or draw a wall clock): use system clock, i.e. time.time() or datetime.datetime.now(). Event scheduler, timeout: time.monotonic(). Benchmark, profiling: time.clock() on Windows, time.monotonic(), or fallback to time.time() Functions To fulfill the use cases, the functions' properties are: time.time(): system clock, "wall clock". time.monotonic(): monotonic clock time.get_clock_info(name): get information on the specified time function """ That broadly covers it, I'd say. There are 2 main exceptions I see: (1) your suggestion of "explain why clock X is a terrible choice for use case Y" isn't there, although I'm not sure how important that is, and (2) there's no really good cross-platform option given for benchmarking/profiling (time.clock() is fine on Windows, but it gives CPU time on Unix - is that acceptable?) Also, Victor - you missed time.clock() from "Functions". Was that deliberate because it's sometimes CPU time? Maybe it should be added for clarity? Paul. _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
Re: this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
|
|
In reply to this post by Victor Stinner-3
On 07Apr2012 01:47, Victor Stinner <[hidden email]> wrote:
| I don't understand this definition. All clocks have a clock drift. | This is just one exception: atomic clocks, but such clocks are rare | and very expensive. They've got drift too. It is generally very small. Anecdote: I used to keep my wristwatch (oh, the days of wrist watches:-) synched to an atomic clock. By walking 4 metres down the hall from my office to peer into the window of the room with the atomic clock:-) Cheers, -- Cameron Simpson <[hidden email]> DoD#743 http://www.cskk.ezoshosting.com/cs/ Knox's 386 is slick. Fox in Sox, on Knox's Box Knox's box is very quick. Plays lots of LSL. He's sick! - Gregory Bond <[hidden email]>, (Apologies to John "Iron Bar" Mackin.) _______________________________________________ Python-Dev mailing list [hidden email] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%2B1324100855712-1801473%40n6.nabble.com |
«
Return to Python - python-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |