Windows .NET更新后对最后一位数字的舍入取整 [英] Rounding of last digit changes after Windows .NET update

查看:78
本文介绍了Windows .NET更新后对最后一位数字的舍入取整的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

Windows更新后,某些计算值的最后一位已更改,例如从-0.0776529085243926到-0.0776529085243925.更改总是下降一个,并且偶数和奇数都会受到影响.这似乎与KB4486153有关,因为还原此更新会将值更改回以前的值.

After Windows has updated, some calculated values have changed in the last digit, e.g. from -0.0776529085243926 to -0.0776529085243925. The change is always down by one and both even and odd numbers are affected. This seems to be related to KB4486153, as reverting this update changes the values back to the previous ones.

在Visual Studio中进行调试并将鼠标悬停在变量上时,已经可以看到此更改.将该值稍后写入输出文件,并在其中进行更改(无需运行调试器).

This change can be seen already when debugging in Visual Studio and hovering over the variable. The value is later written to an output file and changes therein as well (without running the debugger).

最小的可复制示例

var output = -0.07765290852439255;
Trace.WriteLine(output); // This printout changes with the update.

var dictionary = new Dictionary<int, double>();
dictionary[0] = output; // Hover over dictionary to see the change in debug mode

背景

计算值来自

output[date] = input[date] / input[previousDate] - 1;

不管浮点运算的精度损失如何,我都可以在立即窗口中进行计算,并在升级前后获得 -0.07765290852439255 .

Disregarding the loss of precision in floating-point arithmetic, I can do the calculation in the Immediate window and get -0.07765290852439255 both before and after the upgrade.

但是,当悬停在 output 变量上时,我看到了
{[2011-01-12 00:00:00,-0.0776529085243926]} 之前,
{[2011-01-12 00:00:00,-0.0776529085243925]} 之后,此差异也将传播到输出文件.

However, when hovering over the output variable , I see
{[2011-01-12 00:00:00, -0.0776529085243926]} before the upgrade and
{[2011-01-12 00:00:00, -0.0776529085243925]} after, and this difference is also propagated to an output file.

更新前后的计算值似乎相同,但是其表示方式四舍五入.

It seems like the calculated value is the same before and after the update, but its representation is rounded differently.

输入值为

{[2011-01-11 00:00:00, 0.983561000400506]} 
{[2011-01-12 00:00:00, 0.907184628008246]}

目标框架设置为 .NET Framework 4.6.1

问题

是否可以做一些事情来保持以前的行为,同时又保持更新?

Is there something I can do to get the previous behaviour while keeping the updates?

我知道浮点计算的精度损失,但是为什么在更新后会发生这种变化,又如何保证将来的更新不会改变值的表示呢?

I know about loss of precision in floating-point calculations, but why does this change happen after an update and how can we guarantee that future updates don't change the representation of values?

KB4486153是Microsoft .NET Framework 4.8的更新,请参见

KB4486153 is an update for Microsoft .NET Framework 4.8, see https://support.microsoft.com/en-us/help/4486153/microsoft-net-framework-4-8-on-windows-10-version-1709-windows-10-vers

推荐答案

OP遇到浮点数学的常见问题之一.使用新软件时,是想要一致的答案还是最佳的答案?(升级效果更好)

OP is encountering one of the common problems with floating-point math. With new software, does one want consistent answers or the best answer? (The upgrade is better)

一些有助于解决此问题的信息.

Some info to help advance the issue.

var output = -0.07765290852439255;

使用常见的 binary64 编码 1 ,由于binary64的二进制性质,因此 output 具有

With common binary64 encoding1, due to the binary nature of binary64, output takes on the exact value of

-0.077652908524392 54987160666132695041596889495849609375

下面还以十六进制和十进制FP形式显示了上一个和下一个可能的 double .

The below shows the prior and next possible double too as hexadecimal and decimal FP.

                      -0.077652908524392 5
-0x1.3e10f9e8d3217p-4 -0.077652908524392 53599381885351249366067349910736083984375
-0x1.3e10f9e8d3218p-4 -0.077652908524392 54987160666132695041596889495849609375
                      -0.077652908524392 55
-0x1.3e10f9e8d3219p-4 -0.077652908524392 56374939446914140717126429080963134765625
                      -0.077652908524392 6

-0.077652908524392 55 (精确编码为 -0.077652908524392 5498 ... )的最佳四舍五入值小于一位> -0.077652908524392 5 .升级后,代码会打印出更好的答案-至少在这种情况下如此.

The best rounded-to-nearest value of -0.077652908524392 55 (which is encoded exactly as -0.077652908524392 5498...) to one less digit is then -0.077652908524392 5. After the upgrade, code is printing the better answer - at least in this singular case.

我不认为这是四舍五入的变化,没有改进为文本的转换.

I do not see this as a rounding change as much as an improved conversion to text.

是否可以做一些事情来保持以前的行为,同时又保持更新?

Is there something I can do to get the previous behaviour while keeping the updates?

也许,但是看起来更新显示出了更好的结果.

Perhaps, yet it looks like the update presents a better result.

我们如何保证将来的更新不会改变值的表示形式

how can we guarantee that future updates don't change the representation of values

使用十六进制浮点输出(如C中的%a" 一样)是获取不更改表示形式的一种方法,但非十进制输出是

Use hexadecimal floating point output (as with "%a" in C) is one approach to gain don't change the representation, yet non-decimal output is unfamiliar.

1 使用其他编码,确切值可能比 -0.077652908524392 5 更接近 -0.077652908524392 6 .

1 With other encodings, the exact value may have been closer to -0.077652908524392 6 than -0.077652908524392 5.

这篇关于Windows .NET更新后对最后一位数字的舍入取整的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆