即使就值的原始字节表示而言,我也得到了相同的输出d2
和。e2
这是一些带注释的输出:
# Calculation results
d2: 38 E2 53 2E
e2: 38 E2 53 2E
1.079201E-04 = 1.079201E-04
# Result of changing the last byte (some mantissa bits) to alter the value,
# proving they're not equal
d2: 38 E2 53 2F
e2: 38 E2 53 2E
1.079201E-04 <> 1.079201E-04
# Result above may just be luck. This result alters the first byte
# (some exponent bits) to prove that the intended bits were altered.
d2: 39 E2 53 2E
e2: 38 E2 53 2E
4.316805E-04 <> 1.079201E-04
代码:
DIM a AS SINGLE
DIM SHARED d2 AS SINGLE
DIM SHARED e2 AS SINGLE
a = 32.174
d2 = 1! / (2! * 32.174 * 144!)
e2 = 1! / (2! * a! * 144!)
' Print the hex representation of the bytes
' and show they're initially equal.
CALL printHex
PRINT
' Change the last byte of the mantissa by 1 bit.
' Show that doing this makes the two values unequal.
DEF SEG = VARSEG(d2)
POKE VARPTR(d2), PEEK(VARPTR(d2)) + 1
DEF SEG
CALL printHex
PRINT
' Show that the correct byte was poked by reverting mantissa change and
' altering exponent.
DEF SEG = VARSEG(d2)
POKE VARPTR(d2), PEEK(VARPTR(d2)) - 1
POKE VARPTR(d2) + 3, PEEK(VARPTR(d2) + 3) + 1
DEF SEG
CALL printHex
SUB printHex
'SHARED variables used:
' d2, e2
DIM d2h AS STRING * 8, e2h AS STRING * 8
' Get bytes of d2 and e2, storing them as hexadecimal values
' in d2h and e2h.
DEF SEG = VARSEG(d2)
MID$(d2h, 1) = hexByte$(PEEK(VARPTR(d2) + 3))
MID$(d2h, 3) = hexByte$(PEEK(VARPTR(d2) + 2))
MID$(d2h, 5) = hexByte$(PEEK(VARPTR(d2) + 1))
MID$(d2h, 7) = hexByte$(PEEK(VARPTR(d2)))
DEF SEG = VARSEG(e2)
MID$(e2h, 1) = hexByte$(PEEK(VARPTR(e2) + 3))
MID$(e2h, 3) = hexByte$(PEEK(VARPTR(e2) + 2))
MID$(e2h, 5) = hexByte$(PEEK(VARPTR(e2) + 1))
MID$(e2h, 7) = hexByte$(PEEK(VARPTR(e2)))
DEF SEG
' Print the bytes, separating them using spaces.
PRINT "d2: "; MID$(d2h, 1, 2); " "; MID$(d2h, 3, 2); " ";
PRINT MID$(d2h, 5, 2); " "; MID$(d2h, 7, 2)
PRINT "e2: "; MID$(e2h, 1, 2); " "; MID$(e2h, 3, 2); " ";
PRINT MID$(e2h, 5, 2); " "; MID$(e2h, 7, 2)
' Print whether d2 is equal to e2.
IF d2 = e2 THEN
PRINT d2; "= "; e2
ELSE
PRINT d2; "<>"; e2
END IF
END SUB
FUNCTION hexByte$ (b%)
' Error 5 is "Illegal function call".
' This can only happen if b% is outside the range 0..255.
IF b% < 0 OR b% > 255 THEN ERROR 5
' MID$("0" + HEX$(15), 2 + (-1)) => MID$("0F", 1) => "0F"
' MID$("0" + HEX$(16), 2 + ( 0)) => MID$("010", 2) => "10"
hexByte$ = MID$("0" + HEX$(b%), 2 + (b% < 16))
END FUNCTION
编辑
正如@BlackJack 在评论中解释的那样,您注意到的效果似乎出现在编译文件时。因为这是给出的线索,所以我在 DOSBox 中使用了 CodeView 调试器,下面是删减的结果:
5: a = 32.174
057D:0030 C70636002DB2 MOV Word Ptr [0036],B22D
057D:0036 C70638000042 MOV Word Ptr [0038],4200
6: d2 = 1! / (2! * 32.174 * 144!)
057D:003C C7063A002D53 MOV Word Ptr [003A],532D
057D:0042 C7063C00E238 MOV Word Ptr [003C],38E2
7: e2 = 1! / (2! * a! * 144!)
057D:0048 CD35065000 FLD DWord Ptr [0050]; 00 CB 21 CD
057D:004D CD34363600 FDIV DWord Ptr [0036]; 42 00 B2 2D
057D:0052 CD351E3E00 FSTP DWord Ptr [003E]; e2 = result
057D:0057 CD3D FWAIT
BASIC 编译器 (BC.EXE) 将赋值d2
简化为浮点常量的简单赋值(即,它评估表达式本身并将您的代码优化为单个赋值,而不是执行您指定的所有操作)。然而,赋值e2
并不是那么简单,因为它包含一个非常量表达式a!
。
为了解决这个问题并尝试保持尽可能高的精度,它更改1 / (2 * a * 144)
为数学上等效的(1 / 288) / a
,并且 的近似值1 / 288
存储在 offset0x0050
中,这就是FLD
最终加载该偏移量的原因。加载该SINGLE
值后,它将它除以a
(offset 0x0036
) 的值并将结果存储在e2
(offset 0x003E
) 中。您可以使用 进行赋值e2
,d2
但CONST a = 32.174
不能更改其值。
现在有人可能想知道为什么这只发生在编译时而不是在 IDE 中,老实说我不知道。我最好的猜测是 IDE 在 FP 堆栈上保留尽可能多的浮点数以保持精度,因此它不使用 的 32 位舍入值a
,而是使用已经存储在 FP 堆栈上的现有 80 位值,如果它仍然存储在那里。这样,精度损失就会减少,因为将 80 位值存储在 FP 堆栈之外需要四舍五入到最接近的 32 位或 64 位值,具体取决于您指定存储值的位置。当然,如果出于某种原因在 FP 堆栈上需要超过 8 个值,则需要将其中一个换出为另一个腾出空间,最终会出现精度损失。
@BlackJack 还指出 IDE 正在解释代码而不是通过优化对其进行编译,这可能是代码在 IDE 中运行时字节表示相同但在编译版本中不同的原因。也就是说, 和 的计算d2
都e2
以完全相同的方式执行,而不是d2
像 BC.EXE 那样将计算优化为单个值。
无论如何,您可能不会在您的 C 代码中注意到它,因为您的现代编译器比 BC.EXE 更智能,并且在优化方面有更多内存可供使用,即使没有现代浮点技术的帮助像 SSE2。