On Tue, Feb 15, 2005 at 12:38:59PM +0000, Dr Robert Sanderson wrote:
>
> >asked before. I wonder if anyone who is familiar with the source code
> >and randomisation techniques can tell me how it stacks up against other
> >mathematical 'random' number generator in simulating unpredictable
> >reuslts.
>
> AFAIK, it just calls out to the operating system's rand() function.
> So it's as good as your operating system's implementation.
Do you know of any Operating Systems on which lrand48() is actually better,
or even nearly as good, as random()? I know that isn't the case on NetBSD,
which has a quite good random() function, but I haven't investigate other
OS's yet. I am willing to bet the same is true on FreeBSD, OpenBSD, and
Linux, at the very least.
What's surprising to me is that the MOO server is written to prefer
{l,s}rand48(3) over {,s}random(3), even though autoconf sets HAVE_RANDOM.
the {,s}random(3) functions are only used if {l,s}rand48(3) are unavailable,
for some reason. My suspicion is that this dates back to the Heydey of
LambdaMOO on old Unices - for example, the same reason that LambdaMOO still
had code for "/dev/tcp" on Solaris in it. I'll be fixing this in LambdaMOO
1.8.1+foo as soon as I finish sending this mail. We're not quite caught up
to LambdaMOO CVS as far as things like WROGUE go - I haven't even started
merging that in - but the network code, at least, has been almost totally
redone. No reason that the random code shouldn't be brought out of the stone
age as well :-)
PS: I don't suppose anyone is interested in helping with the rather daunting
task of fixing LambdaMOO's memory allocation code? specifically, the goal is
for allocations to be able to fail without bringing down the server
($list_utils:make($maxint) for an example.) I've got plenty of experience
messing with dirty C code, but the ref counting mechanisms used by LambdaMOO
frankly baffle me: The address free()'d is almost NEVER the one returned by
malloc(), and it's left up to the OS to handle this properly. Try running a
database created on an i386, and run there for several years, on an Alpha,
and watch it explode. Try the same thing on an UltraSPARC, and watch it work
just fine. Or, if you really want to have fun, link the MOO server against
ElectricFence. It'll go into an infinite loop no matter where your database
comes from or what hardware you're using. :-P
- Sean
--
_
( ) ASCII Ribbon Campaign
X
/ \ For Plain Text Email
#############################################################
This message is sent to you because you are subscribed to
the mailing list <moo-cows@the-b.org>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to <[EMAIL PROTECTED]>
