[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: current-time and GMP
From: |
Stefan Monnier |
Subject: |
Re: current-time and GMP |
Date: |
Wed, 29 Aug 2018 15:16:44 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>> - use GMP's mpf or mpq numbers (that seems like a lot of work for this
>> only use, tho I guess we could then use those numbers in Calc as
>> well).
> Since the underlying nominal precision is typically nanoseconds, mpf is
> unsatisfactory since it's inexact,
Indeed, the problem with it is that mpf works with binary rather decimal
exponents so it can't represent exactly the 10^-9 of nanoseconds.
> and mpq's canonicalization would lose useful information about
> timestamp resolution.
Not sure to what extend knowledge about the resolution is important here.
> Also, as you mention, both approaches are overkill for timestamps.
That's right.
> Furthermore, we extend existing timestamp functions to accept the form (A),
> where A is an integer, to stand for a timestamp with count A using
> clock-resolution ticks per second since the epoch.
I guess in practice it might work fine, but I'm uncomfortable with the
idea of using a representation that depends on `clock-resolution`, so if
you print a timestamp with one Emacs and read it with another they may
disagree (in a big way) about what it means (if one Emacs uses
nanoseconds while the other uses picoseconds resolution).
> Finally, let's deprecate the long-obsolete timestamp form (A . B)
> where A and B are integers,
Sounds good.
> so that future Emacs versions can support a new
> format where B is the timestamp resolution.
Right, I think (INTEGER-TIMESTAMP . RESOLUTION) would be a nice
representation. We can additionally (and temporarily) signal an
error/warning if INTEGER-TIMESTAMP (and/or RESOLUTION) is "too small"
(indicating a very likely use of the deprecated (HOGH . LOW)
representation).
Stefan