In an article about "AWK As A Major Systems Programming Language"[*]
(in chapter 5.3 "Future Work") we can read:
"Some issues are known and may not be resolvable. For example,
64-bit integer values such as the timestamps in stat() data on
modern systems don’t fit into awk’s 64-bit double-precision
numbers which only have 53 bits of significand. This is also a
problem for the bit-manipulation functions."
I was a bit astonished to read that; I thought that IEEE 80-bit FP
(with a 64 bit mantissa) would be standard nowadays. Not in GNU Awk,
or, generally not in applications?
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
In an article about "AWK As A Major Systems Programming Language"[*]
(in chapter 5.3 "Future Work") we can read:
"Some issues are known and may not be resolvable. For example,
64-bit integer values such as the timestamps in stat() data on
modern systems don’t fit into awk’s 64-bit double-precision
numbers which only have 53 bits of significand. This is also a
problem for the bit-manipulation functions."
I was a bit astonished to read that; I thought that IEEE 80-bit FP
(with a 64 bit mantissa) would be standard nowadays. Not in GNU Awk,
or, generally not in applications?
True -- but a 64-bit time_t value can be stored in a 64-bit IEEE double without loss of information as long as it's not too big.
The smallest
positive integer that can't be represented exactly in a 64-bit IEEE
double is 2**53+1; as a time_t. That's around 285 billion years in the future.
[...]
On 20.01.2023 18:53, Keith Thompson wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
In an article about "AWK As A Major Systems Programming Language"[*]
(in chapter 5.3 "Future Work") we can read:
"Some issues are known and may not be resolvable. For example,
64-bit integer values such as the timestamps in stat() data on
modern systems don’t fit into awk’s 64-bit double-precision
numbers which only have 53 bits of significand. This is also a
problem for the bit-manipulation functions."
I was a bit astonished to read that; I thought that IEEE 80-bit FP
(with a 64 bit mantissa) would be standard nowadays. Not in GNU Awk,
or, generally not in applications?
True -- but a 64-bit time_t value can be stored in a 64-bit IEEE double
without loss of information as long as it's not too big.
Yes. - My point was that a [standard] 80 bit FP number would have a
64 bit mantissa that allows lossless storage (in the mantissa) while
simply ignoring the signs/exponent parts; for gawk 64 bit operations
and 64 bit time_t. If implementation [of gawk] would technically use
an 80 bit "carrier" (instead of a 64 bit "long integer") the issues
mentioned might not be an issue. Or are you saying that the "problem" mentioned by the article is just a gawk implementation issue to not
use the "64 bit carrier" sophisticatedly (and instead unnecessarily
try to use only the 56 bit mantissa or the long integer)?
The smallest
positive integer that can't be represented exactly in a 64-bit IEEE
double is 2**53+1; as a time_t. That's around 285 billion years in the
future.
[...]
Different implementations of awk might use different floating-point representations on different platforms. I don't think the
characteristics of floating-point are defined by the language.
(Is there even a formal language definition?)
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 790 |
Nodes: | 10 (0 / 10) |
Uptime: | 192:51:52 |
Calls: | 11,043 |
Files: | 186,065 |
Messages: | 1,743,688 |