Ho chiamato una classe QuickRandome il suo compito è produrre rapidamente numeri casuali. È davvero semplice: prendi il vecchio valore, moltiplica per a doublee prendi la parte decimale.

Ecco la mia QuickRandomclasse nella sua interezza:

public class QuickRandom {
    private double prevNum;
    private double magicNumber;

    public QuickRandom(double seed1, double seed2) {
        if (seed1 >= 1 || seed1 < 0) throw new IllegalArgumentException("Seed 1 must be >= 0 and < 1, not " + seed1);
        prevNum = seed1;
        if (seed2 <= 1 || seed2 > 10) throw new IllegalArgumentException("Seed 2 must be > 1 and <= 10, not " + seed2);
        magicNumber = seed2;
    }

    public QuickRandom() {
        this(Math.random(), Math.random() * 10);
    }

    public double random() {
        return prevNum = (prevNum*magicNumber)%1;
    }

}

Ed ecco il codice che ho scritto per testarlo:

public static void main(String[] args) {
        QuickRandom qr = new QuickRandom();

        /*for (int i = 0; i < 20; i ++) {
            System.out.println(qr.random());
        }*/

        //Warm up
        for (int i = 0; i < 10000000; i ++) {
            Math.random();
            qr.random();
            System.nanoTime();
        }

        long oldTime;

        oldTime = System.nanoTime();
        for (int i = 0; i < 100000000; i ++) {
            Math.random();
        }
        System.out.println(System.nanoTime() - oldTime);

        oldTime = System.nanoTime();
        for (int i = 0; i < 100000000; i ++) {
            qr.random();
        }
        System.out.println(System.nanoTime() - oldTime);
}

È un algoritmo molto semplice che moltiplica semplicemente il doppio precedente per un doppio "numero magico". L'ho messo insieme abbastanza rapidamente, quindi probabilmente potrei renderlo migliore, ma stranamente, sembra funzionare bene.

Questo è l'output di esempio delle righe commentate nel mainmetodo:

0.612201846732229
0.5823974655091941
0.31062451498865684
0.8324473610354004
0.5907187526770246
0.38650264675748947
0.5243464344127049
0.7812828761272188
0.12417247811074805
0.1322738256858378
0.20614642573072284
0.8797579436677381
0.022122999476108518
0.2017298328387873
0.8394849894162446
0.6548917685640614
0.971667953190428
0.8602096647696964
0.8438709031160894
0.694884972852229

Hm. Abbastanza casuale. In effetti, ciò funzionerebbe per un generatore di numeri casuali in un gioco.

Ecco un esempio di output della parte non commentata:

5456313909
1427223941

Wow! Esegue quasi 4 volte più velocemente di Math.random.

Ricordo di aver letto da qualche parte ciò che Math.randomusava System.nanoTime()e tonnellate di moduli folli e roba da divisione. È davvero necessario? Il mio algoritmo si comporta molto più velocemente e sembra abbastanza casuale.

Ho due domande:

• Il mio algoritmo è "abbastanza buono" (per esempio, un gioco in cui i numeri davvero casuali non sono troppo importanti)?
• Perché fa Math.randomcosì tanto quando sembra solo una semplice moltiplicazione e il taglio del decimale sarà sufficiente?

L' QuickRandomimplementazione non ha realmente una distribuzione uniforme. Le frequenze sono generalmente più alte ai valori più bassi mentre Math.random()ha una distribuzione più uniforme. Ecco un SSCCE che dimostra che:

package com.stackoverflow.q14491966;

import java.util.Arrays;

public class Test {

    public static void main(String[] args) throws Exception {
        QuickRandom qr = new QuickRandom();
        int[] frequencies = new int[10];
        for (int i = 0; i < 100000; i++) {
            frequencies[(int) (qr.random() * 10)]++;
        }
        printDistribution("QR", frequencies);

        frequencies = new int[10];
        for (int i = 0; i < 100000; i++) {
            frequencies[(int) (Math.random() * 10)]++;
        }
        printDistribution("MR", frequencies);
    }

    public static void printDistribution(String name, int[] frequencies) {
        System.out.printf("%n%s distribution |8000     |9000     |10000    |11000    |12000%n", name);
        for (int i = 0; i < 10; i++) {
            char[] bar = "                                                  ".toCharArray(); // 50 chars.
            Arrays.fill(bar, 0, Math.max(0, Math.min(50, frequencies[i] / 100 - 80)), '#');
            System.out.printf("0.%dxxx: %6d  :%s%n", i, frequencies[i], new String(bar));
        }
    }

}

Il risultato medio è simile al seguente:

QR distribution |8000     |9000     |10000    |11000    |12000
0.0xxx:  11376  :#################################                 
0.1xxx:  11178  :###############################                   
0.2xxx:  11312  :#################################                 
0.3xxx:  10809  :############################                      
0.4xxx:  10242  :######################                            
0.5xxx:   8860  :########                                          
0.6xxx:   9004  :##########                                        
0.7xxx:   8987  :#########                                         
0.8xxx:   9075  :##########                                        
0.9xxx:   9157  :###########                                       

MR distribution |8000     |9000     |10000    |11000    |12000
0.0xxx:  10097  :####################                              
0.1xxx:   9901  :###################                               
0.2xxx:  10018  :####################                              
0.3xxx:   9956  :###################                               
0.4xxx:   9974  :###################                               
0.5xxx:  10007  :####################                              
0.6xxx:  10136  :#####################                             
0.7xxx:   9937  :###################                               
0.8xxx:  10029  :####################                              
0.9xxx:   9945  :###################    

Se ripeti il ​​test, vedrai che la distribuzione QR varia notevolmente, a seconda dei seed iniziali, mentre la distribuzione MR è stabile. A volte raggiunge la distribuzione uniforme desiderata, ma più spesso non lo fa. Ecco uno degli esempi più estremi, è persino oltre i confini del grafico:

QR distribution |8000     |9000     |10000    |11000    |12000
0.0xxx:  41788  :##################################################
0.1xxx:  17495  :##################################################
0.2xxx:  10285  :######################                            
0.3xxx:   7273  :                                                  
0.4xxx:   5643  :                                                  
0.5xxx:   4608  :                                                  
0.6xxx:   3907  :                                                  
0.7xxx:   3350  :                                                  
0.8xxx:   2999  :                                                  
0.9xxx:   2652  :                                                  

Quello che stai descrivendo è un tipo di generatore casuale chiamato generatore lineare congruenziale . Il generatore funziona come segue:

• Inizia con un valore seed e un moltiplicatore.
• Per generare un numero casuale:
  • Moltiplica il seme per il moltiplicatore.
  • Impostare il seme uguale a questo valore.
  • Restituisce questo valore.

Questo generatore ha molte belle proprietà, ma ha problemi significativi come una buona fonte casuale. L'articolo di Wikipedia collegato sopra descrive alcuni dei punti di forza e di debolezza. In breve, se hai bisogno di buoni valori casuali, probabilmente questo non è un ottimo approccio.

Spero che questo ti aiuti!

La tua funzione di numero casuale è scadente, poiché ha uno stato interno troppo scarso: il numero emesso dalla funzione in un determinato passaggio dipende interamente dal numero precedente. Ad esempio, se assumiamo che magicNumbersia 2 (a titolo di esempio), la sequenza:

0.10 -> 0.20

è fortemente riflesso da sequenze simili:

0.09 -> 0.18
0.11 -> 0.22

In molti casi, questo genererà evidenti correlazioni nel tuo gioco - ad esempio, se fai chiamate successive alla tua funzione per generare coordinate X e Y per gli oggetti, gli oggetti formeranno chiari schemi diagonali.

A meno che tu non abbia buone ragioni per credere che il generatore di numeri casuali stia rallentando la tua applicazione (e questo è MOLTO improbabile), non ci sono buoni motivi per provare a scrivere la tua.

Il vero problema con questo è che il suo istogramma di output dipende in gran parte dal seme iniziale - per la maggior parte del tempo finirà con un output quasi uniforme, ma per la maggior parte del tempo avrà un output chiaramente non uniforme.

Ispirato da questo articolo su quanto sia cattiva la rand()funzione di php , ho realizzato alcune immagini a matrice casuale usando QuickRandome System.Random. Questa corsa mostra come a volte il seme possa avere un effetto negativo (in questo caso favorendo numeri più bassi) dove as System.Randomè piuttosto uniforme.

QuickRandom

System.Random

Persino peggio

Se inizializziamo QuickRandomquando new QuickRandom(0.01, 1.03)otteniamo questa immagine:

Il codice

using System;
using System.Drawing;
using System.Drawing.Imaging;

namespace QuickRandomTest
{
    public class QuickRandom
    {
        private double prevNum;
        private readonly double magicNumber;

        private static readonly Random rand = new Random();

        public QuickRandom(double seed1, double seed2)
        {
            if (seed1 >= 1 || seed1 < 0) throw new ArgumentException("Seed 1 must be >= 0 and < 1, not " + seed1);
            prevNum = seed1;
            if (seed2 <= 1 || seed2 > 10) throw new ArgumentException("Seed 2 must be > 1 and <= 10, not " + seed2);
            magicNumber = seed2;
        }

        public QuickRandom()
            : this(rand.NextDouble(), rand.NextDouble() * 10)
        {
        }

        public double Random()
        {
            return prevNum = (prevNum * magicNumber) % 1;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var rand = new Random();
            var qrand = new QuickRandom();
            int w = 600;
            int h = 600;
            CreateMatrix(w, h, rand.NextDouble).Save("System.Random.png", ImageFormat.Png);
            CreateMatrix(w, h, qrand.Random).Save("QuickRandom.png", ImageFormat.Png);
        }

        private static Image CreateMatrix(int width, int height, Func<double> f)
        {
            var bitmap = new Bitmap(width, height);
            for (int y = 0; y < height; y++) {
                for (int x = 0; x < width; x++) {
                    var c = (int) (f()*255);
                    bitmap.SetPixel(x, y, Color.FromArgb(c,c,c));
                }
            }

            return bitmap;
        }
    }
}

Un problema con il tuo generatore di numeri casuali è che non esiste uno "stato nascosto" - se so quale numero casuale hai restituito nell'ultima chiamata, conosco ogni singolo numero casuale che invierai fino alla fine dei tempi, poiché ce n'è solo uno possibile prossimo risultato, e così via e così via.

Un'altra cosa da considerare è il "periodo" del generatore di numeri casuali. Ovviamente con una dimensione a stati finiti, uguale alla porzione di mantissa di un doppio, sarà in grado di restituire al massimo 2 ^ 52 valori prima di eseguire il loop. Ma è nel migliore dei casi: puoi provare che non ci sono anelli del periodo 1, 2, 3, 4 ...? Se ci sono, il tuo RNG avrà un comportamento terribile e degenerato in quei casi.

Inoltre, la generazione di numeri casuali avrà una distribuzione uniforme per tutti i punti di partenza? In caso contrario, il tuo RNG sarà distorto, o peggio, distorto in diversi modi a seconda del seme iniziale.

Se riesci a rispondere a tutte queste domande, fantastico. Se non puoi, allora sai perché la maggior parte delle persone non reinventa la ruota e usa un generatore di numeri casuali comprovato;)

(A proposito, un buon adagio è: il codice più veloce è il codice che non viene eseguito. Potresti rendere il più veloce casuale () al mondo, ma non va bene se non è molto casuale)

Un test comune che ho sempre fatto durante lo sviluppo di PRNG era quello di:

1. Converti l'output in valori char
2. Scrivi il valore dei caratteri in un file
3. Comprimi file

Questo mi ha permesso di scorrere rapidamente idee che erano PRNG "abbastanza buone" per sequenze da circa 1 a 20 megabyte. Ha anche fornito una migliore immagine dall'alto verso il basso rispetto al solo ispezionarlo a occhio, poiché qualsiasi PRNG "abbastanza buono" con mezza parola di stato potrebbe rapidamente superare la capacità dei tuoi occhi di vedere il punto del ciclo.

Se fossi davvero esigente, potrei prendere i buoni algoritmi ed eseguire i test DIEHARD / NIST su di essi, per avere più informazioni, quindi tornare indietro e modificare un po 'di più.

Il vantaggio del test di compressione, al contrario di un'analisi di frequenza, è che, banalmente, è facile costruire una buona distribuzione: è sufficiente emettere un blocco di lunghezza 256 contenente tutti i caratteri con valori compresi tra 0 e 255 e farlo 100.000 volte. Ma questa sequenza ha un ciclo di lunghezza 256.

Una distribuzione distorta, anche con un piccolo margine, dovrebbe essere rilevata da un algoritmo di compressione, in particolare se gli dai abbastanza (diciamo 1 megabyte) della sequenza con cui lavorare. Se alcuni caratteri, o bigrammi o n-grammi si verificano più frequentemente, un algoritmo di compressione può codificare questa inclinazione di distribuzione in codici che favoriscono le ricorrenze frequenti con parole in codice più brevi e si ottiene un delta di compressione.

Poiché la maggior parte degli algoritmi di compressione sono veloci e non richiedono alcuna implementazione (poiché i sistemi operativi li hanno solo in giro), il test di compressione è molto utile per classificare rapidamente il passaggio / fallimento per un PRNG che potresti sviluppare.

Buona fortuna con i tuoi esperimenti!

Oh, ho eseguito questo test sull'Rng che hai sopra, usando la seguente piccola mod del tuo codice:

import java.io.*;

public class QuickRandom {
    private double prevNum;
    private double magicNumber;

    public QuickRandom(double seed1, double seed2) {
        if (seed1 >= 1 || seed1 < 0) throw new IllegalArgumentException("Seed 1 must be >= 0 and < 1, not " + seed1);
        prevNum = seed1;
        if (seed2 <= 1 || seed2 > 10) throw new IllegalArgumentException("Seed 2 must be > 1 and <= 10, not " + seed2);
        magicNumber = seed2;
    }

    public QuickRandom() {
        this(Math.random(), Math.random() * 10);
    }

    public double random() {
        return prevNum = (prevNum*magicNumber)%1;
    }

    public static void main(String[] args) throws Exception {
        QuickRandom qr = new QuickRandom();
        FileOutputStream fout = new FileOutputStream("qr20M.bin");

        for (int i = 0; i < 20000000; i ++) {
            fout.write((char)(qr.random()*256));
        }
    }
}

I risultati furono:

Cris-Mac-Book-2:rt cris$ zip -9 qr20M.zip qr20M.bin2
adding: qr20M.bin2 (deflated 16%)
Cris-Mac-Book-2:rt cris$ ls -al
total 104400
drwxr-xr-x   8 cris  staff       272 Jan 25 05:09 .
drwxr-xr-x+ 48 cris  staff      1632 Jan 25 05:04 ..
-rw-r--r--   1 cris  staff      1243 Jan 25 04:54 QuickRandom.class
-rw-r--r--   1 cris  staff       883 Jan 25 05:04 QuickRandom.java
-rw-r--r--   1 cris  staff  16717260 Jan 25 04:55 qr20M.bin.gz
-rw-r--r--   1 cris  staff  20000000 Jan 25 05:07 qr20M.bin2
-rw-r--r--   1 cris  staff  16717402 Jan 25 05:09 qr20M.zip

Considererei un PRNG buono se il file di output non potesse essere compresso affatto. Ad essere sincero, non pensavo che il tuo PRNG avrebbe funzionato così bene, solo il 16% su ~ 20 Meg è impressionante per una costruzione così semplice. Ma lo considero ancora un fallimento.

Il generatore casuale più veloce che potresti implementare è questo:

XD, scherzi a parte, oltre a tutto quanto detto qui, vorrei contribuire citando che testare sequenze casuali "è un compito difficile" [1], e ci sono diversi test che controllano determinate proprietà di numeri pseudo-casuali, puoi trovare un molti qui: http://www.random.org/analysis/#2005

Un modo semplice per valutare la "qualità" del generatore casuale è il vecchio test Chi Square.

static double chisquare(int numberCount, int maxRandomNumber) {
    long[] f = new long[maxRandomNumber];
    for (long i = 0; i < numberCount; i++) {
        f[randomint(maxRandomNumber)]++;
    }

    long t = 0;
    for (int i = 0; i < maxRandomNumber; i++) {
        t += f[i] * f[i];
    }
    return (((double) maxRandomNumber * t) / numberCount) - (double) (numberCount);
}

Citando [1]

L'idea del test χ² è di verificare se i numeri prodotti sono distribuiti ragionevolmente. Se generiamo N numeri positivi inferiori a r , allora ci aspetteremmo di ottenere N / r numeri di ciascun valore. Ma --- e questa è l'essenza della questione --- le frequenze di occorrenza di tutti i valori non dovrebbero essere esattamente le stesse: non sarebbe casuale!

Calcoliamo semplicemente la somma dei quadrati delle frequenze di occorrenza di ciascun valore, ridimensionata in base alla frequenza prevista e quindi sottrarre la dimensione della sequenza. Questo numero, la "statistica χ²", può essere espresso matematicamente come

Se la statistica χ² è vicina a r , i numeri sono casuali; se è troppo lontano, allora non lo sono. Le nozioni di "vicino" e "molto lontano" possono essere definite più precisamente: esistono tabelle che dicono esattamente come correlare la statistica alle proprietà delle sequenze casuali. Per il semplice test che stiamo eseguendo, la statistica dovrebbe essere entro 2√r

Utilizzando questa teoria e il seguente codice:

abstract class RandomFunction {
    public abstract int randomint(int range); 
}

public class test {
    static QuickRandom qr = new QuickRandom();

    static double chisquare(int numberCount, int maxRandomNumber, RandomFunction function) {
        long[] f = new long[maxRandomNumber];
        for (long i = 0; i < numberCount; i++) {
            f[function.randomint(maxRandomNumber)]++;
        }

        long t = 0;
        for (int i = 0; i < maxRandomNumber; i++) {
            t += f[i] * f[i];
        }
        return (((double) maxRandomNumber * t) / numberCount) - (double) (numberCount);
    }

    public static void main(String[] args) {
        final int ITERATION_COUNT = 1000;
        final int N = 5000000;
        final int R = 100000;

        double total = 0.0;
        RandomFunction qrRandomInt = new RandomFunction() {
            @Override
            public int randomint(int range) {
                return (int) (qr.random() * range);
            }
        }; 
        for (int i = 0; i < ITERATION_COUNT; i++) {
            total += chisquare(N, R, qrRandomInt);
        }
        System.out.printf("Ave Chi2 for QR: %f \n", total / ITERATION_COUNT);        

        total = 0.0;
        RandomFunction mathRandomInt = new RandomFunction() {
            @Override
            public int randomint(int range) {
                return (int) (Math.random() * range);
            }
        };         
        for (int i = 0; i < ITERATION_COUNT; i++) {
            total += chisquare(N, R, mathRandomInt);
        }
        System.out.printf("Ave Chi2 for Math.random: %f \n", total / ITERATION_COUNT);
    }
}

Ho ottenuto il seguente risultato:

Ave Chi2 for QR: 108965,078640
Ave Chi2 for Math.random: 99988,629040

Che, per QuickRandom, è lontano da r (al di fuori di r ± 2 * sqrt(r))

Detto questo, QuickRandom potrebbe essere veloce ma (come affermato in altre risposte) non è buono come generatore di numeri casuali

[1] SEDGEWICK ROBERT, Algorithms in C , Addinson Wesley Publishing Company, 1990, pagine da 516 a 518

Ho messo insieme un rapido modello del tuo algoritmo in JavaScript per valutare i risultati. Genera 100.000 numeri interi casuali da 0 a 99 e tiene traccia dell'istanza di ciascun numero intero.

La prima cosa che noto è che è più probabile che tu ottenga un numero basso rispetto a un numero alto. Lo vedi di più quando seed1è alto e seed2basso. In un paio di casi, ho ricevuto solo 3 numeri.

Nella migliore delle ipotesi, il tuo algoritmo necessita di alcuni perfezionamenti.

Se la Math.Random()funzione chiama il sistema operativo per ottenere l'ora del giorno, non è possibile confrontarla con la propria funzione. La tua funzione è un PRNG, mentre quella funzione è alla ricerca di numeri casuali reali. Mele e arance

Il tuo PRNG può essere veloce, ma non ha abbastanza informazioni sullo stato per raggiungere un lungo periodo prima che si ripeta (e la sua logica non è abbastanza sofisticata da raggiungere anche i periodi possibili con tante informazioni sullo stato).

Il periodo è la lunghezza della sequenza prima che il PRNG inizi a ripetersi. Ciò accade non appena la macchina PRNG effettua una transizione di stato verso uno stato identico a uno stato passato. Da lì, ripeterà le transizioni iniziate in quello stato. Un altro problema con i PRNG può essere un basso numero di sequenze uniche, nonché la convergenza degenerata su una sequenza particolare che si ripete. Ci possono essere anche modelli indesiderati. Ad esempio, supponiamo che un PRNG sembri abbastanza casuale quando i numeri sono stampati in decimali, ma un'ispezione dei valori in binario mostra che il bit 4 commuta semplicemente tra 0 e 1 su ogni chiamata. Oops!

Dai un'occhiata a Mersenne Twister e ad altri algoritmi. Esistono modi per trovare un equilibrio tra la durata del periodo e i cicli della CPU. Un approccio di base (utilizzato nel Twister di Mersenne) è quello di spostarsi nel vettore di stato. Vale a dire, quando viene generato un numero, non si basa sull'intero stato, ma solo su alcune parole della matrice di stato soggette ad alcune operazioni a bit. Ma ad ogni passo, l'algoritmo si sposta anche nell'array, mescolando i contenuti un po 'alla volta.

Ci sono molti, molti generatori di numeri pseudo casuali là fuori. Ad esempio il ranarray di Knuth , il tornado di Mersenne o i generatori LFSR. I monumentali "algoritmi seminumerici" di Knuth analizzano l'area e propongono alcuni generatori congruenziali lineari (semplici da implementare, veloci).

Ma ti suggerirei di attenersi a java.util.Randomo Math.random, sono veloci e almeno OK per un uso occasionale (ad esempio, giochi e simili). Se sei solo paranoico sulla distribuzione (alcuni programmi Monte Carlo o un algoritmo genetico), controlla la loro implementazione (la fonte è disponibile da qualche parte) e seminali con un numero davvero casuale, dal tuo sistema operativo o da random.org . Se questo è necessario per alcune applicazioni in cui la sicurezza è fondamentale, dovrai scavare. E come in quel caso non dovresti credere a quello che un quadrato colorato con i pezzi mancanti spunta qui, sto zitto ora.

È molto improbabile che le prestazioni di generazione di numeri casuali rappresentino un problema per qualsiasi caso d'uso che si è presentato a meno che non si acceda a una singola Randomistanza da più thread (perché lo Randomè synchronized).

Tuttavia, se è davvero così e hai bisogno di molti numeri casuali in fretta, la tua soluzione è troppo inaffidabile. A volte dà buoni risultati, a volte dà risultati orribili (in base alle impostazioni iniziali).

Se vuoi gli stessi numeri che la Randomclasse ti dà, solo più velocemente, potresti sbarazzarti della sincronizzazione lì dentro:

public class QuickRandom {

    private long seed;

    private static final long MULTIPLIER = 0x5DEECE66DL;
    private static final long ADDEND = 0xBL;
    private static final long MASK = (1L << 48) - 1;

    public QuickRandom() {
        this((8682522807148012L * 181783497276652981L) ^ System.nanoTime());
    }

    public QuickRandom(long seed) {
        this.seed = (seed ^ MULTIPLIER) & MASK;
    }

    public double nextDouble() {
        return (((long)(next(26)) << 27) + next(27)) / (double)(1L << 53);
    }

    private int next(int bits) {
        seed = (seed * MULTIPLIER + ADDEND) & MASK;
        return (int)(seed >>> (48 - bits));
    }

}

Ho semplicemente preso il java.util.Randomcodice e rimosso la sincronizzazione che risulta in prestazioni doppie rispetto all'originale sul mio Oracle HotSpot JVM 7u9. È ancora più lento del tuo QuickRandom, ma dà risultati molto più coerenti. Per essere precisi, per gli stessi seedvalori e le applicazioni a thread singolo, fornisce gli stessi numeri pseudo-casuali della Randomclasse originale .

_{Questo codice si basa sull'attuale java.util.RandomOpenJDK 7u che è concesso in licenza sotto GNU GPL v2 .}

MODIFICA 10 mesi dopo:

Ho appena scoperto che non è nemmeno necessario utilizzare il mio codice sopra per ottenere Randomun'istanza non sincronizzata . Ce n'è anche uno nel JDK!

Guarda la ThreadLocalRandomclasse di Java 7 . Il codice al suo interno è quasi identico al mio codice sopra. La classe è semplicemente una Randomversione isolata dal thread locale adatta per generare rapidamente numeri casuali. L'unico aspetto negativo che mi viene in mente è che non è possibile impostarlo seedmanualmente.

Esempio di utilizzo:

Random random = ThreadLocalRandom.current();

'Casuale' è molto più che ottenere numeri .... quello che hai è pseudo-casuale

Se lo pseudo-casuale è abbastanza buono per i tuoi scopi, allora sicuramente è molto più veloce (e XOR + Bitshift sarà più veloce di quello che hai)

Rolf

Modificare:

OK, dopo essere stato troppo affrettato in questa risposta, lasciami rispondere al vero motivo per cui il tuo codice è più veloce:

Da JavaDoc per Math.Random ()

Questo metodo è correttamente sincronizzato per consentire l'uso corretto di più di un thread. Tuttavia, se molti thread devono generare numeri pseudocasuali a una velocità elevata, è possibile ridurre la contesa per ogni thread di avere il proprio generatore di numeri pseudocasuali.

Questo è probabilmente il motivo per cui il tuo codice è più veloce.

java.util.Random non è molto diverso, un LCG di base descritto da Knuth. Tuttavia ha 2 principali vantaggi / differenze:

• thread-safe: ogni aggiornamento è un CAS più costoso di una semplice scrittura e necessita di un ramo (anche se previsto con thread singolo perfetto). A seconda della CPU potrebbe esserci una differenza significativa.
• stato interno non divulgato - questo è molto importante per qualsiasi cosa non banale. Desideri che i numeri casuali non siano prevedibili.

Di seguito è la routine principale che genera numeri interi "casuali" in java.util.Random.

  protected int next(int bits) {
        long oldseed, nextseed;
        AtomicLong seed = this.seed;
        do {
          oldseed = seed.get();
          nextseed = (oldseed * multiplier + addend) & mask;
        } while (!seed.compareAndSet(oldseed, nextseed));
        return (int)(nextseed >>> (48 - bits));
    }

Se si rimuove AtomicLong e lo stato non divulgato (ovvero utilizzando tutti i bit di long ), si otterrebbero maggiori prestazioni rispetto alla doppia moltiplicazione / modulo.

Ultima nota: Math.randomnon dovrebbe essere usato per altro che semplici test, è soggetto a contese e se hai anche un paio di thread che lo chiamano contemporaneamente le prestazioni diminuiscono. Una sua caratteristica storica poco nota è l'introduzione di CAS in Java - per battere un famigerato benchmark (prima da IBM via intrinsics e poi Sun fatto "CAS da Java")

Questa è la funzione casuale che utilizzo per i miei giochi. È abbastanza veloce e ha una buona (abbastanza) distribuzione.

public class FastRandom {

    public static int randSeed;

      public static final int random()
      {
        // this makes a 'nod' to being potentially called from multiple threads
        int seed = randSeed;

        seed    *= 1103515245;
        seed    += 12345;
        randSeed = seed;
        return seed;
      }

      public static final int random(int range)
      {
        return ((random()>>>15) * range) >>> 17;
      }

      public static final boolean randomBoolean()
      {
         return random() > 0;
      }

       public static final float randomFloat()
       {
         return (random()>>>8) * (1.f/(1<<24));
       }

       public static final double randomDouble() {
           return (random()>>>8) * (1.0/(1<<24));
       }
}