https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66302
--- Comment #5 from Andrey Kolesov <andrey.kolesov at intel dot com> --- Ok, we understand your points. Obviously there are two approaches: 1) provide maximum random bits in all precisions but not preserve sequences 2) provide reasonable number of random bits but preserve sequences for all precisions. Both approaches have their own customers. First one is applicable to fine accuracy testing suits, for example. Second one is more for Monte-Carlo simulations, finance and general data analytic, etc. Our team chosen the second approach during MKL VSL design since we have a lot of requests and strict requirements from important customers (mostly FSI) to generate the same sequence for all CPU's and precisions. Moreover a number of them just did refuse solutions when random values sequence potentially could be different at different systems and for different precision environments. That's really important feature. What about accuracy: our experience based on customers communication says that ~32 random mantissa bits is quite enough for most of statistical applications. This case the difference between rounded and exact random value is about 10^(-8). During Monte-Carlo simulations these generated random values are being transformed by various math operations and most of them have 1/sqrt(N) statistical error for parameter to be evaluated, where N - number of generated random values. When N = 10^10 the simulation accuracy is about 10^(-5) - this case we did not even see the ~10^(-8) generator error. It means that extra accuracy of double precision generator is almost useless for such kind of applications. At the same time we understand that sometimes customers need full accuracy of high precision generators. This case MKL provides "uniform bits" generator versions with "raw" output type for own customer scaling. Ideally it would be nice to have distributions parametrization by accuracy to satisfy different customer needs, but that would require standard update. What about this issue - we agree to close it. Thanks to all.
