Hi. >>> [...] > >> > >> One actual issue is that we are testing long providers using the long to > >> create 2 int values. Should we test using a series of the upper 32 bits > >> and then a series of the lower 32 bits? > > > > Is that useful since the test now sees the integers as they are produced > > (i.e. 2 > > values per long)? > > > > It is not relevant if you are concerned about int quality. But if you are > concerned about long quality then it is relevant. The long quality is > important for the quality of nextDouble(). Although in that case only the > upper 53 bits of the long. This means that the quality of a long from an int > provider is also not covered by the benchmark as that would require testing > alternating ints twice using the series: 1, 3, 5…, 2n+1 and 2, 4, 6, … 2n.
I don't follow: I'd think that if the full sequence passes the test, then "decimated" sequences will too. > > Given that half of the int values were previously discarded from the BigCrush > analysis, the current results on the user guide page actually represent > BigCrush running on the upper 32-bits of the long, byte reversed due to the > big/little endian interpretation of the bytes in Java and linux. > > So maybe the an update to the RandomStressTester to support analysis for int > or long quality is needed. I'm not convinced. > For now the quality section on the website should just state that the quality > is for the ‘nextInt()’ method of the RNG. > > I have the results of BigCrush using the new bridge c program: > > XorShiftSerialComposite : 40, 39, 39 : 608.2 +/- 3.9 Makes sense now. :-} > So it fails. > > The XorShiftXorComposite crashed after 2 hours about 1/4 of the results file > complete. I am running again so I can monitor it for memory usage. Something > in the BigCrush suite just cannot handle this generator output. Strange... Regards, Gilles >>> [...] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
