Discussion:
Anfaengerfrage zu s-/rand
(zu alt für eine Antwort)
Helmut Wuensch
2016-09-20 14:19:36 UTC
Permalink
Hallo!

Welcher Wertebereich (x) bei der Seed von srand(x)?
(Meine Vermutung: int x von 1 bis 2^15-1.)
Wo kann ich solche Infos nachlesen?
Auch die Zuordnung der Funktionen zu den
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
interessiert mich?
Es müsste doch ein (preiswertes) Kompendium
geben, oder?
Wie groß ist der Bereich von rand() in der
*keine* Wiederholung stattfindet?
(Früher habe ich das 'mal bei qbasic getestet;
da war es ca. 1,6 Mill. bei 256 Möglichkeiten.
Kann mich aber auch um eine Dezimale täuschen.)

Sorry für die für Euch sicher einfachen Fragen,
aber dafür ein *Dankeschön* für Eure Antworten! :-)

cu Helmut
Thomas Jahns
2016-09-20 14:40:28 UTC
Permalink
Post by Helmut Wuensch
Welcher Wertebereich (x) bei der Seed von srand(x)?
(Meine Vermutung: int x von 1 bis 2^15-1.)
Wo kann ich solche Infos nachlesen?
In der Dokumentation der jeweiligen Implementierung, da dieses nicht Teil des
Standards ist. Wenn Du Zufallszahlen von einiger Qualität brauchst ist rand
vermutl. eh nicht die richtige Wahl.
Post by Helmut Wuensch
Auch die Zuordnung der Funktionen zu den
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
interessiert mich?
Das ist hingegen Teil des C-Standards. Gibt es als Buch zu kaufen. Auf
Unix-artigen verrät aber auch "man 3 function" was es bei einer Funktion der
C-Bibliothek zu beachten gilt.
Post by Helmut Wuensch
Es müsste doch ein (preiswertes) Kompendium
geben, oder?
Wie schon oben geschrieben, aber ob man den C-Standard als preiswert einstuft
ist eine Frage der Meinung. Bei Lehmanns finde ich den Preis für C99 durchaus
erträglich[1].
Post by Helmut Wuensch
Wie groß ist der Bereich von rand() in der
*keine* Wiederholung stattfindet?
(Früher habe ich das 'mal bei qbasic getestet;
da war es ca. 1,6 Mill. bei 256 Möglichkeiten.
Kann mich aber auch um eine Dezimale täuschen.)
Im C99-Standard beschreibt 7.20.2 rand und srand. Derartige Details der
Implementierung sind aber nicht Teil der Sprachdefinition. Da kann jeder
Hersteller sein eigenes Ding machen. Linux nimmt random als Basis.

Thomas


[1]
http://www.lehmanns.de/shop/mathematik-informatik/3420850-9780470845738-c-standard
Claus Reibenstein
2016-09-20 16:31:32 UTC
Permalink
Post by Thomas Jahns
Post by Helmut Wuensch
Welcher Wertebereich (x) bei der Seed von srand(x)?
(Meine Vermutung: int x von 1 bis 2^15-1.)
Wo kann ich solche Infos nachlesen?
In der Dokumentation der jeweiligen Implementierung, da dieses nicht Teil des
Standards ist.
srand() verlangt ein unsigned int. Über den erlaubten Wertebereich gibt
es seitens des Standards keine Einschränkung. Also sollte alles von 0
bis UINT_MAX erlaubt sein. Eine Implementierung, die hier
Einschränkungen vorschreibt, wäre IMHO als kaputt einzustufen.

Gruß
Claus
Thomas Jahns
2016-09-21 09:15:51 UTC
Permalink
Post by Claus Reibenstein
srand() verlangt ein unsigned int. Über den erlaubten Wertebereich gibt
es seitens des Standards keine Einschränkung. Also sollte alles von 0
bis UINT_MAX erlaubt sein. Eine Implementierung, die hier
Einschränkungen vorschreibt, wäre IMHO als kaputt einzustufen.
Ich glaube, dem OP ging es darum, wie viele Bits des Initialwerts verwertet
werden. Kann mich aber auch täuschen.

Thomas
Claus Reibenstein
2016-09-21 16:59:08 UTC
Permalink
Post by Thomas Jahns
srand() verlangt ein unsigned int. [...]
Ich glaube, dem OP ging es darum, wie viele Bits des Initialwerts verwertet
werden. Kann mich aber auch täuschen.
Dazu müsste ich sein Posting sehen, aber aufgrund der invaliden
Mailadresse wurde er von meinem SeaMonkey zuverlässig entsorgt.

Gruß
Claus
Helmut Wuensch
2016-09-24 08:24:41 UTC
Permalink
Hallo Claus!

Zuerst 'mal ein *Danke* an Dich!
Post by Claus Reibenstein
Post by Thomas Jahns
srand() verlangt ein unsigned int. [...]
Ich glaube, dem OP ging es darum, wie viele Bits des Initialwerts verwertet
werden. Kann mich aber auch täuschen.
Dazu müsste ich sein Posting sehen, aber aufgrund der invaliden
Mailadresse wurde er von meinem SeaMonkey zuverlässig entsorgt.
Leider ist da Dein SeaMonkey auf dem Holzweg, denn es
ist wohl eine Falsch-Entscheidung! Du solltest einfach
'mal genauer hinschauen!

cu Helmut
David Seppi
2016-09-22 18:02:36 UTC
Permalink
Post by Thomas Jahns
Auf
Unix-artigen verrät aber auch "man 3 function" was es bei einer Funktion der
C-Bibliothek zu beachten gilt.
| ***@vps:~$ man 3 function
| Kein Handbucheintrag für function im Abschnitt 3 vorhanden
| ***@vps:~$ man function
| Kein Handbucheintrag für function vorhanden
| ***@vps:~$ uname -a
| Linux vps 2.6.32-042stab116.2 #1 SMP Fri Jun 24 15:33:57 MSK 2016 i686
| GNU/Linux
(Debian Jessie)
--
David Seppi
1220 Wien
Stefan Reuther
2016-09-20 16:16:15 UTC
Permalink
Post by Helmut Wuensch
Welcher Wertebereich (x) bei der Seed von srand(x)?
(Meine Vermutung: int x von 1 bis 2^15-1.)
Wo kann ich solche Infos nachlesen?
Der Parameter hat den Typ 'unsigned int' und der C-Standard gibt keine
Einschränkungen vor, also kannst du da erstmal alles reinstecken, was du
in einen 'unsigned int' bekommst.

Es gibt allerdings keine Qualitätsforderungen; ob dann also alle Bits
benutzt werden, ist nicht garantiert.
Post by Helmut Wuensch
Auch die Zuordnung der Funktionen zu den
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
interessiert mich?
Es müsste doch ein (preiswertes) Kompendium
geben, oder?
Entweder den Standard. Oder einen Draft
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf). Oder die
Single Unix Specification
(http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm). Oder die
Manpages deines Systems. Bei letzteren beiden beachten, dass die
natürlich dein System dokumentieren und nicht die schöne Theorie des
Standard-C.
Post by Helmut Wuensch
Wie groß ist der Bereich von rand() in der
*keine* Wiederholung stattfindet?
(Früher habe ich das 'mal bei qbasic getestet;
da war es ca. 1,6 Mill. bei 256 Möglichkeiten.
Kann mich aber auch um eine Dezimale täuschen.)
Wie gesagt, dazu gibt es seitens des C-Standards keine Qualitätsforderungen.

Etwas bessere Qualitätsforderungen gibt es z.B. für die Funktion
'random' aus der Single Unix Specification ("With 256 bytes of state
information, the period of the random-number generator shall be greater
than 2^69.").


Stefan
Helmut Wuensch
2016-09-24 08:39:42 UTC
Permalink
Hallo Stefan,
hallo Claus!

*Danke* für Eure tollen Infos! Bitte entschuldigt,
wenn ich nochmals nachhake!
Post by Stefan Reuther
Post by Helmut Wuensch
Welcher Wertebereich (x) bei der Seed von srand(x)?
(Meine Vermutung: int x von 1 bis 2^15-1.)
Wo kann ich solche Infos nachlesen?
Der Parameter hat den Typ 'unsigned int' und der C-Standard gibt keine
Einschränkungen vor, also kannst du da erstmal alles reinstecken, was du
in einen 'unsigned int' bekommst.
ok.
Post by Stefan Reuther
Es gibt allerdings keine Qualitätsforderungen; ob dann also alle Bits
benutzt werden, ist nicht garantiert.
Auch klar.

...
Post by Stefan Reuther
Post by Helmut Wuensch
Es müsste doch ein (preiswertes) Kompendium
geben, oder?
Entweder den Standard. Oder einen Draft
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf).
Habe ich mir geholt!
Post by Stefan Reuther
Oder die Single Unix Specification
(http://pubs.opengroup.org/onlinepubs/9699919799/toc.htm). Oder die
Manpages deines Systems. Bei letzteren beiden beachten, dass die
natürlich dein System dokumentieren und nicht die schöne Theorie des
Standard-C.
Auch klar. Trotz (vieler) guter Absichten, bin ich bei
Win XP stehen geblieben. :-(

...
Post by Stefan Reuther
Etwas bessere Qualitätsforderungen gibt es z.B. für die Funktion
'random' aus der Single Unix Specification ("With 256 bytes of state
information, the period of the random-number generator shall be greater
than 2^69.").
Ihr sprecht immer wieder von "Qualitätsforderungen" bzw.,
dass rand() nicht für Verschlüsselung gut sein soll, kannst
Du mir dies 'mal erklären, warum dies so ist! (Ist denn
nicht "Zufall" gleich "Zufall"? Gut "Zufall", der wieder-
holt/reproduziert werden kann, wenn seed bekannt ist ...
- Aber die sollte in *keinem* Fall publik sein.)

cu Helmut
Stefan Reuther
2016-09-24 09:44:35 UTC
Permalink
Post by Helmut Wuensch
Post by Stefan Reuther
Etwas bessere Qualitätsforderungen gibt es z.B. für die Funktion
'random' aus der Single Unix Specification ("With 256 bytes of state
information, the period of the random-number generator shall be greater
than 2^69.").
Ihr sprecht immer wieder von "Qualitätsforderungen" bzw.,
dass rand() nicht für Verschlüsselung gut sein soll, kannst
Du mir dies 'mal erklären, warum dies so ist! (Ist denn
nicht "Zufall" gleich "Zufall"? Gut "Zufall", der wieder-
holt/reproduziert werden kann, wenn seed bekannt ist ...
- Aber die sollte in *keinem* Fall publik sein.)
Dies ist nach meinem Dafürhalten eine standardkonforme Implementation
von rand / srand:

static int state;
void srand(unsigned int seed) {
state = (seed & 1);
}
int rand() {
state ^= 1;
return RAND_MAX * state;
}

Dass das kein guter Zufall ist, sollte einleuchten.


Stefan
Peter J. Holzer
2016-09-24 10:25:58 UTC
Permalink
Post by Helmut Wuensch
Ihr sprecht immer wieder von "Qualitätsforderungen" bzw.,
dass rand() nicht für Verschlüsselung gut sein soll, kannst
Du mir dies 'mal erklären, warum dies so ist! (Ist denn
nicht "Zufall" gleich "Zufall"? Gut "Zufall", der wieder-
holt/reproduziert werden kann, wenn seed bekannt ist ...
- Aber die sollte in *keinem* Fall publik sein.)
Die Seed ist aber recht klein - 4294967296 Möglichkeiten (bei einem
handelsüblichen 32 Bit unsigned int) sind im Zweifelsfall schnell
durchprobiert. Für kryptographische Anwendungen wäre das allein schon
Ausschlusskriterium. Dazu kommt, dass man bei nicht-kryptographischen
Zufallszahlengeneratoren meist ein relativ einfacher Zusammenhang
zwischen dem internen Zustand und den generierten Zufallszahlen besteht
- wenn man eine genügend lange Folge von Outputs beobachtet, kann man
auf den internen Zustand schließen und dann die Folge fortführen.

Für kryptographische Verfahren will man Zufallszahlengeneratoren,
die ein möglichst nicht reversierbares Mischverfahren verwenden und
echten Zufall reinmischen.

Aber auch, wenn das keine Rolle spielt, gibt es unterschiedliche
Qualitätskriterien für Zufallszahlengeneratoren. Die Folge soll sich in
diversen statistischen Eigenschaften nicht von einer Zufallsfolge
unterscheiden.

Die von Helmut gepostete Man-Page von random() weist z.B. auf ein
Problem einer weitverbreiteten Implementation von rand() hin: Bei
linearen Kongruenzgeneratoren haben die unteren Bits kürzere Perioden.
In der klassischen (16-Bit) Unix-Implementation hatte das unterste Bit
eine Periode von 2^17, das zweitunterste eine von 2^18, etc. Das war
damals für viele Anwendungen wohl ausreichend. In DEC Ultrix (einer
BSD-Variante in den 80er-Jahren) hat das dann jemand naiv auf 32 Bit
aufgebohrt, indem er einfach den Shift entfernt hat. Ergebnis: Das
unterste Bit hatte eine Periode von 2, das nächste eine von 4, etc. Wenn
ein Zufallszahlengenerator immer abwechselnd eine gerade und eine
ungerade Zahl liefert, wirkt das nicht mehr sehr zufällig.
Ein üblicher Workaround ist, bevorzugt die obersten Bits zu verwenden.
Wenn Du eine ganzzahlige Zufallszahl im Intervall [0, n) brauchst,
verwende nicht (rand() % n), sondern ((int)(rand() * (double)n /
(double)RAND_MAX+1)) (das liefert auch eine bessere Verteilung).

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Helmut Schellong
2016-09-25 20:20:10 UTC
Permalink
Post by Peter J. Holzer
Post by Helmut Wuensch
Ihr sprecht immer wieder von "Qualitätsforderungen" bzw.,
dass rand() nicht für Verschlüsselung gut sein soll, kannst
Die Seed ist aber recht klein - 4294967296 Möglichkeiten (bei einem
handelsüblichen 32 Bit unsigned int) sind im Zweifelsfall schnell
durchprobiert. Für kryptographische Anwendungen wäre das allein schon
Ausschlusskriterium. Dazu kommt, dass man bei nicht-kryptographischen
Zufallszahlengeneratoren meist ein relativ einfacher Zusammenhang
zwischen dem internen Zustand und den generierten Zufallszahlen besteht
- wenn man eine genügend lange Folge von Outputs beobachtet, kann man
auf den internen Zustand schließen und dann die Folge fortführen.
Für kryptographische Verfahren will man Zufallszahlengeneratoren,
die ein möglichst nicht reversierbares Mischverfahren verwenden und
echten Zufall reinmischen.
[...]

Ich habe nun den Algorithmus 'Spritz', den Nachfolger von arc4/RC4,
in bsh implementiert.
Wertbereich bis 2^32-1 bzw. 2^63-1 (2^64-1).

Das dürfte jenseits von allem liegen, das so in libc vorhanden ist.
Lediglich (Free)BSD hat eine Familie arc4random() darin, den
Vorläufer von Spritz.

Ich verwende mehrere Datenobjekte, die alle ihre Inhalte ständig
und teilweise unvorhersehbar verändern, zur Initialisierung.
Init erfolgt nicht nur bei erster Benutzung, sondern auch nach jeweils
einer bestimmten Menge ausgegebener Zahlen.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Wuensch
2016-09-24 13:48:50 UTC
Permalink
Hi Stefan und Peter,

*vielen Dank* für Eure ganz tolle Info!!
(Leider seid Ihr Profis und ich nur ein kleiner
Newby, der zum Verstehen doch etwas länger "brüten"
muss .... :-(
Ich werde mir Euren Text demnächst nochmals ganz
genau ansehen und dann hoffentlich ganz verstehen. :-) )

cu Helmut
Helmut Schellong
2016-09-25 18:13:37 UTC
Permalink
Post by Helmut Wuensch
Post by Stefan Reuther
Etwas bessere Qualitätsforderungen gibt es z.B. für die Funktion
'random' aus der Single Unix Specification ("With 256 bytes of state
Ihr sprecht immer wieder von "Qualitätsforderungen" bzw.,
dass rand() nicht für Verschlüsselung gut sein soll, kannst
Du mir dies 'mal erklären, warum dies so ist! (Ist denn
nicht "Zufall" gleich "Zufall"? Gut "Zufall", der wieder-
holt/reproduziert werden kann, wenn seed bekannt ist ...
- Aber die sollte in *keinem* Fall publik sein.)
Die Qualität ist durch viele einfache Tests nicht zu erkennen.
Abzählen, wie oft 0 und 1 jeweils vorkommen, sagt fast nichts
über die Qualität aus!
Besser ist da schon, das Spektrum mit dem Kennerauge anzusehen:
======================================================================
010011000100110000110000010001000110001011011101001011101010
010110111100010101011100111100001101110010100100110010010100
110011111001110001100001111001010111101000011101011100111010
011110101000111101110100011001000010000010101001011111000000
101101101100100001010100110010100001010100110111010111101101
010001001101101001100010010110101001110000011010000100001001
001100011101110001000001111010011001111000010111000000011101
111000000011011110000100000011101000100011000100011110010110
000001010110111000100010011011010010000011101111010000011100
011011100100110001001110011110111010000001001011100001010000
101111000101000001101110011001000111110011001000110110010110
010011000000000010011010001001011001001111000111011101101100
000110011010110111011111111101000110101001100001001001111001
010011111111110000101011010000101001100010001110010110001111
001001101100110101110011001111000100000011000101000011011100
011100110010100100001001001000110000000101001100000101100111
101010101001001011101101100101000111110011010111011010011001
011110101011111000010000100000111101110100000110011010101000
000011111101100101010101100010101101100011100100001011011011
100010101011010101111001101010111101001110000001101011101110
000111011011100101111111011011110111011011101110101100100010
010110011110001011110010100111101010001100011111100010100001
110000100101110000011011001101011111101011001100000101000001
101110011111101100111001011111100000011000101010001010110110
100010010010001111000111010001101101110000000010100000101110
101011000001110100000101001001100000100001100001100011001111
111100100110001100010000111011110110000101001111100100101000
101101010011010111100000000100000101011110011111001000001000
010101110010010000111110001100001111101111101101000011111001
101000000010111100100101010010100100101110110111110000010010
011010110101110101110011001110101000110110010010001001000100
100111101000010011100011111000101010100011100000001010001101
111000001101111010100100101011010111010001011110101110011010
110011011010000000100011100000011001010111101111110100011111
011001101000001100110110101010000000101011011101001110101011
111111100000010010110100011111101011010000100100111000000101
100010110001001000100011111011110001000110001001110110111101
010101000010101101011111000101101100000011011011000101000110
001111001110000000011101100100110101001100001110010011010001
101000010100000101010001001010100100100101010010001000011011
101011010001000110010001011011001100011100110101101111001011
011000100011001111001010100101101100101101000011111001011111
100010011010010001110100101100100010010101111001100001001110
010100110011010100100111101010100000011001010100100111011101
001111110001111110100001110101001101111011001000111011011100
111111101010010000000010001101111100110110010000101101110001
011110101010110011001100110000000000100111010101101111111001
111000010000101110001000000111100100100000111100100110011010
010000011011100100011101010100011101000101100111101000111000
011011011110101101101100001100101100001001000010110000010011
001101110100100000001000110100001101010101000110010011100011
000001110010010110101000100001001000100001000101101100000011
100100000101111110111100000000011111010100001101010101111100
000000100111000010111011001010101010111110000000100001000101
110001101111011001101011100111001101010011100010001111111100
111100010010101101100001111100010011011100000000011011101111
100100010101011011010011010101010100000011101111100100101010
101111100000010010110000001111011101111010000101110010001101
110001111000111000101100101100001011001001100101010000100010
011111100000110110010000110011101110110101110010010101110111
100001000001101010111111100010010001111101110001011011111010
101111011101101111010011011000111011011011011000111010101100
111000110101100100110001101110000000000000000101110101100101
110110111100100010110101111101001000100101001001111101011110
110101111001100000100011101100111101100010100011001011010110
000101000000111110101010110000110111111101111100100010101010
1100000100110000111011100100001110001010
======================================================================

Die vorstehende Sequenz wurde mit dem Algorithmus 'Spritz' erzeugt,
den ich in 'bsh' implementierte, und der kryptographisch sicher ist.
Das dürfte im Vergleich zu lib-Funktionen eine unschlagbar gute
Qualität sein.
(Spritz ist der Nachfolger von arc4/RC4.)
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Wuensch
2016-09-20 16:58:14 UTC
Permalink
Hi Thomas, Claus und Stefan!

Zuerst *vielen, vielen Dank* für Eure Antworten!
Als Newby bin ich da leider bei dem Einen oder
Anderen momentan "etwas" überfordert! :-(

Aber ich werde mich da reinhängen ....
Versprochen :-)

cu Helmut
Helmut Schellong
2016-09-20 22:52:13 UTC
Permalink
Post by Helmut Wuensch
Hallo!
Welcher Wertebereich (x) bei der Seed von srand(x)?
(Meine Vermutung: int x von 1 bis 2^15-1.)
Wo kann ich solche Infos nachlesen?
Auch die Zuordnung der Funktionen zu den
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
interessiert mich?
Es müsste doch ein (preiswertes) Kompendium
geben, oder?
Wie groß ist der Bereich von rand() in der
*keine* Wiederholung stattfindet?
(Früher habe ich das 'mal bei qbasic getestet;
da war es ca. 1,6 Mill. bei 256 Möglichkeiten.
Kann mich aber auch um eine Dezimale täuschen.)
Nimm diese:

LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <stdlib.h>

long
random(void);

void
srandom(unsigned long seed);

DESCRIPTION
The functions described in this manual page are not cryptographically
secure. Cryptographic applications should use arc4random(3) instead.

The random() function uses a non-linear additive feedback random number
generator employing a default table of size 31 long integers to return
successive pseudo-random numbers in the range from 0 to (2**31)-1. The
period of this random number generator is very large, approximately
16*((2**31)-1).

The random() and srandom() functions have (almost) the same calling
sequence and initialization properties as the rand(3) and srand(3) func-
tions. The difference is that rand(3) produces a much less random
sequence -- in fact, the low dozen bits generated by rand go through a
cyclic pattern. All the bits generated by random() are usable.
For example, `random()&01' will produce a random binary value.

Like rand(3), random() will by default produce a sequence of numbers
that can be duplicated by calling srandom() with `1' as the seed.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Helmut Wuensch
2016-09-21 06:45:09 UTC
Permalink
Hallo Helmut!


*Herzlichen Dank*!

cu Helmut
...
Post by Helmut Schellong
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include <stdlib.h>
long
random(void);
void
srandom(unsigned long seed);
DESCRIPTION
The functions described in this manual page are not cryptographically
secure. Cryptographic applications should use arc4random(3) instead.
The random() function uses a non-linear additive feedback random number
generator employing a default table of size 31 long integers to return
successive pseudo-random numbers in the range from 0 to (2**31)-1. The
period of this random number generator is very large, approximately
16*((2**31)-1).
The random() and srandom() functions have (almost) the same calling
sequence and initialization properties as the rand(3) and srand(3) func-
tions. The difference is that rand(3) produces a much less random
sequence -- in fact, the low dozen bits generated by rand go through a
cyclic pattern. All the bits generated by random() are usable.
For example, `random()&01' will produce a random binary value.
Like rand(3), random() will by default produce a sequence of numbers
that can be duplicated by calling srandom() with `1' as the seed.
Loading...