Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung

[Swordfish]

@manni66 Ich glaub' es reicht dann auch wieder.

@EinNutzer0 Tut's org.apache.commons.math3.distribution.NormalDistribution nicht?

[EinNutzer0]

@Swordfish sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

@EinNutzer0 Tut's org.apache.commons.math3.distribution.NormalDistribution nicht?

Das ist eine zusätzliche Lib.

Warum ist @manni66 so unfreundlich? Ich werde hier nichts mehr schreiben, dann kann er sich von mir aus in seinem eigenen Saft suhlen. Irgendwann sollte man doch mal normale Umgangsformen gelernt haben.

[Swordfish]

@EinNutzer0 sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Das ist eine zusätzliche Lib.

deren Code Du Dir ansehen kannst.

[EinNutzer0]

@Swordfish sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

@EinNutzer0 sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Das ist eine zusätzliche Lib.

deren Code Du Dir ansehen kannst.

Ja werde ich machen. Danke.

[yahendrik]

@EinNutzer0 sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Um Performance geht es nicht.

Zack, downvote. Nur warum? Meiner Meinung nach eine völlig legitime Handlungsweise, Probleme erst zu verstehen, bevor man sich über die Performance Gedanken macht.
Ist doch (glücklicherweise?) nicht stackoverflow hier.

[wob]

new Random() in einer Loop hat nicht nur Performanceprobleme. Man hat dann nicht mehr das normalerweise garantierte Verhalten von Random, sondern man erzeugt "irgendwie" immer neue prngs. Der seed soll laut Java-Doku bei jedem Aufruf möglichst anders sein, aber wie genau er erzeugt wird, ist nicht klar definiert. Welches Verhalten haben also die hier generierten Zufallszahlen?

Es ist nun eben einfach nicht sinnvoll, einen prng hier in der Loop immer neu zu erzeugen.

[EinNutzer0]

@wob sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

new Random() in einer Loop hat nicht nur Performanceprobleme. Man hat dann nicht mehr das normalerweise garantierte Verhalten von Random, sondern man erzeugt "irgendwie" immer neue prngs. Der seed soll laut Java-Doku bei jedem Aufruf möglichst anders sein, aber wie genau er erzeugt wird, ist nicht klar definiert. Welches Verhalten haben also die hier generierten Zufallszahlen?

Es ist nun eben einfach nicht sinnvoll, einen prng hier in der Loop immer neu zu erzeugen.

Die Entropie und Güte der Zufallswerte wird dadurch nicht beeinflusst (sprich: Die Semantik bleibt dieselbe). Aber hier noch mal neu:

    /**
     * @param from lower bound
     * @param to   upper bound
     * @param a    factor between 0.0 and 1.0
     * @return     a random double value in bounds
     */
    @SuppressWarnings("unused")
    public static double getRandomDouble(double from, double to, double a) {
        Random random = new Random();
        double g;
        do {
            g = (random.nextGaussian() + 1.0) / 2.0;
        } while (g < 0 || g > 1);
        if (g < 0.5) {
            g += (0.5 - g) * a * a;
        } else if (g > 0.5) {
            g -= (g - 0.5) * a * a;
        }
        return g * (to - from) + from;
    }

Und ich hab mich auch etwas informiert, die new BetaDistribution(2.0, 2.0).sample(); gibt das gewünschte Ergebnis zurück.

Link

[wob]

@EinNutzer0 sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Die Entropie und Güte der Zufallswerte wird dadurch nicht beeinflusst (sprich: Die Semantik bleibt dieselbe).

Beweis durch Behauptung?

[EinNutzer0]

@wob sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

@EinNutzer0 sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Die Entropie und Güte der Zufallswerte wird dadurch nicht beeinflusst (sprich: Die Semantik bleibt dieselbe).

Beweis durch Behauptung?

Random wählt den seed unter anderem anhand der Nanosystemzeit. Dadurch ist eine ausreichende seed-Entropie sichergestellt. Der Zustand des Systems kann praktisch auch nicht so genau beobachtet werden, dass der seed reproduzierbar wäre (Werner Heisenbergs Unschärferelation).

Es könnte lediglich (theoretisch) passieren, dass zwei getRandomDouble-Aufrufe zeitlich so nah beieinander liegen, dass sie denselben Wert berechnen und zurückgeben... Aber dann hilft eine lokale Variable (Zeile 9) auch nicht... dann braucht man eine Objekt- oder Klassenvariable.

[SeppJ]

manni66 hat Recht.

[EinNutzer0]

Der Beweis geht quasi direkt aus dem Kommentar/Source hervor:

    /**
     * Creates a new random number generator. This constructor sets
     * the seed of the random number generator to a value very likely
     * to be distinct from any other invocation of this constructor.
     */
    public Random() {
        this(seedUniquifier() ^ System.nanoTime());
    }

    private static long seedUniquifier() {
        // L'Ecuyer, "Tables of Linear Congruential Generators of
        // Different Sizes and Good Lattice Structure", 1999
        for (;;) {
            long current = seedUniquifier.get();
            long next = current * 1181783497276652981L;
            if (seedUniquifier.compareAndSet(current, next))
                return next;
        }
    }

http://www.java2s.com/example/java-src/pkg/java/util/random-fd044.html

@SeppJ sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

manni66 hat Recht.

Womit hat er recht? Wie man sich danebenbenimmt?

[wob]

@EinNutzer0 sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Random wählt den seed unter anderem anhand der Nanosystemzeit. Dadurch ist eine ausreichende seed-Entropie sichergestellt.

Ähm. Vielleicht einmalig. Aber sicher nicht beim Wiederholen.

Der Zustand des Systems kann praktisch auch nicht so genau beobachtet werden, dass der seed reproduzierbar wäre (Werner Heisenbergs Unschärferelation).

Ich sehe einen im Grab rotierenden Heisenberg.

[EinNutzer0]

@wob sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Ich sehe einen im Grab rotierenden Heisenberg.

Es könnte lediglich (theoretisch) passieren, dass zwei getRandomDouble-Aufrufe zeitlich so nah beieinander liegen, dass sie denselben Wert berechnen und zurückgeben...

Das war irgendwie falsch formuliert... Das kann eigentlich gar nicht passieren.

Dennoch hat, wo das new Random() nun genau vorkommt, gar nichts mit meiner Frage zu tun!

[Schlangenmensch]

@EinNutzer0 Du willst normalverteilte Zufallsvariablen haben, richtig? Warum sollten die ersten Werte der Zufallsreihen verschieden initialisierter Zufallsgeneratoren normalverteilt sein? Garantiert ist das für die Werte eines Zufallsgenerators.

[wob]

@EinNutzer0 sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Dennoch hat, wo das new Random() nun genau vorkommt, gar nichts mit meiner Frage zu tun!

Eine deiner Fragen war (Zitat) "Oder gibts vielleicht etwas Besseres als new Random().nextGaussian()?" (Zitat Ende). Ja, gibt es. Trennen von "new Random()" und dem "nextGaussian()". Aber für mich ist jetzt Ende.

[EinNutzer0]

@Schlangenmensch : #nextGaussian() ist eine Methode von Random basierend auf dessen seed.

[EinNutzer0]

@wob sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

@EinNutzer0 sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Dennoch hat, wo das new Random() nun genau vorkommt, gar nichts mit meiner Frage zu tun!

Eine deiner Fragen war (Zitat) "Oder gibts vielleicht etwas Besseres als new Random().nextGaussian()?" (Zitat Ende). Ja, gibt es. Trennen von "new Random()" und dem "nextGaussian()". Aber für mich ist jetzt Ende.

Etwas Besseres nur in Hinblick auf die Methode nextGaussian() meinte ich...

Und die erstere Frage bezog sich auf die Vermeidung der do-while-Schleife.

Du musst nicht weglaufen, nur, weil es etwas unbequem wird.

[Quiche Lorraine]

@Schlangenmensch sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Warum sollten die ersten Werte der Zufallsreihen verschieden initialisierter Zufallsgeneratoren normalverteilt sein?

Das frage ich mich auch schon die ganze Zeit. Aber es scheint mir noch ein wenig schlimmer denn der TE schneidet ja alles über +- Sigma (siehe Standardabweichung) weg. Das heißt in 30% der Fälle wird einfach nochmals gewürfelt bis der Wert im +- Sigma Raster liegt. Und dadurch ändert sich die Verteilung.

Das was da rauskommt dürfte ähnlich der Normalverteilung sein. Sicher bin ich da nicht.

[Schlangenmensch]

@EinNutzer0 sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

@Schlangenmensch : #nextGaussian() ist eine Methode von Random basierend auf dessen seed.

Und? Du hast meine Antwort nicht verstanden, denke ich.
In deinem ursprünglichen Code hast du ja eben nicht mit nextGaussian auf einen Zufallsgenerator gearbeitet, sondern nextGaussian immer nur einmal auf einen neuen Zufallsgenerator aufgerufen. Und das ist eben nicht nur aus Performance Gründen problematisch, was dir ja egal war, sondern auch aus Sicht des Zufalls.

[EinNutzer0]

@Schlangenmensch sagte in Zufälligen nextGaussian-Wert zwischen zwei Grenzen mit einer Häufung:

Und?

Mir scheint, du hast Random noch nicht richtig verstanden. Solange die nextGaussian()-Werte auf unterschiedlichen seeds beruhen, werden auch "gute" Zufallszahlen generiert. Und das tun sie ja.

Um die Performance kann man sich später kümmern. Kein Grund, an meiner Intelligenz zu zweifeln...

Wer paranoid ist, nimmt eben SecureRandom.