[Python-ideas] millisecond and microsecond times without floats

[Paul Sokolovsky]

Hello,

On Thu, 25 Jun 2015 14:06:38 -0400
random832 at fastmail.us wrote:

> > Hello from MicroPython, a lean Python implementation
> > scaling down to run even on microcontrollers 
> > (https://github.com/micropython/micropython).
> > 
> > Our target hardware base oftentimes lacks floating point support,
> > and using software emulation is expensive. So, we would like to have
> > versions of some timing functions, taking/returning millisecond
> > and/or microsecond values as integers.
> 
> What about having a fixed-point decimal numeric type to be used for
> this purpose?

The problem is actually not even in floating point per se. For example,
reference hardware board for MicroPython is built on a relatively
powerful microcontroller which has hardware floating point. But
only single-precision floating point (IEEE 32-bit). And you won't read
it at https://docs.python.org/3/library/time.html or PEP418 - it's just
implied - that you don't just need floating point for those functions,
it should be floating point of specific mantissa requirements. Let's
count:

time.time() returns the time in seconds since the epoch (1 Jan 1970) as
a floating point number.

That means that mantissa already should be at least 32 bits.
Single-precision FP has 23 mantissa bits, so it's already ruled out
from suitable representation of time.time() value.

Then, we need 10 extra mantissa bits for each SI decimal subunit (2^10
== 1024). Double-precision FP has 52 mantissa bits. We can store
millisecond precision there, we can store microsecond precision there.
But - oops - going further, we hit the same problem as MicroPython
hit right away: it's not possible to represent the same calendar data
range as Unix time() call, but with higher resolution than microsecond.

Of course, PEP418 provides one direction to work that around - by
using other epochs than Jan 1, 1970 with all these new functions like
monotonic() (which is specified as "reference point of the returned
value is undefined"). It still implicitly assumes there's enough bits
so wrap-arounds can be ignored.

My proposal works around issue in another direction - by embracing the
fact that any fixed-size counter wraps around and preparing to deal with
that. All that in turn enables to use just integer values for
representing times.

And why it's useful (implementation-wise) to be able to use integer
values, I elaborated in another recent mail.

[]

-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com