本征：log（）的计算限制是什么？ （Windows和Linux）

Question

I have a strange problem with my Eigen code. It works well on Linux (64 bit) and Mac OSX (64 bit), but it fails on Windows (32 bit) with an 1.#INF value.

I traced down the problem to this function, where I implemented the Box-Muller-transform:

Eigen::MatrixXd box_muller ( const Eigen::VectorXd vRand )
{
    unsigned long n = vRand.rows();
    unsigned long m = n/2;

    Eigen::ArrayXd rand1 = vRand.head ( m );
    Eigen::ArrayXd rand2 = vRand.tail ( m );

    /* Implemented according to
     * http://en.wikipedia.org/wiki/Box%E2%80%93Muller_transform
     */

    for ( unsigned long i=0; i<rand1.cols(); i++ )
    {
        if ( rand1 ( i ) < 1e-8 )
        {
            rand1 ( i ) = 1e-8;
        }
    }

    rand1 = (-2 * rand1.log()).sqrt(); // something must be wrong here

    std::cout << rand1.mean() << std::endl; // prints 1.#INF

    rand2 = rand2*2*M_PI;

    Eigen::MatrixXd result ( 2*m, 1 );
    Eigen::MatrixXd res1 = ( rand1 *rand2.cos() ).matrix();
    Eigen::MatrixXd res2 = ( rand1 *rand2.sin() ).matrix();
    result << res1, res2;

    return result;
}

This piece of code fails, but only on Windows and only for large input vectors vRand. It fails because in rand1 there are unexpected values that generate 1.#INF , -1.#INF , 1.#IND or 1.#QNAN values in subsequent computations. When I set the number of elements in vRand to a small number, say, 10000 , it works fine. But when the number is large (eg 100000 ) it fails.

I tried everything I could think of and now I am out of ideas. What can I try to eliminate this problem?

More info:

• We're building this with MS Visual Studio 12.0. It runs on a buildserver, therefore I cannot find out the exact version easily.
• We are using C++0x, as far as I know.

Answer 1

I suggest replacing this loop:

for ( unsigned long i=0; i<rand1.cols(); i++ )
{
    if ( rand1 ( i ) < 1e-8 )
    {
        rand1 ( i ) = 1e-8;
    }
}

with:

rand1 = rand1.max(1e-8); // limit min value to 1e-8
rand1 = rand1.min(1.0);  // limit max value to 1.0

This would then guarantee that the values of rand1.log() will be <= 0 and the subsequent sqrt() should not then fail. If this fixes the problem then you might want to work backwards to identify where the out-of-range input values are coming from.