mirror of
git://git.sv.gnu.org/emacs.git
synced 2025-12-06 06:20:55 -08:00
Fix FIXME in comment
* src/timefns.c (decode_float_time): Explain why the code can use large precision here, removing a FIXME by updating the containing comment.
This commit is contained in:
parent
77e3a56507
commit
2b848a4e50
1 changed files with 5 additions and 3 deletions
|
|
@ -414,9 +414,11 @@ decode_float_time (double t, struct lisp_time *result)
|
||||||
else
|
else
|
||||||
{
|
{
|
||||||
int scale = double_integer_scale (t);
|
int scale = double_integer_scale (t);
|
||||||
/* FIXME: `double_integer_scale` often returns values that are
|
/* Because SCALE treats trailing zeros in T as significant,
|
||||||
"pessimistic" (i.e. larger than necessary), so 3.5 gets converted
|
on typical platforms with IEEE floating point
|
||||||
to (7881299347898368 . 2251799813685248) rather than (7 . 2).
|
(time-convert 3.5 t) yields (7881299347898368 . 2251799813685248),
|
||||||
|
a precision of 2**-51 s, not (7 . 2), a precision of 0.5 s.
|
||||||
|
Although numerically correct, this generates largish integers.
|
||||||
On 64bit systems, this should not matter very much, tho. */
|
On 64bit systems, this should not matter very much, tho. */
|
||||||
eassume (scale < flt_radix_power_size);
|
eassume (scale < flt_radix_power_size);
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue