lua_numbertointeger - 为什么我们可以假设INT_MIN在浮点数中具有精确表示?

Lua将数字存储在内部作为整数或浮点数。在两种不同类型的数字之间进行比较操作(例如小于)时,它需要转换一种类型以进行比较。

整数和浮点类型取决于配置/平台,但会做出某些假设。(我只对“正常”的32位或64位二进制补码整数和32位或64位IEEE754浮点类型感兴趣)。

当整数类型可能没有在浮点格式中具有精确表示时,Lua尝试将浮点值转换为整数。

这在宏“lua_numbertointeger”中完成:

/*
@@ lua_numbertointeger将具有整数值的浮点数转换为整数,
** 如果浮点数不在lua_Integer的范围内,则返回0。 (由于
** 舍入而导致的范围比较很棘手。这里的测试假定有二
** 补码表示方式,在此情况下,MININTEGER在浮点格式中始
** 终具有精确的表示形式。MAXINTEGER可能没有这种形式,
** 因此其转换为浮点格式时可能有一个非法的值。)
*/
#define lua_numbertointeger(n,p) \
  ((n) >= (LUA_NUMBER)(LUA_MININTEGER) && \
   (n) < -(LUA_NUMBER)(LUA_MININTEGER) && \
      (*(p) = (LUA_INTEGER)(n), 1))

因此,我的问题是:

假设“LUA_NUMBER”是32位的“float”,而“LUA_INTEGER”是32位的“int”,为什么我们可以假设“LUA_MIN_INTEGER”(即“INT_MIN”)在浮点类型中具有精确表示。

(对于64位整数和64位浮点数也一样...它能在64位整数和32位浮点数上工作吗?)

点赞
用户4142924
用户4142924

在二进制补码表示中,最小值通常只有1位被设置,例如 C 语言中的 INT_MIN,可能是 0x80000000。因此,它可以在 float 中被准确表示,因为它只有一个重要位,并且可以在不丢失精度的情况下规范化。

但是 INT_MAX,例如 0x7FFFFFFF,有31个重要位,比 float 的有效数字还要多,因此它不能在 float 中准确表示。

2021-06-19 14:28:36
用户2410359
用户2410359

INT_MIN 作为 2 的补码,是 2 的幂(取负)并且有一个精确的 FP 表示。因此 (n) >= (LUA_NUMBER)(LUA_MININTEGER) 中的数学运算是精确的,没有转换或舍入误差。(潜在的范围异常 128 位 int 和 32 位 float

然而,在 if() 测试中存在一个 64 位浮点和 32 位 int 的功能问题。

在一个边缘情况下,lua_numbertointeger(n,p) 是错误的。因为 (LUA_INTEGER)(n) 截断了 n 的小数部分,我希望正确的前面的 if 测试是 (n) - (LUA_NUMBER)(LUA_MININTEGER) > -1 ...,而不是 (n) >= (LUA_NUMBER)(LUA_MININTEGER)。这允许将值在 (LUA_MININTEGER - 1 ... LUA_MININTEGER) 转换。

转换的值范围应该是

(INT_MIN - 1 .... INT_MAX + 1)
// 而不是
[INT_MIN     .... INT_MAX + 1)
2021-06-19 15:05:20