Quel est l'avantage d'ensemencer un générateur de nombres aléatoires avec uniquement des nombres premiers ?

Question

Alors que je réalisais quelques expériences en Java, mon chef de projet m'a rappelé qu'il fallait ensemencer chaque itération de l'expérience avec un nombre différent. Il m'a également conseillé d'utiliser des nombres premiers pour les valeurs d'amorçage. Cela m'a fait réfléchir : pourquoi des nombres premiers ? Pourquoi pas n'importe quel autre nombre comme valeur de départ ? Et pourquoi le nombre premier doit-il être suffisamment grand ? Avez-vous des idées ? Je lui aurais bien posé la question moi-même, mais il est 4 heures du matin ici, tout le monde dort, je viens de me souvenir de cette question et je brûle de connaître la réponse (je suis sûr que vous connaissez ce sentiment).

Ce serait bien si vous pouviez fournir quelques références, je suis très intéressé par les mathématiques/concepts derrière tout cela !

EDIT :

J'utilise java.util.Random.

POURSUIVRE L'ÉDITION :

Mon professeur vient d'un milieu C, mais j'utilise Java. Je ne sais pas si ça aide. Il semble que l'utilisation des nombres premiers soit son idiosyncrasie, mais je pense que nous avons trouvé des réponses intéressantes sur la génération de nombres aléatoires. Merci à tous pour vos efforts !

Answer 1

Un simple coup d'œil à la mise en œuvre vous montrerait qu'il ne peut avoir aucune raison pour cette affirmation. Pourquoi ? Parce que c'est à ça que ressemble la fonction de graine de set :

synchronized public void setSeed(long seed) {
    seed = (seed ^ multiplier) & mask;
    this.seed.set(seed);
    haveNextNextGaussian = false;
}

Et c'est exactement ce qui est appelé depuis le constructeur. Donc, même si vous lui donnez un nombre premier, il ne l'utilisera pas de toute façon, donc si jamais vous devez utiliser une graine s où (s^ multiplicateur) & masque donne un nombre premier ;)

Java utilise une méthode habituelle de congruence linéaire, c'est-à-dire :

x_n+1 = (a * x_n + c) mod m avec 2 <= a < m ; 0 <= c < m.

Puisque vous voulez obtenir un periode maximal, c et m doivent être relativement premiers et quelques autres limitations assez obscures, plus quelques conseils pour obtenir une version utile en pratique. Knuth couvre évidemment cela en détail dans la partie 2 ;)

Mais de toute façon, la graine n'influence pas du tout les qualités du générateur. Même si l'implémentation utilisait un générateur de Lehmer, elle s'assurerait évidemment que N est premier (sinon l'algorithme est pratiquement inutile ; et non uniformément distribué si toutes les valeurs aléatoires devaient être copremières à un N non premier, je parie), ce qui rend le point discutable.

Answer 2

Si le générateur est un générateur de Lehmer, alors le germe et le module doivent être co-premiers ; voir la page wiki . Une façon de s'assurer qu'elles sont co-primées est de commencer par un nombre premier.

Answer 3

Si vous parlez de java.util.Random ou l'une de ses sous-classes dans le runtime Oracle, il n'y a aucune raison pour cela. C'est juste un caprice de votre superviseur.