uniform_int_distribution output changed from VS 17.4 to 17.5?

[totalgee]

I discovered some of my project's unit tests failed when I moved from VS 17.4 to 17.5, presumably due to a new version of the STL.

After debugging and looking at the code in this repo, I believe this is due to the change #3012, which substituted a faster algorithm (_Rng_from_urng_v2) for uniform_int_distribution. Is there a recommended way to get the old behaviour? We require repeatable (and cross-platform) random number generation for some things, and although our random generator (PCG) is still producing the same sequence of states after the Visual Studio version update, the remapping to our [lo, hi] integer range using uniform_int_distribution is no longer producing the same sequence of numbers.

You probably don't consider this a bug, since I expect the behaviour of this STL class is allowed to be implementation-defined (as long as it produces a statistically uniform distribution)... My workaround for now is basically to use rng() % (hi - lo + 1) + lo, which does at least produce the same integer sequence we had with VS 17.4 and earlier versions (albeit slower).

Thanks for any suggestions (or should I just avoid using uniform_int_distribution if I want cross-platform repeatability?).

[StephanTLavavej]

After debugging and looking at the code in this repo, I believe this is due to the change #3012, which substituted a faster algorithm (_Rng_from_urng_v2) for uniform_int_distribution.

Yep.

Is there a recommended way to get the old behaviour?

We didn't implement an escape hatch, so there's no way other than selecting an older toolset.

We require repeatable (and cross-platform) random number generation

While the Standard's engines (e.g. mt19937) are reproducible, with absolutely guaranteed outputs across all platforms and versions, its distributions aren't. In particular, uniform_int_distribution has never had identical results cross-platform - MSVC has always used its own implementation, with 3 versions over time, that behaves differently from GCC's libstdc++ and Clang's libc++. They also differ from each other; e.g. see https://godbolt.org/z/a8T9Yz1rb where libstdc++ emits 21 62 25 75 42 48 71 20 69 44 while libc++ emits 13 37 21 67 13 89 59 35 65 91.

If you require reproducible results, you will need to write your own distribution (or take an existing implementation under its license, such as ours, and use that for all platforms).

My workaround for now is basically to use rng() % (hi - lo + 1) + lo

Please note that using modulo results in bias, unless the input and output ranges are clean multiples. Consider mapping 2³² inputs, i.e. 4,294,967,296, to an output range of [0, 99] with modulo. Because the input range isn't a clean multiple of 100, naive modulo will result in some outputs being more likely. At a minimum, you need to reject and retry, as our previous implementation did, or use a fancier algorithm. Note that floating-point scaling is even more doomed; for more details see my talk rand() Considered Harmful.

[totalgee]

Pretty much what I suspected... Thanks for the helpful reply!

[ShelbyPLS]

Not sure if it's more helpful to comment here or to open a new issue. But the resulting change to uniform_int_distribution is giving a Run-Time Check exception in VS 17.5.1, for a debug x64 build on Windows 10, using C++17.

#include <iostream>
#include <random>
void TestRand()
{
std::random_device rd;
std::mt19937 gen(rd());
std::uniform_int_distribution<> distrib(0, 1);
int d = distrib(gen);
}

[StephanTLavavej]

ShelbyPLS The STL doesn't support /RTCc, and blocks it with a hard #error:

STL/stl/inc/yvals_core.h

Lines 1824 to 1829 in daa994b

	#ifdef _RTC_CONVERSION_CHECKS_ENABLED
	#ifndef _ALLOW_RTCc_IN_STL
	#error /RTCc rejects conformant code, so it is not supported by the C++ Standard Library. Either remove this \
	compiler option, or define _ALLOW_RTCc_IN_STL to suppress this error.
	#endif // _ALLOW_RTCc_IN_STL
	#endif // _RTC_CONVERSION_CHECKS_ENABLED

As the message indicates, we provide an escape hatch (e.g. if code uses only <type_traits> with no codegen involvement, or whatever) but we decline to alter conformant code that triggers /RTCc checks.

[ShelbyPLS]

Thanks Stephan T. Lavavej (@StephanTLavavej) for the speedy response! Sure enough, we've got _ALLOW_RTCc_IN_STL defined, which masked that helpful bit of info. Appreciate the explanation.

[sbsce]

Glen Fraser (@totalgee) I just encountered this same issue in my project, thanks for opening and describing this issue here! I wonder, how did you end up solving it eventually in your project? Did you stay with your rng() % (hi - lo + 1) + lo workaround, or did you find a better workaround to keep the old value output?

[totalgee]

sbsce It's nice to know I'm not alone. (-; Depending on your application, a small uniform_int_distribution bias may not be important. It's almost certainly not important in mine... but nonetheless I went for an unbiased rejection approach, similar to what I believe STL used to do; something simple like what's discussed here.

I would rather just use the std library function, but in our case cross-platform compatibility and having unit tests get consistent results across them was important.