如果我在 Gnome 设置中设置 175% 缩放,则该值将保存1.7518248558044434
为~/.config/monitors.xml
:
<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 是可以表达精确值的快乐数字之一。
侏儒韦兰 43.3
答案1
预设比例因子(100%、125% 等)调整为最接近的值,为您的分辨率提供水平和垂直方向上的预缩放虚拟像素的整数个值;根据您的值 1.7518248558044434 判断,这可能是 2192 x 1233 虚拟分辨率,并且您有一个 3840 x 2160 显示器。
至于为什么用该值计算的宽度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'
为什么将浮点数转换为更高精度会给出具有更多无用数字的十进制表示形式,这就是问题所暗示的浮点舍入错误的类型 - 浮点数的内部表示形式是二进制的,并且因此内部浮点后面的数字(“二进制小数点”,因为它是二进制的)代表 2 个分数的幂(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
如果你想知道为什么开发人员决定舍入比例因子以获得整数像素,我没有答案,但我的猜测是向后兼容性:开发人员习惯于人们的显示器具有整数像素,因此这就是现有软件的设计目的。
答案2
另一种理论:1.7518248558044434的近似有理数不是2192/1233,而是更简单的240/137 = 1.7518248175182481...(要获得更接近的有理数,您需要将分子和分母大1390倍。并且是的,1/137 的倍数的十进制表示有一个 8 位周期。)因此,以像素为单位的高度和宽度有多种可能性可以给出这个比率,包括 2160 x 1233。
但是,你说,240/137 很接近,但又不是那么接近。另一个很好的近似值是 3673843/2097152。为了获得更接近的有理数,您需要将分子和分母大数千倍。 1/2097152 是 2^{-21}。因此,这表明 240/137 存储在二进制浮点数中,有足够的空间容纳 22 个尾数位:二进制小数点左边 1 位,右边 21 位。 (这些位计数忽略了可能存在的任何尾随 0。)然后转换为十进制,其精度远高于二进制表示形式的精度。