<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Thu, Apr 5, 2012 at 7:14 PM, Greg Ewing <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><br>Yep. As far as I can tell, nobody has a use for an unsteady, monotonic clock.<br><br>There seem to be two groups of people:<br><br>1. Those who think that "monotonic clock" means a clock that never<br>goes backwards. These people are in the majority. After all, that's<br>what the word "monotonic" means ¹ . However, a clock which guarantees<br>*only* this is useless.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div>2. Those who think that "monotonic clock" means a clock that never<br>jumps, and that runs at a rate approximating the rate of real time.<br>This is a very useful kind of clock to have! It is what C++ now calls<br>a "steady clock". It is what all the major operating systems provide.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>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, <<a href="http://twistedmatrix.com/trac/ticket/2424#comment:26">http://twistedmatrix.com/trac/ticket/2424#comment:26</a>>, but you need an event loop for that, because you need to be able to register interest in that event.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div>The people in class 1 are more correct, technically, and far more<br>numerous, but the concept from 1 is a useless concept that should be<br>forgotten.<br></div></blockquote><div><br></div><div>Technically correct; the best kind of correct!</div><div><br></div><div>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".</div><div><br></div><div>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.</div><br><blockquote type="cite"><div>So before proceeding, we should mutually agree that we have no<br>interest in implementing a clock of type 1. It wouldn't serve anyone's<br>use case (correct me if I'm wrong!) and the major operating systems<br>don't offer such a thing anyway.<br></div></blockquote><div><br></div><div>+1.</div><div><br></div><blockquote type="cite"><div>Then, if we all agree to stop thinking about that first concept, then<br>we need to agree whether we're all going to use the word "monotonic<br>clock" to refer to the second concept, or if we're going to use a<br>different word (such as "steady clock") to refer to the second<br>concept. I would prefer the latter, as it will relieve us of the need<br>to repeatedly explain to newcomers: "That word doesn't mean what you<br>think it means.".<br></div></blockquote><div><br></div><div>I don't think anything can (or should) relieve that need.</div><div><br></div><div>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 :-).</div><div><br></div><div>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)".</div><div><br></div><blockquote type="cite"><div>The main reason to use the word "monotonic clock" to refer to the<br>second concept is that POSIX does so, but since Mac OS X, Solaris,<br>Windows, and C++ have all avoided following POSIX's mistake, I think<br>Python should too.<br></div></blockquote><div><br></div><div>Do you just mean that the APIs don't have "monotonic" in the name? They all use <i>different</i> words, which strikes me as more of a failure than a success, in the realm of making mistakes about communicating things :).</div><br><blockquote type="cite"><div>Regards,<br><br>Zooko<br><br>¹ <a href="http://mathworld.wolfram.com/MonotonicSequence.html">http://mathworld.wolfram.com/MonotonicSequence.html</a><br>_______________________________________________<br>Python-Dev mailing list<br><a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>http://mail.python.org/mailman/listinfo/python-dev<br>Unsubscribe: http://mail.python.org/mailman/options/python-dev/glyph%40twistedmatrix.com<br></div></blockquote></div><br></body></html>