为什么Gnome分数标度为1.7518248558044434而不是1.75？

Question

如果我在Gnome中设置175%缩放，则该值在~/.config/monitors.xml中保存为1.7518248558044434：

<monitors version="2">
  <configuration>
    <logicalmonitor>
      <x>0</x>
      <y>0</y>
      <scale>1.7518248558044434</scale>
      <primary>yes</primary>
      <monitor>
        <monitor spec>
          <connector>DP-3</connector>

为什么会这样呢？起初，我认为这可能是由于浮点舍入误差，但1.75是那些幸福的数字之一，它的确切值可以表示。

Gnome Wayland 43.3

Answer 1

预置标度因子(100%，125%等)调整到最接近的值，为您的分辨率提供大量的水平和垂直缩放前虚拟像素；从您的值1.7518248558044434判断，这可能是2192x1233，并且您有一个3840x2160显示器。

另外，为什么用这个值计算的宽度3840/1.7518248558044434 = 2191.9999520937613只精确到小数点之后的四位，很明显，标度已经从单精度浮点(IEEE-754 32位)转换而来。3840/2192的双精度近似更像1.7518248175182483，但是如果将该值转换为单精度并返回到双精度，则可以精确地得到1.7518248558044434。我是用Python做的，正如答案https://stackoverflow.com/a/43405711/60422所建议的那样：

>>> struct.unpack('f', struct.pack('f', 1.7518248175182483))[0]
1.7518248558044434

Stéphane Chazelas建议Perl中相应的一行：

perl -e 'printf "%.17g\n", unpack "f", pack "f", 1.7518248175182483'

为什么把浮点数转换成更高的精度给了小数点表示法更多没有用处的数字，这是问题所指的浮点舍入误差--浮点数的内部表示是二进制的，所以浮点后面的数字(“二进制点”，因为它是二进制的)代表两个分数的幂(1/2，1/4，1/8，等等)。一个数字，你可以用有限的小数位表示，不一定有有限的二进制表示。有关此问题的更多信息，请参见：https://stackoverflow.com/a/588014/60422

单精度通常被认为是好的大约7小数点的重要数字，这就是我们在这里看到的。

为了了解这个数字产生的比例因子的调整是如何工作的，get_closest_scale_factor_for_resolution函数在mutter中从缩放因子中计算虚拟宽度和高度，如果这些不是整数，则从计算出的宽度四舍五入开始，从计算出的宽度四舍五入开始，一次从它向外扩展一个像素，直到它找到一个经过调整的缩放因子，使虚拟高度成为一个整数，或者直到它放弃，因为标度超出了搜索范围或超出了搜索阈值。https://gitlab.gnome.org/GNOME/mutter/-/blob/176418d0e7ac6a0418eea46669f33c8e3b03c4bd/src/backends/meta-monitor.c#L1960

如果您想知道为什么开发人员决定这样做，我没有答案，但我的猜测是向后兼容性:开发人员习惯于拥有大量像素的人的监视器，所以这就是现有的软件设计的目的。

Answer 2

另一种理论: 1.7518248558044434近似的理性不是2192/1233，而是更简单的240/137 =1.7518248175182481。(为了得到一个更接近的理性，你需要分子和分母比它大1390倍。)是的，1/137倍数的十进制表示有一个8位的循环。)因此，有几种可能性，以像素为单位的高度和宽度，将提供这一比率，包括2160x1233。

但是，你说，240/137接近，但没有那么接近。另一个很好的近似是3673843/2097152。为了得到一个更接近的理性，你需要分子和分母比它大几千倍。1/2097152是2^{-21}。因此，这表明240/137存储在一个二进制浮点中，有足够的空间容纳22个尾数位:左边一个位，右边21个位。(这些位数忽略了任何落后的0。)然后转换成十进制，比二进制表示的精度要精确得多。