=?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeb### [at] freefr> wrote:
> Jay Fox wrote:
> > "Phoenex" <rib### [at] sapopt> wrote:
> >> The algorithm PRNGAlvo was put in this discussion, always with an atti
> tude of
> >> helping, and to receive critics about it.
> >
> > Well, in the spirit of constructive analysis, I will say that Alvo is p
> robably
> > better than a 32-bit LCG.
> >
> > Just to set the record straight, Phoenex is right: Alvo is NOT an LCG.
> > Technically, anyway, and depending on how strictly you define an LCG.
> >
>  I beg to disagree. An LCG is called that because it uses a linear
> equation followed by a congruence. The Alvo algorithm fits that
> description.
>
Well, I tried to qualify that it depends on how strictly you define an LCG. In
an integer LCG (or a floating point LCG with an INTEGER multiplier and
sufficient 0-padding in the lower bits of the floating point number), there is
never a loss of information in the lower bits. The upper bits are intentionally
discarded, which is the "congruential" part of an LCG.

However, when the multiplier is not an integer, then unless you use
infinite-precision math (which is to say, never), you necessarily will have to
truncate lower bits. That's truncation, not modular congruence. So it's not an
LCG in the strictest sense. The truncation is non-linear. And it's not exactly
modular congruence either (e.g. 1.211 mod 1.0 != 0.21). Take your pick, but in
my book, it's not an LCG.

But yes, it's basically the same thing. Apple or orange, it's still a fruit.
It's not a carrot or a rack of lamb.

Post a reply to this message