【问题标题】:c++ log function is using floating point precisionc ++ log函数使用浮点精度
【发布时间】:2011-08-26 01:43:42
【问题描述】:

当我给它一个非常接近 1.0 的数字时,我在以下函数中遇到了一个有趣的段错误。特别是当数字以 FLOATING POINT 精度四舍五入到 1.0 时。

double get_random_element(double random_number)
{
    if (random_number <= 0.0 || random_number >= 1.0)
        throw std::runtime_error("Can't have a random number not on the range (0.0, 1.0)");
    return -log(-log(random_number));
}

如果 random_number 为 1.0,则 log(1.0) = 0.0,并且 log 为零是导致 seg 错误的未定义计算。但是我会认为第一行的错误检查会阻止这种情况发生。 Ddebugging 显示非常接近 1 的数字将通过错误检查,但无论如何从 log 函数返回 0,这让我相信 log 函数仅使用单浮点精度。

我的包含如下,所以我只能假设我使用的是 math.h 中的日志

#include <string>
#include <math.h>
#include <sstream>
#include <map>
#include <boost/random/mersenne_twister.hpp>
#include <boost/random/uniform_int.hpp>
#include <boost/random/uniform_real.hpp>
#include <boost/random/variate_generator.hpp>
#include <utility>

更新:正如所指出的,一个简单的解决方案是仅使用浮点数作为参数,并且如果传入等于 1.0f 的数字以仅删除 std::numeric_limits::epsilon() 以给出一个数字可以安全地传递到双日志中。

但我想回答的问题是,为什么调用一个接近但不等于 1 的数字的双对数会失败。

更新 2:在测试项目中重新创建此问题后,我认为问题实际上出在输入中。如果我通过

double val = 1.0 - std::numerical_limits<double>::epsilon();

我对这个功能没有任何问题。但是我实际传入的是

boost::mt19937 random_generator;
double val = (random_generator()+1)/4294967297.0;

其中 random_generator 旨在返回 [0, 2^32 - 1] == [0,4294967295] 范围内的数字。所以我决定打入尽可能大的返回值

double val = (4294967295+1)/4294967297.0;

这很快给了我一个关于 unsigned int 溢出的警告,果然生成了一个零。我正在重新编译以下内容:

get_random_element((random_generator()+1.0)/4294967297.0);

希望这种奇怪的行为能够得到解决。

更新 3:我终于找到了这里发生的事情......和往常一样,它归结为用户错误(我自己就是错误)。有第二条控制路径通向此方法,它将双精度值临时存储为浮点数,然后将其转换回双精度,导致 0.999999999 舍入为 1.0,然后传递给 -log(-log(x)) 函数并导致它会倒下。我仍然不明白为什么我要检查

 if (random_number <= 0.0 || random_number >= 1.0) throw runtime_error(blah)

在将错误输入传递到日志函数之前没有捕获它?

【问题讨论】:

  • 不需要假设;使用::log 并预处理您的源代码以进行验证
  • 你确定是段错误吗?
  • @sehe 运行预处理器显示 math.h 日志函数导入 @david 不确定这是一个段错误还是只是一个不受支持的操作......但无论哪种方式它都会很好地杀死主机应用程序 :)
  • @Jamie:肯定是double1.0f 之间的比较有什么问题吗?
  • 你用的是什么编译器?最重要的是,您通过了哪些关于浮点运算的选项(/fp:... 与 Visual Studio)?您是否尝试使用 1.0 而不是 1.0f (它不应该改变任何东西)?你试过r + std::numeric_limits&lt;double&gt;::epsilon() &gt; 1 而不是r &gt;= 1 吗?

标签: c++ floating-point logging floating-accuracy


【解决方案1】:

我认为 quamrana 有一个很好的观点(它也立即引起了我的注意)。但是,我已经能够运行这个 sn-p 相当长的时间:

#include <math.h>
#include <boost/random/mersenne_twister.hpp>
#include <boost/random/uniform_real.hpp>

double get_random_element(double random_number)
{
    if (random_number <= 0 || random_number >= 1.0f)
        throw std::runtime_error("Can't have a random number not on the range (0.0, 1.0)");
    return -::log(-::log(random_number));
}

int main()
{
    boost::mt19937 rng; 
    boost::uniform_real<> random(std::numeric_limits<double>::epsilon(),1);
    for (;;)
    {
        double r = random(rng);
        double gre = get_random_element(r);
        std::cout << "r = " << r << ", gre = " << gre << std::endl;
    }
    return 0; // not reached
}

例如:

sehe@meerkat:/tmp$ ./t | grep '^r = 0.999999' 
r = 0.999999, gre = 14.4777
r = 0.999999, gre = 13.7012
r = 0.999999, gre = 14.0492
r = 0.999999, gre = 14.1161
[.... many many lines snipped ....]
r = 0.999999, gre = 14.3691
r = 0.999999, gre = 13.424
r = 0.999999, gre = 14.4822
r = 0.999999, gre = 14.286
r = 0.999999, gre = 14.4344
r = 0.999999, gre = 14.0572
r = 0.999999, gre = 14.0607
r = 0.999999, gre = 14.1126
r = 0.999999, gre = 13.575
r = 0.999999, gre = 13.4754
r = 0.999999, gre = 13.5486
r = 0.999999, gre = 14.1983
^C

real    18m14.005s
user    20m5.667s
sys 12m19.302s

也许你可以使用类似的东西?

【讨论】:

  • 这让我觉得问题可能出在编译器标志上。在 MSVC 中尝试 /fp:strict(或编译器的等效项),看看问题是否仍然存在。
  • sehe,我刚刚更新了这个问题......我们正在使用梅森捻线机,但我不完全确定 uniform_real 将什么作为参数......那些是包容性的还是排他性的边界?
  • 简单文档查找:uniform_real models a random distribution. On each invocation, it returns a random floating-point value uniformly distributed in the range [min..max)。我很惊讶你会自己编写输入分布,但偏执到需要检查这个事实:)
  • 偏执狂很有趣 :P 我在上面的代码中看到的问题是,如果运行时间足够长,它肯定会失败,因为你的 rng 应该在某个阶段生成一个 0,这会导致 log零和失败。但也许我们使用 boost::uniform_real random(std::numerical_limits::epsilon(),1); 更有意义
  • 我正在更新示例代码,以免混淆未来的访问者。 (我必须承认我完全错过了 0 也是不允许的事实:))
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2021-09-16
  • 2011-02-23
  • 2010-12-19
  • 2012-04-15
  • 2020-02-03
相关资源
最近更新 更多