www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/08/13/06:44:08

Message-ID: <321058A3.6A5C@pobox.oleane.com>
Date: Tue, 13 Aug 1996 12:27:47 +0200
From: Francois Charton <deef AT pobox DOT oleane DOT com>
Organization: CCMSA
MIME-Version: 1.0
To: Alexander Lehmann <lehmann AT mathematik DOT th-darmstadt DOT de>
CC: djgpp AT delorie DOT com
Subject: Re: problem with libm.a "pow" function (and comment on ran())
References: <320E4A9F DOT 6E8 AT pobox DOT oleane DOT com> <4uo0l6$1igc AT rs18 DOT hrz DOT th-darmstadt DOT de>

Alexander Lehmann wrote:
>
> Actually, when you want randomness, the rand function isn't of much
> use anyway. (I think this is even mentioned in some versions of the
> rand(3) manpage). There are a couple of much improved random
> functions, including one from BSD, which may or may not be in the
> djgpp library (random(), I think) or you could get it from the BSD 4.4
> distribution.
> If it is so bad, why put it in the library ? (no, I'm just kidding).

rand(), IMHO, has two advantages : it is fast, reasonably random, and 
ANSI-compliant (if this means something for random numbers...).

The congruential generator used : 
next=next*1103515245+12345
is neither excellent, nor specially bad, it has been suggested by the 
ANSI comitee so that different machine might have the same generator. I 
am not sure that this is pertinent, but if ANSI wanted it, then let it 
be.

The point I was trying to make was that the "bit shuffling" thing in the 
libc rand() function changes the generator, which is no more an "ANSI 
formula" generator... If this makes the generator more random at no speed 
cost, it is ok, but if the resulting generator is no  better than the 
previous one, why ?

Bye,
Francois

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019