C++11-PRNGs

[cooky451]

asfdlol schrieb:

Ich habe eine gleichverteilte Engine geschrieben

Könntest du die mal posten?

asfdlol schrieb:

und sogar kryptographisch sicher.

Hört sich interessant an, aber habe ich leider wenig zu gefunden bei einer schnellen Suche. Gibt's da was zu lesen?

asfdlol schrieb:

Gibt es einen direkten Weg um den Zustand speichersparend abzuspeichern oder wenigstens auf den internen Zustand zugreifen zu können?

Nein, weil's das Komitee mit der Portabilität mal wieder ein bisschen übertrieben hat.

asfdlol schrieb:

5. Wieso ist von result_type , min() , etc. bei (eigenen) Generatoren gefordert, dass sie Teil der Klasse sind?

Weil traits das ganze unnötig komplex machen würden.

[Fytch]

TyRoXx schrieb:

asfdlol schrieb:

2. Ich habe eine gleichverteilte Engine [...] zu meiner Enttäuschung äusserst schlecht verteilt.

Aha.

Verfälschst du das Zitat absichtlich?

TyRoXx schrieb:

asfdlol schrieb:

3. Wieso ist der Algorithmus KISS / RKISS nicht implementiert? Dieser ist viel schneller / kleiner / besser als der Mersenne Twister und sogar kryptographisch sicher.

Dein Proposal für die Standardisierung ist bestimmt sehr interessant, ich finde das gute Stück aber nirgends.

Was meinst du damit? Ich hab ja nicht gesagt, dass ich sowas machen kann.

TyRoXx schrieb:

asfdlol schrieb:

6. Wieso ist discard() eine Methode?

Weil ein Generator die unter Umständen effizienter implementieren kann, wenn er nicht wirklich etwas generieren muss.

Ja, war zunächst auch mein Gedanke. Bei MSVC's Standardbibliothek ist das jedenfalls nicht der Fall. Und auch wenn es eine effiziente Version gibt, dann lässt sich die auch ohne Probleme im eine freie Funktion implementieren.

camper schrieb:

Amortisiert konstant.

Huch, danke. Kannte ich nicht.

camper schrieb:

Die Implementation von Visual C++ kenne ich nicht, aber bereits ein naiver modulo-basierter Algorithmus hat diese Eigenschaft.

Ich bin mir nicht 100%ig sicher und gebe somit keine Garantie auf Richtigkeit, jedoch hat mich der folgende Code denken lassen, dass die Komplexität theoretisch unbeschränkt ist:

for (; ; )
			{	// repeat until random value is in range
			_Udiff _Val = _Ref() - (_Urng::min)();

			if (_Val <= _Bmask)
				return (_Val);
			}

Wobei _Bmask eine Bitmaske ist, die anhand der Zielmenge der Verteilung gewählt wurde.

cooky451 schrieb:

Könntest du die mal posten?

Natürlich (ist nur eine vereinfachte std::shuffle_order_engine ):

template<unsigned int Range>
class PermutationEngine
{
public:
	typedef unsigned int result_type;

private:
	result_type Permutation[Range];
	std::size_t State;
	void Shuffle()
	{
		std::random_shuffle(std::begin(Permutation), std::end(Permutation));
	}

public:
	PermutationEngine()
		: State(0)
	{
		for(std::size_t i = 0; i < Range; ++i)
		{
			Permutation[i] = i; // evtl. static_cast<result_type>(i)
		}
		Shuffle();
	}

	static /*constexpr*/ result_type min()
	{
		return 0;
	}
	static /*constexpr*/ result_type max()
	{
		return Range - 1;
	}

	result_type operator() ()
	{
		result_type Result = Permutation[State];
		if(++State == Range)
		{
			State = 0;
			Shuffle();
		}
		return Result;
	}
};
template<>
class PermutationEngine<0>;

Das soll auch keine echte Engine sein die man auch wirklich nutzt, sondern dient nur den Testzwecken.

cooky451 schrieb:

Hört sich interessant an, aber habe ich leider wenig zu gefunden bei einer schnellen Suche. Gibt's da was zu lesen?

Das was PRND schon gepostet hat.

cooky451 schrieb:

asfdlol schrieb:

Gibt es einen direkten Weg um den Zustand speichersparend abzuspeichern oder wenigstens auf den internen Zustand zugreifen zu können?

Nein, weil's das Komitee mit der Portabilität mal wieder ein bisschen übertrieben hat.

Schade. Wie macht ihr das denn?

cooky451 schrieb:

Weil traits das ganze unnötig komplex machen würden.

Das stimmt, komplexer wird es ein wenig. Naja, ich bin perfektionistisch und ärgere mich ein bisschen, wenn ich die selben Dinge zwei Mal in der Klasse habe (mit anderem Bezeichner).

[TyRoXx]

asfdlol schrieb:

TyRoXx schrieb:

asfdlol schrieb:

2. Ich habe eine gleichverteilte Engine [...] zu meiner Enttäuschung äusserst schlecht verteilt.

Aha.

Verfälschst du das Zitat absichtlich?

Deine "gleichverteilte Engine" ist falsch. Natürlich liefert uniform_int_distribution damit Müll.

[Fytch]

TyRoXx schrieb:

Deine "gleichverteilte Engine" ist falsch. Natürlich liefert uniform_int_distribution damit Müll.

Und wieso ist sie falsch?

[cooky451]

asfdlol schrieb:

Und auch wenn es eine effiziente Version gibt, dann lässt sich die auch ohne Probleme im eine freie Funktion implementieren.

Eh... nö. Wie kommst du darauf? Als friend vielleicht, aber dass Memberfunktionen hier hübscher als friend gehacke sind sollte wohl klar sein.

asfdlol schrieb:

Das was PRND schon gepostet hat.

Also da habe ich jetzt nichts zur kryptographischen Sicherheit gefunden?

asfdlol schrieb:

Schade. Wie macht ihr das denn?

Es gibt die Möglichkeit den Seed und wie oft man discard()en muss zu speichern. Wenn das zu langsam ist muss man wohl in den sauren Apfel beißen und es selbst implementieren, aber ich meine dann scheint man ja eh recht spezielle Anforderungen an die Performance zu haben.

Ansonsten wegen der Engine, also wenn die die mit <16> instanziiere und eine uniform_int_distribution(0, 32) 50000 benutze kommt da bei mir (VS 2013) folgendes bei raus:

0: 1432
1: 1324
2: 1364
3: 1382
4: 1334
5: 1329
6: 1438
7: 1622
8: 1641
9: 1598
10: 1570
11: 1630
12: 1629
13: 1667
14: 1585
15: 1600
16: 1655
17: 1447
18: 1415
19: 1322
20: 1355
21: 1382
22: 1376
23: 1368
24: 1668
25: 1551
26: 1651
27: 1650
28: 1608
29: 1602
30: 1636
31: 1662
32: 1507

Sind zwar ein paar "Ausschläge" bei die nicht ganz sauber aussehen, aber die würde ich dann mal frech auf das etwas eigenartige Verhalten deiner Engine schieben. (Innerhalb einer Periode kann eine Zahl nur genau ein mal vor kommen.)

[Fytch]

cooky451 schrieb:

asfdlol schrieb:

Und auch wenn es eine effiziente Version gibt, dann lässt sich die auch ohne Probleme im eine freie Funktion implementieren.

Eh... nö. Wie kommst du darauf? Als friend vielleicht, aber dass Memberfunktionen hier hübscher als friend gehacke sind sollte wohl klar sein.

Oder die Engine, für welche dies der Fall ist, bietet eine Methode an, die dann von der entsprechenden Spezialisierung der freien Funktion aufgerufen wird. Ist aber auch egal nun, ich bin das Boilerplate- discard() mit CRTP los geworden.

cooky451 schrieb:

asfdlol schrieb:

Das was PRND schon gepostet hat.

Also da habe ich jetzt nichts zur kryptographischen Sicherheit gefunden?

Okay, ich habe gerade dieses Paper hier gefunden, in welchem steht, dass KISS doch nicht kryptographisch sicher ist. Schade. Nichtsdestotrotz produziert KISS laut dem BigCrush-Test bessere Zufallszahlen wie der Mersenne-Twister.

cooky451 schrieb:

[...]

Oha, deine Ergebnisse sind ja um Welten besser als die meinen. Ich hab meinen Code des Tests leider wieder weggeworfen und weiss die exakten Testparameter nicht mehr... Vielleicht finde ich sie wieder heraus. Vielleicht habe ich aber auch bei der Auswertung gestern Quatsch gemacht, denn meine Ergebnisse sind schon so absonderlich, dass sie kaum glaubwürdig waren / sind. Könnte jedoch wetten, dass die Auswerung gestimmt hat.

[volkard]

asfdlol schrieb:

std::uniform_int_distribution generieren lassen. Diese sind zu meiner Enttäuschung äusserst schlecht verteilt. Seht selbst:

0: 0		 1: 0		 2: 0		 3: 0		 4: 0		 5: 0		 6: 96774		 7: 0		 8: 0		 9: 0
10: 0		11: 0		12: 0		13: 0		14: 0		15: 0		16: 96774		17: 0		18: 0		19: 0
20: 0		21: 0		22: 0		23: 0		24: 0		25: 0		26: 96774		27: 0		28: 0		29: 0
30: 0		31: 0		32: 0		33: 0		34: 0		35: 0		36: 96774		37: 0		38: 0		39: 0
40: 0		41: 0		42: 0		43: 0		44: 0		45: 0		46: 96774		47: 0		48: 0		49: 0
50: 0		51: 0		52: 0		53: 0		54: 0		55: 0		56: 96774		57: 0		58: 0		59: 0
60: 0		61: 0		62: 0		63: 0		64: 0		65: 0		66: 129033		67: 0		68: 0		69: 0
70: 0		71: 0		72: 0		73: 0		74: 0		75: 0		76: 96774		77: 0		78: 0		79: 0
80: 0		81: 0		82: 0		83: 0		84: 0		85: 0		86: 96774		87: 0		88: 0		89: 0
90: 0		91: 0		92: 0		93: 0		94: 0		95: 0		96: 96775		97: 0		98: 0		99: 0

Wieso ist das so?

Haste die std::uniform_int_distribution lange leben lassen oder für jede Zahl eine neue genaut, wie es so oft hier im Form vorgeschlagen wird?

[hustbaer]

Darf die std::uniform_int_distribution denn lügen wenn man dauernt neue Instanzen erzeugt?

[Caligulaminus]

Wieso lügen?
Woher soll denn die nächste Instanz den Zustand ihrer Vorgängerin kennen?

[volkard]

hustbaer schrieb:

Darf die std::uniform_int_distribution denn lügen wenn man dauernt neue Instanzen erzeugt?

So Sachen wie "Produces random integer values i, uniformly distributed on the closed interval [a, b]" habe ich immer nur so verstanden, daß daß die Ausgabefolge eines Objekts auf lange Sicht gleichverteilt ist. Keine Aussage drüber, was kurzfristig passiert.

[hustbaer]

@Caligulaminus
Ich würde mal behaupten dass man std::uniform_int_distribution wunderbar stateless implementieren kann.

Bei anderen Verteilungen mag das schwieriger sein, keine Ahnung.
Wobei ich mir grad schwer tue mir vorzustellen wo eine "stateful" Implementierung Sinn machen würde.

@volkard
Ja klar auf lange Sicht. Die Frage ist nur ob man "stateful" Distributions erlauben sollte.
Vorberechnete Konstanten/Lookup-Tables/... sind klarerweise OK. Mutable State in einer Distribution ... weiss nicht ob das so gut ist.

[Caligulaminus]

hustbaer schrieb:

@Caligulaminus
Ich würde mal behaupten dass man std::uniform_int_distribution wunderbar stateless implementieren kann.

Das denke ich auch, aber erstens ist stateful sicher effizienter und zweitens ist die std::uniform_int_distribution nunmal stateful implementiert (zumindest bei meinem MSVC).

[bits/random.h]

volkard schrieb:

hustbaer schrieb:

Darf die std::uniform_int_distribution denn lügen wenn man dauernt neue Instanzen erzeugt?

So Sachen wie "Produces random integer values i, uniformly distributed on the closed interval [a, b]" habe ich immer nur so verstanden, daß daß die Ausgabefolge eines Objekts auf lange Sicht gleichverteilt ist. Keine Aussage drüber, was kurzfristig passiert.

Die einzigen Member von uniform_int_distribution beim GCC sind min und max, das Ziehen könnte hier theoretisch const sein.

Allerdings ist das nicht bei jeder Distribution so, std::normal_distribution hat einen State.

Die Verteilheit sollte aber auch gewährleistet sein, wenn man jedesmal eine neue uniform_int_distribution erstellt, nur halt vielleicht etwas langsamer.

[cooky451]

Caligulaminus schrieb:

stateful implementiert (zumindest bei meinem MSVC).

Also bei mir nicht wirklich, wenn ich da mal kurz drüber schaue finde ich nur min/max, und wenn ich die distribution jedes mal neu erstelle bekomme ich auch immer noch exakt die selben Ergebnisse.

[Caligulaminus]

cooky451 schrieb:

Also bei mir nicht wirklich

Ich glaube, ich muß mich korrigieren, meine std::uniform_int_distribution scheint doch nicht stateful zu sein.
Morgen muß ich noch mal genauer schauen...

[Fytch]

volkard schrieb:

Haste die std::uniform_int_distribution lange leben lassen oder für jede Zahl eine neue genaut, wie es so oft hier im Form vorgeschlagen wird?

Ich hab eine Distribution für alle Werte genommen. Ehrlich gesagt habe ich nie Diesbezügliches im Forum gelesen.

Also bei meinem Visual C++ 2013 Express ist std::uniform_int_distribution auch zustandslos implementiert.

[seldon]

Mal außen vor, dass der Generator keine vereinfachte std::shuffle_order_engine und natürlich nicht gleichverteilt ist (wie hoch ist die Wahrscheinlichkeit, mit ihm dreimal hintereinander die gleiche Zahl zu ziehen?) und eine uniform_int_distribution keinerlei Verpflichtung hat, damit sinnvoll klarzukommen -- irgendwie sieht mir das Ergebnis so aus, als sei eine PermutationEngine<10> als Generator für eine uniform_int_distribution(0, 100) verwendet worden. Das könnte natürlich nicht gutgehen.

@asfdlol: Zeig doch mal den kompletten Code, der das Verhalten erzeugt.

[hustbaer]

seldon schrieb:

Mal außen vor, dass der Generator keine vereinfachte std::shuffle_order_engine und natürlich nicht gleichverteilt ist (wie hoch ist die Wahrscheinlichkeit, mit ihm dreimal hintereinander die gleiche Zahl zu ziehen?)

Es sind keine guten Zufallszahlen wenn man nicht 3x hintereinander die selbe Zahl ziehen kann. Aber inwiefern soll das die (1 dimensionale) Gleichverteilung stören? Die ist ja gerade perfekt bei dem Generator.

und eine uniform_int_distribution keinerlei Verpflichtung hat, damit sinnvoll klarzukommen -- irgendwie sieht mir das Ergebnis so aus, als sei eine PermutationEngine<10> als Generator für eine uniform_int_distribution(0, 100) verwendet worden. Das könnte natürlich nicht gutgehen.

Keine Ahnung, ist das so?
Was sind denn die Anforderungen die eine Distribution an den übergebenen Generator stellen darf?

[SeppJ]

hustbaer schrieb:

Was sind denn die Anforderungen die eine Distribution an den übergebenen Generator stellen darf?

26.5.1.3 Uniform random number generator requirements

A uniform random number generator g of type G is a function object returning unsigned integer values such
that each value in the range of possible results has (ideally) equal probability of being returned. [ Note: The
degree to which g’s results approximate the ideal is often determined statistically. — end note ]

Die Anforderungen werden hier also tatsächlich erfüllt. Es gibt, wie du schon anmerkst, keinen mathematischen Grund es anders zu verlangen. Die Zufallszahlen sind zwar schlecht (sowohl vor als auch nach dem man sie durch die Verteilungsfunktion gejagt hat), aber ihre Verteilung sollte richtig sein.

P.S.: Die Distributionen verlangen dann auch einen eben solchen uniform random number generator (§ 26.5.1.6, 2f). Nur um das nochmal klar zu stellen, falls es nicht offensichtlich war.

[hustbaer]

Danke

Und was sind die Anforderungen an min/max?