[Python-ideas] millisecond and microsecond times without floats

[Paul Sokolovsky]

Hello,

On Fri, 26 Jun 2015 18:00:44 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 26 June 2015 at 04:06,  <random832 at fastmail.us> wrote:
> > On Mon, Jun 22, 2015, at 19:15, Paul Sokolovsky 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?
> >
> > Allowing time (and stat, and the relevant functions of the datetime
> > module) to return any real numeric type rather than being required
> > to use float would be a useful extension.
> 
> It isn't the data type that's the problem per se, it's the additional
> abstraction layers - the time module assumes it's dealing with

Just to clarify, I tried to pose problem exactly as capturing right
level of abstraction, but implementation-wise, data type is important
for us (MicroPython) too. Specifically small integer is different from
most other types is that it's value type, not reference type, and so
it doesn't require memory allocation (will never trigger garbage
collection => no unpredictable pauses), and faster to work with (uPy
has ahead-of-type machine code compiler -> operations on word-sized
values approach (unoptimized) C performance).

But those are implementation details hidden by formulation of the
original task - we need integer-based time (Python has integers, so no
problems with that), and that time may and will wrap around at
implementation-specific intervals (so a particular implementation may
choose to represent it with efficient "small integer" type if it have
one).

Note that I also don't try to bloat the problem space and say "Guys,
why don't we have unsigned integers in Python?" or "Let's have a
generic builtin modular arithmetics module". None of those needed here.

> operating system provided timing functionality, rather than accessing
> timer hardware directly. Folks tend to think that the os and time
> modules are low level, but there's a wonderful saying that asks "How
> do you tell the difference between a software developer and a computer
> systems engineer?" Answer:
> 
> Software developer: "In a *low* level language like C..."
> Computer systems engineer: "In a *high* level language like C..."
> 
> Paul, what do you think of the idea of trying to come up with a
> "hwclock" module for MicroPython that aims to expose very, very low

Well, so on MicroPython side, having extra modules is expensive
(defining a module costs 100+ bytes, OMG! ;-)) That's why we have
catch-all "pyb" module so far, and see ways to put sensible extra stuff
into existing modules. So, my concern is function, not module, names and
sensible semantics of those functions.

To come up with general-purpose "hwclock" module, there would need to
be bigger cooperation from various parties and stakeholders. Neither
myself nor other MicroPython developers can lead that effort,
unfortunately. But it's my hope that if someone starts that effort,
they will grep Python lists first for prior art, and maybe fall into
arguments presented here, and select compatible API, then for us,
compatibility will be easy:

--- hwclock.py ---
from utime import *
------------------

And even if someone selects other API, we'll know that ours is the most
efficient building blocks we can have on our side, and can implement
compatibility layer in their terms.

> level timing functionality as you describe, and reserving that name
> for independent distribution on PyPI? Such a module could even
> eventually grow a plugin system to provide access to various real time
> clock modules in addition to the basic counter based clocks you're
> interested in right now.
> 
> Cheers,
> Nick.

[]


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