Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Reuther Newsgroups: de.comp.lang.misc Subject: Re: [srand()/rand()] Ich brauche mehr Chaos. Date: Mon, 10 Mar 2025 18:13:46 +0100 Lines: 28 Message-ID: References: <20250309201000.2c112389@Achmuehle.WOR> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net tSCndO6NJyChnEJmQB5tWAuEPBUoHvXlIoqXUtTfbVMzwnLJte Cancel-Lock: sha1:jiYhRllmdFNRghFvRV/bkkDCUC8= sha256:zcgbnY5SVrPRxhZ/iqqv353fjjiZpRYWc5D7ZuNbpKY= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 Hamster/2.1.0.1538 In-Reply-To: Xref: csiph.com de.comp.lang.misc:2083 Am 10.03.2025 um 07:30 schrieb Michael Uplawski: > Sieghard Schicktanz hat geschrieben: >>> srand(Time.now.nsec) >>> allSigs[rand(numSigs)] >> >> _Könnte_ es evtl. daran liegen, daß der Zufallsgenerator jedesmal wieder >> auf einen "ähnlichen" Anfangswert gesetzt wird? > > Ich kenne mich mit PRNGs nicht aus. Mein Verständnis war bisher, > dass ein abweichender Seed-Wert für ausreichende Variationen sorgen > sollte. Die Frage ist, wieviele der Bits von 'Time.now.nsec' durch 'srand' ausgewertet werden - und andererseits, wieviele der Bits überhaupt gültig sind. Der klassische C-Zufallsgenerator nutzt nur 15 Bit. Und wenn im Extremfall dein Betriebssystem die Zeit in Zeitscheiben von 16 Millisekunden misst, und dir folglich als Nanosekunden nur Vielfache von 16000000 gibt, hast du von den 15 Bit schon 11 verloren. Ich würde als Seed für den Zufallsgenerator immer ein paar Bytes aus /dev/urandom benutzen. Wenn du das nicht hast, dann wenigstens die Nanosekunden irgendwie mit xor zusammenfalten (also in C sowas wie 'x ^= (x >> 16)') und ggf. die pid mit einbeziehen. Stefan