It seems to always create even numbers. You might want to fix that. Using the date, hour, etc is not helping, because those are derived from time in milliseconds in snap. Time in milliseconds is the total number of milliseconds since 1970, not a number under 1000. I am currently running a test, and so far it seems to be about even. I don't know if that is exact though.
Umm... Not always for me.
Yes, I know. I use them because calculating the difference with Unix time will create a small but a good difference, so I can make it more random using operations.
In any case, it does create evenly distributed pseudorandom numbers, at least if your clock continues to advance.
Could you explain this better?
Do you guys have different width computers? Back when Berkeley converted Unix from the 16-bit PDP-11 to the 32-bit Vax, they didn't pay enough attention to the random number algorithm, and it started returning only even numbers. And the funny part is that it took several years before anyone noticed.
What are these?
Computers. From the 1970s to 1980s. Look 'em up!
No, of course not. But it's possible that one of you still has a 32-bit computer, of which there are still a lot around, and another of you has a shiny new 64-bit computer. The point of my story is that pseudorandom number generators are sensitive to the width of a word.
Anyway, I think this algorithm is effective because it generated 1000000 (one million) numbers, all of them different...
is it just me or is the algorithim slower than the builtin?
https://snap.berkeley.edu/snap/snap.html#present:Username=programmer_user&ProjectName=Random%20Contest
Yes, is a bit slower though...
But, a recommendation is that you shouldn't use it with a custom block, since it will generate unnecessary candidates. That will make it faster...