浮点并且在加法和减法之后小于等于 [英] Floating point and less than equal after addition and substraction

问题描述

在一系列浮点算术运算之后，是否有一个最佳实践小于与浮点数相等的比较？

R中有下面的例子，但是这个问题不仅适用于R，而且也适用于任何使用浮点的语言。我有一个double x = 1 ，我应用了一系列的加法和减法。最后 x 应该只是一个，但不是由于浮点运算（从我收集的）。这里是例子

 > stop_times <-seq（0.25,2，by = .25）
> expr<  - 表达式（复制（100，{
 + x< -1 b $ b + 
 + for（i in 1:10））{
 + tmp<  -  rexp （1,1）
 + n < -  sample.int（1e2,1）
 + delta <-tmp / n 
 + for（j in 1：n）
 + x < -  x  -  delta 
 + x < -  x + tmp 
 +} 
 + 
 +＃correct的答案是4 
 + .max（x <= stop_times）
 +}））
> eval（expr）
 [1] 5 5 5 4 4 4 5 5 5 4 5 4 4 4 5 5 4 4 5 4 5 4 5 4 5 5 5 4 4 4 4 4 4 4 4 4 5 5 5 5 5 4 5 4 5 5 5 4 4 5 5 5 4 4 5 5 5 4 4 4 4 4 4 
 [64] 5 4 4 4 5 5 5 4 4 4 5 4 4 4 4 4 4 4 4 5 5 5 5 4 4 4 5 5 5 5 5 4 4 4 5 5 4 
  

A ？）的解决办法是在右边的不等式中增加一些任意的小正数如下：

pre $ some_arbitrary_factor< - 100
stop_times <-seq（0.25,2，by = .25）+
some_arbitrary_factor * .Machine $ double.eps
eval（expr）
[1] 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
[64] 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4


这是最佳做法吗？如果有的话，选择 some_arbitrary_factor ？

我的具体问题是我有时间周期$（t_0，t_1），（t_1，t_2），\点$，并且需要查找在给定的观察$ x $所在的时段。$ x $可能已经被设置为一个边界$ t_i $经历了一系列的浮点运算操作，如果执行了精确的操作，应该导致$ t_i $

没有最佳实践。不幸的是，这是不可能的，因为几乎所有的浮点计算都会引入一些舍入误差，并且对于不同的应用程序，错误的后果是不同的。通常，软件将执行有些计算理论上会产生一些精确的数学结果，但由于舍入误差（或其他问题），会产生近似值 x 。当比较浮点数时，你想问一些关于 x 的问题，比如Is x < 1？或Is x = 3.1415926 ...？所以你想解决的问题是我如何使用 x '来回答这个关于 x ？

没有通用的解决方案。即使 x 小于1，某些错误可能会产生大于1的 x 。有些错误可能会产生 x ，即小于1即使x大于1.任何特定实例中的解决方案都取决于计算 x 时产生的错误信息以及要回答的具体问题。 b
$ b

有时候一个彻底的分析可以证明某些关于 x 的问题可以用 x 来回答。例如，在一些情况下，我们可以进行计算，以便我们知道，如果 x '< 1，那么 x 或者，如果 x '< .99875，然后 x 1.假设我们分析了我们用来计算的计算结果 x ，并且可以显示最终的误差小于.00125。然后，如果 x '< .99875，那么我们知道 x < 1，而如果 x '> 1.00125，则 x 1。但是，如果.99875 < x '< 1.00125，那么我们不知道是否 x 1或 x 我们在这种情况下做什么？对于你的应用程序来说，更好的方法是采取 x 的路径。 1或者 x 1的路径答案是特定于每个应用程序，并没有一般的最佳做法。

我会补充说，发生的舍入错误的数量在应用程序之间差别很大。这是因为舍入误差可以以各种方式复合。有些浮点运算的应用程序将会以小错误达到结果。一些具有许多浮点运算的应用程序也将获得适中的错误结果。但某些行为可能导致计算错位并产生灾难性的错误。所以处理舍入错误是每个程序的自定义问题。

Is there a "best practice" less than equal comparisons with floating point number after a series of floating-point arithmetic operations?

I have the following example in R though the question does not only apply to R but any language using floating points. I have a double x = 1 which I apply a series of addition of and subtractions to. In the end x should be exactly one but is not due to floating-point arithmetic (from what I gather). Here is the example

> stop_times <- seq(0.25, 2, by = .25)
> expr <- expression(replicate(100,{
+   x <- 1
+   
+   for(i in 1:10){
+     tmp <- rexp(1, 1)
+     n <- sample.int(1e2, 1)
+     delta <- tmp / n
+     for(j in 1:n)
+       x <- x - delta
+     x <- x + tmp
+   }
+ 
+   # "correct" answer is 4  
+   which.max(x <= stop_times)
+ }))
> eval(expr)
  [1] 5 5 5 4 4 4 5 5 5 4 5 4 4 4 5 5 4 4 5 4 5 4 5 4 5 5 5 4 4 4 4 4 4 4 4 4 5 5 5 5 5 4 5 4 5 5 5 4 4 5 5 5 4 4 5 5 5 4 4 4 4 4 4
 [64] 5 4 4 4 5 5 5 4 4 4 5 4 4 4 4 4 4 4 4 5 5 5 5 4 4 4 5 5 5 5 5 4 4 4 5 5 4

A (naive?) solution is to add some arbitrary small positive number to the right hand side of the inequality as follows

some_arbitrary_factor <- 100
stop_times <- seq(0.25, 2, by = .25) + 
  some_arbitrary_factor * .Machine$double.eps
eval(expr)
  [1] 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
 [64] 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4

Is this "best practice" and if so are there guidelines on how to chose some_arbitrary_factor?

My concrete problem is that I have time periods $(t_0, t_1], (t_1, t_2], \dots$ and need to finde out in which period a given observation $x$ is in. $x$ may have been set to one the boundaries $t_i$ after having undergone a series of floating-point arithmetic operations which should result in $t_i$ if exact operation where performed.

解决方案

No, there is no best practice. Unfortunately, there cannot be, because almost all floating-point calculations introduce some rounding error, and the consequences of the errors are different for different applications.

Typically, software will perform some calculations that ideally would yield some exact mathematical result x but, due to rounding errors (or other issues), produce an approximation x'. When comparing floating-point numbers, you want to ask some question about x, such as "Is x < 1?" or "Is x = 3.1415926…?" So the problem you want to solve is "How do I use x' to answer this question about x?"

There is no general solution for this. Some errors may produce an x' that is greater than 1 even though x is less than 1. Some errors may produce an x' that is less than 1 even though x is greater than 1. The solution in any specific instance depends on information about the errors that were generated while calculating x' and the specific question to be answered.

Sometimes a thorough analysis can demonstrate that certain questions about x can be answered using x'. For example, in some situations, we might craft calculations so that we know that, if x' < 1, then x < 1. Or perhaps that, if x' < .99875, then x < 1. Say we analyze the calculations we used to calculate x' and can show that the final error is less than .00125. Then, if x' < .99875, then we know x < 1, and, if x' > 1.00125, then x > 1. But, if .99875 < x' < 1.00125, then we do not know whether x > 1 or x < 1. What do we do in that situation? Is it then better for your application to take the path where x < 1 or the path where x > 1? The answer is specific to each application, and there is no general best practice.

I will add to this that the amount of rounding error that occurs varies hugely from application to application. This is because rounding error can be compounded in various ways. Some applications with a few floating-point operations will achieve results with small errors. Some applications with many floating-point operations will also achieve results with modest errors. But certain behaviors can lead calculations astray and produce catastrophic errors. So dealing with rounding error is a custom problem for each program.

这篇关于浮点并且在加法和减法之后小于等于的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！