need particular prng

[deltarho[1859]]

OK I got to 2TB and stopped there.

However, PractRand has its limitations: It cannot describe the quality of the wheat.

Wrong! dodicat got to 4TB with only one small anomaly. RomuTrio had three small anomalies and one mildly suspicious in 2TB. This may simply down to dodicat having a little extra 'mix' by using three rotls as opposed to RomuTrio only using two. Vigna's xoroshiro128** uses three as well. It is a bit like encryption and hashing - reduce the rounds to give more speed, and cryptanalysts may find themselves breaking algorithms.

Forget my comment about RomuTrio being faster than dodicat. In future I must use a checklist to make sure that I am using the same metrics for each test. I use WinFBE and Cswitches. I do other things besides test generators and may forget to correct the switches used. Get that wrong and the figures will be wrong and therefore the conclusions. dodicat has an edge on RomuTrio.

My conclusions above, '32-bit mode (32-bit granularity)', and so on have not changed.

RomuTrio is good but it is not pushing anyone to one side, in my opinion. dodicat is a little faster with my plotting program.

SFC32 does not have a fixed period either, but it should not be an issue with 128 bits of state. RomuTrio has 192 bits of state.

I am going to make a slight revision: With regard '64-bit mode (53-bit granularity)' toss a coin between dodicat and RomuTrio.

I don't like 15241094284759029579. I am going to try it with O'Neill's 6364136223846793005. Back later.

[dafhi]

sounds like you're having fun. in my image compression project i found that i can use a hash to simulate 2^32 bits (or whatever state size) x,y,r,g,b,radius of a circle, and combined with an error measurement, all i need is 1 bit of seed selection on say the x, and the image will begin to clarify

so before, i was using at least 6 attributes x 4 bytes, now all i need is 1 bit. the image isn't nearly a perfect match, and the clarification process takes a while, but this is awesome. it's broke atm xD

[deltarho[1859]]

OK using 6364136223846793005 I get to 2TB with no anomalies. I'll repeat that - no anomalies. We don't see that often.

We could test 15241094284759029579 a few times and get no anomalies. We could test 6364136223846793005 a few times and get anomalies. However, when testing I prefer single tests and let the algorithms take their chances. So, there may be something in using 6364136223846793005.

I wrote "O'Neill's 6364136223846793005". In fact, it is the multiplier used in Donald Knuth's 64-bit LCG.

Above I refereed to it as a prime - it isn't and factorizes as 3*5*415949*1020018675983 with those four numbers as primes.

I have also found another instance of its use. Mersenne Twister uses 1812433253 in the original paper, but uses 6364136223846793005 in the 64-bit version of Mersenne Twister. Why? I have no idea.

[dafhi]

relative prime

[deltarho[1859]]

Relatively prime requires two numbers to compare.

[dafhi]

why wouldn't the 2nd number be 2^64

[deltarho[1859]]

I think I am done here now.

[dafhi]

yeah i just realized relative prime has to do with the add :\

[jj2007]

Forget my comment about RomuTrio being faster than dodicat.

Actually, I was quite surprised to see that. All the candidates are very short under the hood, in practice there is no way to make one of them a factor 2 faster. Physical limits.