The current implementation of random_default_impl for integers is as follow: enum { rand_bits = floor_log2<(unsigned int)(RAND_MAX)+1>::value, scalar_bits = sizeof(Scalar) * CHAR_BIT, shift = EIGEN_PLAIN_ENUM_MAX(0, int(rand_bits) - int(scalar_bits)) }; Scalar x = Scalar(std::rand() >> shift); Scalar offset = NumTraits<Scalar>::IsSigned ? Scalar(1 << (rand_bits-1)) : Scalar(0); return x - offset; and that does not sounds correct to me. For instance, let's assume rand_bits==32, and scalar_bits==8 (Scalar==char). Then offset is equal to 2^31 while it should be 2^7. Another problem is that std::rand() >> shift might not fit within a Scalar if Scalar is signed. So, is it ok to assume that the bits returned by std::rand() have all the probability? and also that the bits of a random integer have the same probability? If so, then we could simply reinterpret_cast "std::rand()&(1>>scalar_bits-1)"? or, we can also fix the current implementation like this: if(IsSigned) return Scalar( (std::rand() >> shift) - (1 << (scalar_bits-1)) ); else return Scalar(std::rand() >> shift);
My rand() man page says that on some older/other systems the lower order bits are less random than the higher order bits. This is why in C r = ((long long) rand() * n)/RAND_MAX; // is preferable to: r = rand() % n; Subtracting (1<<(scalar_bits-1)) will give very strange behavior if (scalar_bits>random_bits) and for (scalar_bits<random_bits) subtracting the offset does not really make a difference, I guess. (Sure technically, signed integer overflow leads to undefined behavior, but I doubt that this happens on any platform we support.) That said, I'm not really a fan of rand() anyways, as I generally prefer reproducible random numbers (e.g. by <boost/random/> or C++11 <random>)
I still prefer to make sure no overflow will occur, so: https://bitbucket.org/eigen/eigen/commits/942b7eedb4e8/ Changeset: 942b7eedb4e8 User: ggael Date: 2013-07-10 21:11:41 Summary: Revisit the implementation of random_default_impl for integer to avoid overflows and compiler warnings.
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/628.