为什么没有比符号和幅度更好的浮点数表示方法?

发布于 2024-08-29 13:40:51 字数 137 浏览 9 评论 0原文

我们有整数的 2 补码,它允许我们执行运算而不必担心符号。这对实施层面有很大帮助。

同样,我们有如此多的浮点运算,但我们依赖符号和幅度。原因是什么?

为什么类似 2 的补码系统不能用于浮点数?

We have 2's complement for integers that allows us to perform operations without worrying about the sign. That is a big help at the implementation level.

Similarly we have so many floating point operations and yet we rely on sign and magnitude. What is the reason?

Why can't a 2's complement like system work for floats?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

昨迟人 2024-09-05 13:40:51

对于浮点数的加法,需要做的事情比整数情况要多得多 - 您需要移动一个值以使指数匹配。相比之下,进行符号+幅度相加的任何额外成本都是微不足道的。

另请注意,单独的符号位对于乘法要好得多 - 您只需要一个无符号乘法器来处理所有情况,并单独处理符号位。将此与补码乘法进行比较,您必须标准化符号或支持有符号/无符号乘法。

For addition of floats there is a lot more to do than in the integer case - you need to shift one value to make the exponents match. Any additional cost for doing sign+magnitude addition is insignificant by comparison.

Also note that the separate sign bit is much better for multiplication - you just need a single unsigned multiplier which handles all cases with the sign bits being taken care of separately. Compare this with two's complement multiplication, where you either have to normalise the signs or have support for signed/unsigned multiplies.

半世晨晓 2024-09-05 13:40:51

如果您深入研究浮点数的标准表示形式,它实际上是一个类似整数的尾数和指数。我说类似整数,因为标准化时,第一位始终是“1” - 您知道两个数字的乘积将始终以 0 或 1 开头(在前一种情况下,您需要将结果左移并相应地调整指数,但会损失一位精度)。只要不溢出指数中可以容纳的位数,乘法和除法就可以正常运行。

另一方面,加法和减法需要将表示形式从标准化形式更改为指数匹配的形式。这就是为什么如果将两个大小相差很大的数字相加或将两个几乎相同的数字相减,就会得到看似奇怪的结果。这就是为什么中间结果通常比标准 4 字节和 8 字节浮点数和实数具有更多的精度。

你能在这里使用二进制补码表示法吗?也许......但你不能使用相同的规则来操纵表示。

我认为这取决于对研究过这个问题的一代又一代专家的信任。如果数百名博士和首席工程师认为当前的代表是最好的方法,那么我必须相信他们。

If you dig into the standard representation of floating point numbers it's actually an integer-like mantissa and an exponent. I say integer-like since, when normalized, the first bit is always a '1' - you know that the product of two numbers will always start with 0 or 1 (and in the former case you need to left-shift the results by one and adjust the exponent accordingly, at the loss of a single bit of precision). Multiplication and division are well-behaved as long as you don't overflow the number of bits you can hold in the exponent.

Addition and subtraction, on the other hand, require changing the representation from the normalized form to one where the exponents match. This is why you can get seemingly bizarre results if you add two numbers that are wildly different in magnitude or you subtract two numbers that are nearly identical. This is why the intermediate results usually have far more digits of precision than the standard 4- and 8-byte floats and reals.

Could you use twos-complement notation here? Maybe... but you couldn't use the same rules for manipulating the representation.

I think it comes down to trusting the generation(s) of experts who have looked at the problem. If hundreds of PhDs and principal engineers think the current representation is the best approach then I have to believe them.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文