PowerShell中数学常数π与E为何截断精度不同？

在PowerShell中执行命令行数学运算时发现如下现象：

# "{0:f64}" -f ([Math]::PI); "{0:f48}" -f ([Math]::PI)
3.1415926535897931159979634685441851615905761718750000000000000000
3.141592653589793115997963468544185161590576171875

# "{0:f64}" -f ([Math]::E); "{0:f51}" -f ([Math]::E)
2.7182818284590450907955982984276488423347473144531250000000000000
2.718281828459045090795598298427648842334747314453125

为何数学常数π和E被截断为不同的小数长度（48位vs51位）？且为何未对齐16、32、64等字节/字的偶数位数？

• 核心原因是双精度浮点数的二进制存储特性
  .NET中的[Math]::PI和[Math]::E都是64位双精度浮点数，这类数值的小数部分是二进制分数的近似值，转换成十进制时，有效数字最多约17位。当用fN格式强制输出更多小数位时，超出有效数字的部分是二进制转十进制时的尾缀，直到出现连续的0才会停止截断：

  • π的双精度二进制表示转十进制后，小数部分到第48位就全为0，所以f48和f64的有效内容一致，后面仅补0；
  • e的双精度二进制表示转十进制后，小数部分到第51位才全为0，因此f51就能输出完整尾缀，更多位数同样只是补0。

• 关于未对齐字节/字位数的问题
  双精度浮点数的十进制尾缀长度和其二进制存储的52位尾数相关，但二进制转十进制的过程没有强制对齐16、32、64这类字节位数的规则——尾缀长度完全由二进制分数转十进制后的具体数值决定，和字节/字的偶数位数没有关联，只取决于十进制小数位何时开始全为0。

内容的提问来源于stack exchange，提问作者not2qubit