Leu*_*nko 5 c floating-point bit-manipulation
如果有效数的最低有效位被设置为随机值,那么对浮点数学的影响可能是多少？
说明:
语言PicoLisp使用一个结构分配所有值,该结构由两个"机器字"组成.在32位系统上,这意味着单元是两个32位指针或整数的八字节结构.单元格与其大小对齐,这意味着至少字的最低三位可以自由地用作类型和GC标签数据.
PicoLisp极简主义.语言缺乏的(许多)事物之一是对浮点数的任何支持,而是完全依赖于文档称为"缩放的固定点"表示.我认为尝试添加浮点支持会很有趣.
在32位系统上,64位浮点数可以整齐地放在一个单元格内,这很方便地意味着分配系统可以完全相同,除了一个小问题:双重使用所有64位.但是GC期望使用位0作为GC标记位.天真地进行,在每个收集周期之后,位0将被设置为零,而不管双倍中实际存储了什么值.
(这是假设的大小和正确ENDIANNESS所有行承担的这一点,他们做的目的;如果他们不这样做,那么整个问题是完全不相关和不同的策略不一定必须使用.)
那么:对于通用数学,使用硬件浮点运算有多少问题？
如果它是所有减轻双微小剂量的精度,然后我的身影,实际上并不是一个问题:只要是记录在案的是,在解释浮点数学是不是精确的用户所期望的,他们应该如果他们需要严格准确的行为,可以回到修复点或库或其他东西.我对它的直观理解是应该是这种情况,因为它是最不重要的一点(当你转换为字符串时甚至不显示......？).
另一方面,浮点是,呃,巫术.这种小小的琐事是否会严重影响数学的有用性或产生任何一致结果的能力？
(我已经考虑过分配器的其他几种实现可能性.我特别感兴趣的是这种策略是否具有愚蠢性,因为它是最简单的,而且我很懒.)
只要外部代码总是看到该值，就好像低位已被四舍五入，并且您可以通过将尾数四舍五入到最接近的偶数来完成此操作，对于正常计算来说就可以了。
也就是说，对于以以下形式结尾的尾数：
00： 没做什么
10： 没做什么
01：尾数减1
11：尾数加1（溢出时，需要增加指数并清除尾数）
如果您的舍入不一致并且只是去掉低位，则会在计算中引入非常轻微的向下偏差。向偶数舍入是 IEEE 抵消这种向下偏差的方法。
请小心 +/- 无穷大，因为设置低位会将其转变为 NAN，而 NAN 的使用非常脆弱（突然间，所有比较操作都开始失败）。