Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

(time) PEP 418 glossary V2

 

 

Python dev RSS feed   Index | Next | Previous | View Threaded


jimjjewett at gmail

Apr 23, 2012, 6:58 PM

Post #1 of 9 (419 views)
Permalink
(time) PEP 418 glossary V2

Glossary
========

Absolute Time
-------------

A measurement of time since a specific Epoch_, typically far in the
past. Civil Time is the most common example. Typically contrasted
with a `Duration`_, as (now - epoch) is generally much larger than
any duration that can be appropriately measured with the clock in
question.

Accuracy
--------

The amount of deviation of measurements by a given instrument from true
values. See also the wikipedia article on `Accuracy and precision
<http://en.wikipedia.org/wiki/Accuracy_and_precision>`_.

Inaccuracy in clocks may be caused by lack of `Precision`_, by
`Drift`_, or by an incorrect initial setting of the clock (e.g., timing
of threads is inherently inaccurate because perfect synchronization in
resetting counters is quite difficult).

Adjusted
--------

Resetting a clock, presumably to the correct time. This may be done
either with a `Step`_ or with `Slew`_. Adjusting a clock normally
makes it more accurate with respect to the `Absolute Time`_. The cost
is that any durations currently being measured will show a `Bias`_.
(17 ticks is not the same Duration_ as 17 ticks plus an adjustment.)

Bias
----

Lack of accuracy that is systematically in one direction, as opposed to
random errors. When a clock is `Adjusted`_, durations overlapping the
adjustment will show a Bias.

Civil Time
----------

Time of day; external to the system. 10:45:13am is a Civil time;
A Duration_ like "45 seconds" is not a Civil time. Provided by
existing functions ``time.localtime()`` and ``time.gmtime()``, which
are not changed by this PEP.

Clock
-----

An instrument for measuring time. Different clocks have different
characteristics; for example, a clock with nanosecond Precision_ may
start to Drift_ after a few minutes, while a less precise clock
remained accurate for days.

This PEP is primarily concerned with clocks which use a unit of
seconds, rather than years, or arbitrary units such as a Tick_.

Counter
-------

A clock which increments each time a certain event occurs. A counter
is strictly monotonic in the mathematical sense, but does not meet
the typical definitions of Monotonic_ when used of a computer clock.
It can be used to generate a unique (and ordered) timestamp, but these
timestamps cannot be mapped to `Civil Time`_; Tick_ creation may well
be bursty, with several advances in the same millisecond followed
by several days without any advance.

CPU Time
--------

A measure of how much CPU effort has been spent on a certain task.
CPU seconds are often normalized (so that a variable number can
occur in the same actual second). CPU seconds can be important
when profiling, but they do not map directly to user response time,
nor are they directly comparable to (real time) seconds.

Drift
-----

The accumulated error against "true" time, as defined externally to the
system. Drift may be due to imprecision, or to a difference between
the average rate at which clock time advances and that of real time.

Drift does not include intentional adjustments, but clocks providing
`Absolute Time`_ will eventually have to be Adjusted_ to compensate
for drift.

Duration
--------

Elapsed time. The difference between the starting and ending times.
Also called Relative Time. Normally contrasted with `Absolute Time`_.

While a defined Epoch_ technically creates an implicit duration, this
duration is normally too large to be of practical use.

Computers can often supply a clock with better Precision_ or higher
Resolution_ if they do not have to guarantee meaningful comparisons to
any times not generated by the clock itself.

Epoch
-----

The reference point of a clock. For clocks providing `Civil Time`_,
this is often midnight as the day (and year) rolled over to
January 1, 1970. A Monotonic_ clock will typically have an undefined
epoch (represented as None).

Latency
-------

Delay. By the time a call to a clock function returns, `Real Time`_
has advanced, possibly by more than the precision of the clock.

Monotonic
---------

This is a particularly tricky term, as there are several subtly
incompatible definitions in use. C++ followed the mathematical
definition, so that a monotonic clock only promises not to go
backwards. In practice, that is not sufficient to be useful, and no
Operating System provides such a weak guarantee. Most discussions
of a "Monotonic *Clock*" will also assume several additional
guarantees, some of which are explicitly required by the POSIX
specification.

Within this PEP (and Python), the intended meaning is closer to
"the characteristics expected of a monotonic clock in practice".
In addition to not moving backward, a Monotonic Clock should also be
Steady_, and should be convertible to a unit of seconds. The tradeoffs
often include lack of a defined Epoch_ or mapping to `Civil Time`_,
and being more expensive (in `Latency`_, power usage, or duration spent
within calls to the clock itself) to use. For example, the clock may
represent (a constant multiplied by) ticks of a specific quartz timer
on a specific CPU core, and calls would therefore require
synchronization between cores.

Precision
---------

This is another tricky term, as there are several different meanings
which are relevant.

This PEP (and python) uses the most common meaning from natural
sciences: "The amount of deviation among measurements of the same
physical value by a single instrument." Imprecision in clocks may be
caused by a fluctuation of the rate at which clock time advances
relative to `Real Time`_, including intentional clock adjustments
by slewing.

Note that this is different from the typical computer language meaning
of how many digits to show (perhaps better called resolution).

Note that this is also different from at least one time-related meaning
of precision used in at least some sources. That usage assumes that a
clock is an oscillator with a given frequency, and measures the
precision with which that oscillator tracks its target frequency,
irrespective of how precisely the computer can read the resulting time.

Note that "precision" as reported by the clock itself may use yet
another definition, and may differ between clocks.

Process Time
------------

Time elapsed since the process began. It is typically measured in
`CPU time`_ rather than `Real Time`_, and typically does not advance
while the process is suspended.

Real Time
---------

Time in the real world. This differs from `Civil time`_ in that it is
not `Adjusted`_, but they should otherwise advance in lockstep.

It is not related to the "real time" of "Real Time [Operating]
Systems". It is sometimes called "wall clock time" to avoid that
ambiguity; unfortunately, that introduces different ambiguities.

Resolution
----------

The smallest difference between two physical values that results
in a different measurement by a given instrument.

Note that the above is in the ideal case; computer clocks in particular
are often prone to reporting more resolution than they can actually
distinguish.

Slew
----

A slight change to a clock's speed, usually intended to correct Drift_
with respect to an external authority. In other words, the Precision_
is (temporarily) intentionally reduced by some `Bias`_, and short
Duration_ measurements become less comparable, in return for providing
a more accurate `Absolute Time`_.

Stability
---------

Persistence of accuracy. A measure of expected `Drift`_.

Steady
------

A clock with high Stability_ and relatively high Accuracy_ and
`Precision`_. In practice, it is often used to indicate a Monotonic_
clock. In theory, "steady" places greater emphasis on the consistency
of the duration between subsequent ticks; in practice it may simply
indicate more familiarity with C++ than with Posix.

Step
----

An instantaneous change in the represented time. Instead of speeding
or slowing the clock (`Slew`_), a single offset is permanently added.

System Time
-----------

Time as represented by the Operating System.

Thread Time
-----------

Time elapsed since the thread began. It is typically measured in
`CPU time`_ rather than `Real Time`_, and typically does not advance
while the thread is idle.

Tick
----

A single increment of a `Counter`_. Generally used to indicate what
the raw hardware provides, before multiplying by a constant to get
seconds.

Wallclock
---------

Also Wall Clock, Wall Time. What the clock on the wall says. This is
typically used as a synonym for `Real Time`_; unfortunately, wall time
is itself ambiguous, particularly (but not only) between Real Time and
`Civil Time`_.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

Apr 23, 2012, 9:31 PM

Post #2 of 9 (412 views)
Permalink
Re: (time) PEP 418 glossary V2 [In reply to]

I like the updated glossary - very good summary of the relevant
terminology and common points of confusion. One minor gripe below (and
it *is* minor, despite the amount of text explaining my point of
view...)

On Tue, Apr 24, 2012 at 11:58 AM, Jim Jewett <jimjjewett [at] gmail> wrote:
> Real Time
> ---------
>
> Time in the real world. This differs from `Civil time`_ in that it is
> not `Adjusted`_, but they should otherwise advance in lockstep.
>
> It is not related to the "real time" of "Real Time [Operating]
> Systems". It is sometimes called "wall clock time" to avoid that
> ambiguity; unfortunately, that introduces different ambiguities.

"Not related" is simply not true, as this is the exact meaning of
"Real Time" in the term "Real Time Operating System". In the PEP's
terms, a Real Time OS is simply an operating system specifically
designed to allow developers to meet deadlines expressed as the
maximum permitted Real Time Duration between an event occurring and
the system responding to that event.

The power an RTOS gives you over an ordinary OS is sufficiently low
level control over the scheduler (if there's even an entity worth of
the name "scheduler" at all) such that you can *demonstrably* meet
hard real time deadlines (down to a certain lower limit, generally
constrained by hardware). It's a pain to program that way though (and
adequately demonstrating correctness gets harder as the code gets more
complicated), so you often want to use a dedicated processor for the
RTOS bits and a separate processor (with an ordinary OS) for
everything else. (There's a good explanation of many of these
concepts, include separating the hard realtime parts from everything
else, in the Giant Robots of Doom talk from PyCon AU 2010:
http://pyvideo.org/video/481/pyconau-2010--hard-real-time-python--or--giant-ro)

One interesting aspect of using a normal OS is that you can *never*
reliably read a Real Time clock in user level code - the scheduler
doesn't provide adequate guarantees of responsiveness, so there's
always going to be some scheduling jitter in the results. This
generally doesn't matter for measuring durations within a machine
(since the jitter will, with a sufficiently large number of samples,
cancel out between the two measurements), but can be a problem for
absolute time measurements that are intended to be compared with high
precision across different machines.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


stephen at xemacs

Apr 24, 2012, 12:26 AM

Post #3 of 9 (402 views)
Permalink
Re: (time) PEP 418 glossary V2 [In reply to]

Very nice! Two possible clarifications:

On Tue, Apr 24, 2012 at 10:58 AM, Jim Jewett <jimjjewett [at] gmail> wrote:
> Glossary
> ========
> Bias
> ----
>
> Lack of accuracy that is systematically in one direction, as opposed to
> random errors. When a clock is `Adjusted`_, durations overlapping the
> adjustment will show a Bias.

"Conversely, if the clock has experienced `Drift`_, its reports of
`Absolute Time`_ will show Bias until the adjustment takes place."


> Counter
> -------
>
> A clock which increments each time a certain event occurs. A counter
> is strictly monotonic in the mathematical sense, but does not meet
> the typical definitions of Monotonic_ when used of a computer clock.
> It can be used to generate a unique (and ordered) timestamp, but these
> timestamps cannot be mapped to `Civil Time`_; Tick_ creation may well

"mapped" -> "algorithmically mapped"

> be bursty, with several advances in the same millisecond followed
> by several days without any advance.
> Duration_ measurements become less comparable, in return for providing
> a more accurate `Absolute Time`_.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Apr 24, 2012, 3:38 AM

Post #4 of 9 (406 views)
Permalink
Re: (time) PEP 418 glossary V2 [In reply to]

> Monotonic
> ---------
>
> This is a particularly tricky term, as there are several subtly
> incompatible definitions in use.

Is it a definition for the glossary?

>  C++ followed the mathematical
> definition, so that a monotonic clock only promises not to go
> backwards.

The "C++ Timeout Specification" doesn't have any monotonic anymore. It
has a steady_clock, but it's something different.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.monotonic

>  In practice, that is not sufficient to be useful, and no
> Operating System provides such a weak guarantee.  Most discussions
> of a "Monotonic *Clock*" will also assume several additional
> guarantees, some of which are explicitly required by the POSIX
> specification.

What do you mean for POSIX? The definition of CLOCK_MONOTONIC by the
POSIX specification is:

"The identifier for the system-wide monotonic clock, which is defined
as a clock whose value cannot be set via clock_settime() and which
cannot have backward clock jumps. The maximum possible clock jump
shall be implementation-defined."
http://pubs.opengroup.org/onlinepubs/000095399/basedefs/time.h.html

time.monotonic() of the PEP 418 gives the same guarantee (cannot go
backward, cannot be set), except for "system-wide" (Python cannot give
this guarantee because of Windows older than Vista).

>  The tradeoffs
> often include lack of a defined Epoch_ or mapping to `Civil Time`_,

I don't know any monotonic with a defined epoch or mappable to the civil time.

> and being more expensive (in `Latency`_, power usage, or duration spent
> within calls to the clock itself) to use.

CLOCK_MONOTONIC and CLOCK_REALTIME have the same performances on Linux
and FreeBSD. Why would a monotonic clock be more expensive?

>  For example, the clock may
> represent (a constant multiplied by) ticks of a specific quartz timer
> on a specific CPU core, and calls would therefore require
> synchronization between cores.

I don't think that synchronizing a counter between CPU cores is
something expensive. See the following tables for details:
http://www.python.org/dev/peps/pep-0418/#performance

CLOCK_MONOTONIC and CLOCK_REALTIME use the same hardware clocksource
and so have the same latency depending on the hardware.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Apr 24, 2012, 3:47 AM

Post #5 of 9 (408 views)
Permalink
Re: (time) PEP 418 glossary V2 [In reply to]

> Precision
> ---------
>
> This is another tricky term,

This is a good reason why it is no more used in the PEP :-)

> Note that "precision" as reported by the clock itself may use yet
> another definition, and may differ between clocks.

Some C function provides the frequency of the clock (and so its
resolution), or directly the resolution, but I don't know any function
providing the precision.

I thought that clock_getres() is the precision, but I was wrong.
clock_getres() is really the resolution announced by the OS, even if
the OS may be pessimistic (and so wrong, ex: OpenBSD and Solaris). But
Python should not try to workaround OS "bugs".

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


jimjjewett at gmail

Apr 24, 2012, 9:19 AM

Post #6 of 9 (397 views)
Permalink
Re: (time) PEP 418 glossary V2 [In reply to]

On Tue, Apr 24, 2012 at 6:38 AM, Victor Stinner
<victor.stinner [at] gmail> wrote:
>> Monotonic
>> ---------

>> This is a particularly tricky term, as there are several subtly
>> incompatible definitions in use.

> Is it a definition for the glossary?

One use case for a PEP is that someone who does *not* have a
background in the area wants to start learning about it. Even
excluding the general service of education, these people can be
valuable contributors, because they have a fresh perspective. They
will almost certainly waste some time retracing dead ends, but I would
prefer it be out of a need to prove things to themselves, instead of
just because they misunderstood.

Given the amount of noise we already went through arguing over what
"Monotonic" should mean, I think we have an obligation to provide
these people with a heads-up, even if we don't end up using the term
ourselves. And I think we *will* use the terms ourselves, if only as
some of the raw os_clock_* choices.

>> C++ followed the mathematical definition
>> ... a monotonic clock only promises not to go backwards.
>> ... additional guarantees, some ... required by the POSIX

Confession:

I based the above statements strictly on posts to python-dev, from
people who seemed to have some experience caring about clock details.

I did not find the relevant portions of either specification.[1]
Every time I started to search, I got pulled back to other tasks, and
the update was just delayed even longer. I still felt it was worth
consolidating the state of the discussion. Anyone who feels confident
in this domain is welcome to correct me, and encouraged to send
replacement text.

[1] Can I assume that Victor's links here are the relevant ones, or
is someone aware of additional/more complete references for these
specifications?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.monotonic
http://pubs.opengroup.org/onlinepubs/000095399/basedefs/time.h.html

>> The tradeoffs often include lack of a defined Epoch_
>> or mapping to `Civil Time`_,

> I don't know any monotonic with a defined epoch or
> mappable to the civil time.

The very basic "seconds (not even milliseconds) since the beginning of
1970" fits that definition, but doesn't seem to fit what most people
mean by "Monotonic Clock".

I'm still a little fuzzy on *why* it shouldn't count as a monotonic
clock. Is it technically valid, but a lousy implementation because of
insufficient precision or resolution? Is it because the functions
used in practice (on a modern OS) to retrieve timestamps don't
guarantee to ignore changes to the system clock?

>> and being more expensive (in `Latency`_, power usage, or duration spent
>> within calls to the clock itself) to use.

> CLOCK_MONOTONIC and CLOCK_REALTIME have the same performances on Linux
> and FreeBSD. Why would a monotonic clock be more expensive?

>> For example, the clock may
>> represent (a constant multiplied by) ticks of a specific quartz timer
>> on a specific CPU core, and calls would therefore require
>> synchronization between cores.

> I don't think that synchronizing a counter between CPU cores is
> something expensive. See the following tables for details:
> http://www.python.org/dev/peps/pep-0418/#performance

Synchronization is always relatively expensive. How expensive depends
on a lot of things decides before python was installed.

Looking at the first table there (Linux 3.3 with Intel Core i7-2600 at
3.40GHz (8 cores)), CLOCK_MONOTONIC can be hundreds of times slower
than time(), and over 50 times slower than CLOCK_MONOTONIC_COARSE. I
would assume that CLOCK_MONOTONIC_COARSE meets the technical
requirements for a monotonic clock, but does less well at meeting the
actual expectations for some combination of
(precision/stability/resolution).


> CLOCK_MONOTONIC and CLOCK_REALTIME use the same hardware clocksource
> and so have the same latency depending on the hardware.

Is this a rule of thumb or a requirement of some standard?

Does that fact that Windows, Mac OS X, and GNU/Hurd don't support
CLOCK_MONOTONIC indicate that there is a (perhaps informal?)
specification that none of their clocks meet, or does it only indicate
that they didn't like the name?

-jJ
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Apr 24, 2012, 9:35 AM

Post #7 of 9 (407 views)
Permalink
Re: (time) PEP 418 glossary V2 [In reply to]

>> I don't know any monotonic with a defined epoch or
>> mappable to the civil time.
>
> The very basic "seconds (not even milliseconds) since the beginning of
> 1970" fits that definition, but doesn't seem to fit what most people
> mean by "Monotonic Clock".
>
> I'm still a little fuzzy on *why* it shouldn't count as a monotonic
> clock.  Is it technically valid, but a lousy implementation because of
> insufficient precision or resolution?  Is it because the functions
> used in practice (on a modern OS) to retrieve timestamps don't
> guarantee to ignore changes to the system clock?

You mean the time() function? It is the system clock and the system
clock is not monotonic because it can jump backward. It is also
affected when... the system clock is changed :-)

> Looking at the first table there (Linux 3.3 with Intel Core i7-2600 at
> 3.40GHz (8 cores)), CLOCK_MONOTONIC can be hundreds of times slower
> than time(), and over 50 times slower than CLOCK_MONOTONIC_COARSE.  I
> would assume that CLOCK_MONOTONIC_COARSE meets the technical
> requirements for a monotonic clock, but does less well at meeting the
> actual expectations for some combination of
> (precision/stability/resolution).

I chose CLOCK_MONOTONIC instead of CLOCK_MONOTONIC_COARSE because I
bet that most people prefer a clock with an higher precision over a
faster clock. When the issue #14555 (Add more clock identifiers) will
be done, you will be able to call
time.clock_gettime(time.CLOCK_MONOTONIC_COARSE) in Python if you need
a faster monotonic clock.

>> CLOCK_MONOTONIC and CLOCK_REALTIME use the same hardware clocksource
>> and so have the same latency depending on the hardware.
>
> Is this a rule of thumb or a requirement of some standard?

It is how these clocks are implemented on Linux. I don't know how they
are implemented on other OSes. It was just to say that their
performance should be *very close* on Linux.

> Does that fact that Windows, Mac OS X, and GNU/Hurd don't support
> CLOCK_MONOTONIC indicate that there is a (perhaps informal?)
> specification that none of their clocks meet, or does it only indicate
> that they didn't like the name?

CLOCK_MONOTONIC requires the clock_gettime() function: clock_gettime()
is not available on Windows nor Mac OS X. For Hurd, see:
http://www.gnu.org/software/hurd/open_issues/clock_gettime.html

The PEP 418 uses other monotonic clocks for Windows and Mac OS X, but
GNU/Hurd is the only OS not supporting the new time.monotonic()
function.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


stephen at xemacs

Apr 24, 2012, 8:08 PM

Post #8 of 9 (392 views)
Permalink
Re: (time) PEP 418 glossary V2 [In reply to]

On Wed, Apr 25, 2012 at 1:19 AM, Jim Jewett <jimjjewett [at] gmail> wrote:

> I'm still a little fuzzy on *why* it shouldn't count as a monotonic
> clock.

So are the people who say it shouldn't count (unless you're speaking
of the specific implementation on Unix systems, which can go backward
if the admin or NTP decides it should be so). I think they are in
general mistaking their use case for a general specification, that's
all. Even Glyph cited "what other people seem to think" in supporting
the usage where "monotonic" implies "high quality" in some informal
sense, although he does have a spec for what high quality means, and
AIUI an API for it in Twisted.

I think we should just accept that "monotonic" is in more or less
common use as a synonym for "high quality", and warn *our* users that
the implementers of such clocks may be working to a different spec. I
think the revised glossary's description of "monotonic" does that
pretty well.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


steve at pearwood

Apr 25, 2012, 10:20 AM

Post #9 of 9 (380 views)
Permalink
Re: (time) PEP 418 glossary V2 [In reply to]

Stephen J. Turnbull wrote:
> On Wed, Apr 25, 2012 at 1:19 AM, Jim Jewett <jimjjewett [at] gmail> wrote:
>
>> I'm still a little fuzzy on *why* it shouldn't count as a monotonic
>> clock.
>
> So are the people who say it shouldn't count (unless you're speaking
> of the specific implementation on Unix systems, which can go backward
> if the admin or NTP decides it should be so).

The fact that the clock is not monotonic is a pretty good reason for it not to
count as monotonic. I don't think there's anything fuzzy about that.


> I think they are in
> general mistaking their use case for a general specification, that's
> all.

I'm sorry, am I missing something here? What use case are you talking about?


> Even Glyph cited "what other people seem to think" in supporting
> the usage where "monotonic" implies "high quality" in some informal
> sense, although he does have a spec for what high quality means, and
> AIUI an API for it in Twisted.

Who are these people who think monotonic is a synonym for "high quality"?

Why should we pander to their confusion at the cost of those who do understand
the difference between monotonic and high quality?


> I think we should just accept that "monotonic" is in more or less
> common use as a synonym for "high quality", and warn *our* users that
> the implementers of such clocks may be working to a different spec. I
> think the revised glossary's description of "monotonic" does that
> pretty well.

Do I understand correctly that you think it is acceptable to call something
monotonic regardless of whether or not it actually is monotonic?

If not, I'm not sure I understand what you are suggesting here.



--
Steven

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.