Re: Generating normally distributed randoms in CL

"Madhu" == Madhu <enometh@xxxxxxxx> writes:

Madhu> * (Raymond Toy (RT/EUS)) <sxd1w1b9l7y.fsf@xxxxxxxxxxxxxxx> :
Madhu> Wrote on Wed, 30 Jul 2008 16:21:37 -0400:

Madhu> | Madhu> I suggest that there is another reason to use a well known
Madhu> | Madhu> implementation.
Madhu> |
Madhu> | Madhu> For serious simulations you want to publish repeatable results,
Madhu> | Madhu> _independent_ of the Common Lisp implementation you use---In
Madhu> | Madhu> that case your simulation program cannot depend on a package
Madhu> | Madhu> which calls CL:RANDOM [as different implementations will
Madhu> | Madhu> produce different sequences of numbers]. It is preferable to
Madhu> | Madhu> use FFI to a "Standard" C implementation, like the "RANLIB.C"
Madhu> | Madhu> package from NETLIB,
Madhu> |
Madhu> | I would suggest that if your simulation results depended on the
Madhu> | sequence of random numbers, then your simulation is broken.

Madhu> No that is not what I'm suggesting.

Madhu> The point I'm making is about getting the exact same simulation result
Madhu> (after seeding the rng identically) on different runs of the
Madhu> application. [This is often required to verify your simulation is NOT
Madhu> broken in some ways]

Agreed. Especially if you're debugging something and the bug keeps
moving because the seed is different on each run. But it's also good
to use a different seed and/or rng once in a while to make sure some
weird scenario is handled.

Madhu> If you switch lisp implementation you get a different number from your
Madhu> program because you are switching the rng. The suggestion to use a well
Madhu> known RNG was to get identical results regardless of the lisp
Madhu> implementation.

This is also one of the reasons I've never bothered to change CMUCL's
rng. There are new ones out there that are at least as good or better
in some way. But changing it breaks so many things because the
results won't be the same as before.

Madhu> Am I missing something?

Nothing really. I guess I should have put a smilely there. I think
it's good to use a different implementation once in a while to
discover any wierd issues.

I often times use gcc and Sun C to compile my code to see what bad
assumptions I may have made. Way back when we had this simulation
that worked beautifully. But when we recompiled the code for a
different machine, it was totally broken. Why? Because the compilers
on the different machines did different things for "uninitialized"
memory. One zeroed it out, the other left random bit there. The
program should have initialized memory itself.

Ray

.

Relevant Pages