Difference between revisions of "Talk:Pseudo-random Number Generator"
Jump to navigation
Jump to search
(unsigned comment) |
m |
||
| Line 9: | Line 9: | ||
: I like to try to keep the code human-readable at first, but I'll add this as the optimized version. Thanks --[[User:Xaviar Czervik|Xaviar Czervik]] 09:55, 26 November 2007 (PST) | : I like to try to keep the code human-readable at first, but I'll add this as the optimized version. Thanks --[[User:Xaviar Czervik|Xaviar Czervik]] 09:55, 26 November 2007 (PST) | ||
If we use 2 seeds, could we XOR "^" the seeds after modifiing the seeds, instead of "+" or "*"? to make it faster? <small> | If we use 2 seeds, could we XOR "^" the seeds after modifiing the seeds, instead of "+" or "*"? to make it faster? <small>—The preceding unsigned comment was added by [[User:Ollj Oh|Ollj Oh]]</small> | ||
: I haven't done cryptographic analysis of this function to ensure it's distribution but I'm inclined to say that you shouldn't use XOR. I think it would result in some quantity of bits being predictable. I'm pretty sure the distribution of this function is skewed regardless. If you feed it 1431655765, you should notice that numbers between -715827882 & 715827882 have twice the probability then those outside. With smaller numbers this type of skew is less noticeable, but as long as <code>((2147483648 % spread ) != 0)</code> is true then you will have a skew. -- [[User:Strife Onizuka|Strife Onizuka]] 09:07, 11 February 2008 (PST) | |||
Revision as of 10:07, 11 February 2008
rand can be optimized to and will be mono safe as...
integer rand(integer spread) {
seed2 = (seed2 * seed2Mod + 0xB);
return (seed1Mod = ((seed1 = (seed1 * (seed2Mod = seed1Mod) + 0xB)) * seed2)) % spread;
}
-- Strife Onizuka 11:25, 21 November 2007 (PST)
- I like to try to keep the code human-readable at first, but I'll add this as the optimized version. Thanks --Xaviar Czervik 09:55, 26 November 2007 (PST)
If we use 2 seeds, could we XOR "^" the seeds after modifiing the seeds, instead of "+" or "*"? to make it faster? —The preceding unsigned comment was added by Ollj Oh
- I haven't done cryptographic analysis of this function to ensure it's distribution but I'm inclined to say that you shouldn't use XOR. I think it would result in some quantity of bits being predictable. I'm pretty sure the distribution of this function is skewed regardless. If you feed it 1431655765, you should notice that numbers between -715827882 & 715827882 have twice the probability then those outside. With smaller numbers this type of skew is less noticeable, but as long as
((2147483648 % spread ) != 0)is true then you will have a skew. -- Strife Onizuka 09:07, 11 February 2008 (PST)