Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Les générateurs de nombres aléatoires
Bonjour à tous !
La rubrique Mathématiques vous propose un article sur la génération des nombres pseudo aléatoires écrit par yahiko : les générateurs de nombres aléatoires.
N'hésitez pas à faire part de vos remarques, commentaires ou propositions d'améliorations !Cet article est une présentation de diverses méthodes pour générer des nombres pseudo-aléatoires.
Les générateurs de nombres aléatoires
Raymond
Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi
Cafuro
e-verbe
Ma page personnelle sur DVP.
Cela est sans doute passé inaperçu, mais depuis la version de Chrome 49, la fonction Math.random() génère de bien meilleurs nombres pseudo-aléatoires.
L'algorithme jusqu'à cette version 49 était un LCG nommé MWC1616.
Mais comme tous les LCG, il souffrait intrinsèquement de certaines régularités qui devenaient visibles au bout d'un certain nombre d'itérations.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
Désormais, V8 de Chrome utilise l'algorithme XorShift128+. Ce qui est amusant de noter, c'est que ce changement chez Google a poussé Mozilla et Safari a faire de même, ce qui réduit la nécessité d'utiliser un autre générateur de nombres aléatoires que celui par défaut. Et on ne s'en plaindra pas.
source : Blog officiel de V8
Bonjour,
j'avais pensé a un système pour avoir des nombre plus aléatoire que les algorithme classique, mais j'ai jamais prit le temps de le faire et vérifier mon assertion.
l'idée était d'écouter le port série du pc et de ce servir de ce bruit "pensé plus aléatoire" pour générer des nombres aléatoire ?
vous pensez que c'est viable, ou le bruit généré par le post série qui ne serait connecté a rien ne donnerai rien de bien. pareil pour le micro ?
Je ne connais pas très bien le niveau d'aléatoire (entropie) du bruit d'une prise série ou celui d'un micro, mais ce genre de systèmes existent déjà pour générer des nombres aléatoires. Certains générateurs de nombres aléatoires utilisent même le "bruit" du courant électrique au niveau d'un transistor. Mais il me semble que l'aléatoire produit ainsi n'est pas vraiment parfait dans la mesure où cela reste de la physique "classique" et donc plus ou moins déterministe, on n'a simplement pas assez d'informations. L'idéal reste donc de réaliser des mesures à un niveau quantique où le hasard n'est pas une propriété émergente, mais est réellement intrinsèque aux phénomènes observés.
On pourrait utiliser, comme précisé en début d'article, les mouvements de souris, en particulier les coordonnées du pointeur au click sur le bouton OK ou à l'appuie de la touche Entrée (après avoir saisi la seed).Envoyé par yahiko
Donc, randomSeed + coord souris y + coord souris x (ou *, ou autre formule, pour les plus sadiques).
J'ai dévoré l'article.
Alors j'ai deux points de discussion en tête.
D'abord, au sujet des chapitres 6 et 7, où l'alogo présenté en 7 est décrit comme plus "naturel" que le 6, avec exemple d'un univers généré. Le souci, c'est que l'on sait maintenant que l'Univers connu ressemble plus à ce que donne l'algo du 6. Voir ici http://www.nationalgeographic.fr/293...s-de-lunivers/
Second point, et si, au sein de l’algorithme, on ajoutait encore une composante random ?
Exemple :Bon, pour être précis, j'ai dans l'idée d'utiliser un nombre aléatoire Rand() pris entre 1 et randomSeed. Je ne sais pas exactement comment l'écrire, là, tout de suite (je sais surtout le faire en basic, pour créer des tirage d'entiers, afin de simuler un lancé de dé).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6var randomSeed = Date.now(); function randCLib(): number { randomSeed = randomSeed * 1103515245 + 12345; randomSeed = (Rand(randomSeed) / 65536) % 32768; return randomSeed / 32767.0; }// randCLib
De toute façon, il faut bien se dire que, dans la nature ou le reste de l'univers, l'aléatoire n'existe pas. Tout est déterminé. Mais déterminé par tellement de composants visibles et invisibles qu'il est juste humainement impossible de les traiter tous, afin de déterminer le résultat final.
Et pourtant, l'état d'un événement ou la position d'une chose à l'instant T sera toujours le résultat de l'influence d'un vaste ensemble d'autres événements : vent, humidité, vibrations, température, pression, altitude, perturbations de diverses natures causées par un autre événement (passe de voiture, abeille qui se pose ou qui frôle, gaz d'échappement d'un véhicule au feu rouge, etc...), etc., etc., etc. le tout se répercutant l'un l'autre et pouvant se propager très loin et donc influencer encore un autre événement, etc, etc, etc...
Ce qu'on appelle la théorie du Chaos, le papillon qui bat des ailes à Tokyo et qui provoque un orage à New-York.
Du coup, en y réfléchissant bien n'importe quelle formule est donc plus ou moins réaliste. Sa capacité à refléter la réalité dépend juste de sa complexité.
Le mieux, serait une formule qui, au lieu de prendre des nombres définis comme iciprendrait des paramètres passés par l'utilisateur (si on lui laisse la maîtrise sur les événements de son monde) ou par le monde lui-même (ou les conditions particulières à l'instant T/l’itération i).
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12var randomSeed = Date.now(); // Xorshift initialization var x = 123456789; var y = 362436069; var z = 521288629; function randXorshift(): number { var t = (x ^ (x << 11)) & 0x7fffffff; x = y; y = z; z = randomSeed; randomSeed = (randomSeed ^ (randomSeed >> 19) ^ (t ^ (t >> 8))); return randomSeed /2147483648.0;
Oh bon sang... Je viens juste d'imaginer un algo...
Vraiment bon, cet article !
Cela me fait plaisir que vous ayez apprécié l'article sur les générateurs de nombres aléatoires.
Pour répondre succinctement aux questions soulevées :
1) L'exemple d'univers présenté en fin d'article n'a aucune prétention de décrire une quelconque réalité mais juste de montrer en quoi mémoriser une graine peut permettre de régénérer un même univers, sans avoir à stocker l'ensemble des coordonnées aléatoirement générées au préalable.
2) Rendre la graine aléatoire est quelque chose qui est pratiqué dans certaines situations. Tout est permis, même s'il faut bien avoir en tête que l'algorithme reste pseudo-aléatoire et que rendre la graine aléatoire n'améliorera pas la qualité statistique des nombres produits, ni réduira le risque de pouvoir prédire les nombres aléatoires générés (par des individus malveillants par exemple).
3)
Jusqu'à preuve du contraire, les lois de la physique quantique stipulent bien que certains phénomènes quantiques sont réellement aléatoires et ne dépendent pas de paramètres qui nous seraient cachés par manque d'information (cf. débat entre Bohr et Einstein). Ce n'est qu'au niveau macroscopique que l'aléatoire intrinsèque de la physique quantique disparaît pour laisser place à des moyennes qui elles deviennent parfaitement déterministes.De toute façon, il faut bien se dire que, dans la nature ou le reste de l'univers, l'aléatoire n'existe pas. Tout est déterminé. Mais déterminé par tellement de composants visibles et invisibles qu'il est juste humainement impossible de les traiter tous, afin de déterminer le résultat final.
Mais là, on va sortir le cas du chat de Schrödinger. Mais j'ai jamais accepté cet exemple. Le chat n'est pas soit mort, soit vivant : Sauf avoir sauté dessus à pieds joints, le chat est toujours aussi vivant qu'à l'entrée. Schrödinger n'avait qu'à s'y mettre lui-même dans la boite, il aurait bien vu. Ce qui pourrait changer la donne, et donc donner une courbe temporelle parallèle, c'est que des événements influents différents interviennent : On décide soudainement de sauter sur le carton où est enfermé le chat. Après ça n'a peut-être rien à voir, au final.
Bref, pour en revenir au générateur, je me souviens d'anciens jeux qui permettaient au joueur de changer des paramètres, comme je le propose, mais ces changements étaient intégrés à la seed. Or moi, j'imagine plutôt faire varier la formule elle même. Si on considère que la seed est le postulat de base d'une certaine situation à un instant T et la formule représente alors tout ce qui fera varier le postulat de base pour donner la succession d’événements suivants, alors ce sont les paramètres/données de la formule qui doivent varier. Et on pourrait même pousser plus loin en imaginant que les paramètres de base, qui ne valent que pour le postulat de base, peuvent aussi varier en fonction de la nouvelle valeur, à chaque itération.
P.S. : le bruit blanc ou QRN est produit par toutes sources naturelles ou artificielles ambiantes pouvant perturber un courant électrique ou électro-magnétique. Et ça va de la lampe-torche aux tempêtes solaire. Sur une prise ou un micro c'est pareil. On reste dans le déterminisme, mais pour le coup, je pense que la mécanique quantique à plus son mot à dire, dans le cas de la prise surtout.
Quoi, je suis parano...
Bonjour,
Voici les questions que je me pose, relatives aux générateurs de nombres aléatoires (RNG), et pour lesquelles je n'attends pas de réponse**.
- Il y a quelques années, j'ai posé une question sur le site DVP relative au "mot de passe" des liaisons WIFI et leur "longueur", étant bêtement convaincu que si 63 caractères étaient utilisables, le meilleur "mot de passe" en serait un de 63 caractères de long. Il m'a été répondu que ce "mot" n'était là que comme graine d'un générateur qui lui donnait "autre chose" utilisée comme "mot de passe" (ou équivalent). RàS, mais j'ai surtout noté que le thread avait disparu dans les jours qui suivirent !
- Il me semble avoir compris qu'en France, la politique interdit de crypter les communications, et que tout ce qui concerne l'exécutif (la police au sens large, dont DST et descendants) s'intéresse de très près aux hébergeurs et fournisseurs d'accès internet, où ils imposent des règles comme, par exemple, celle de ne pas avoir à chercher les mots de passe des visiteurs des sites hébergés.
- J'ai également noté qu'un des premiers travaux demandé aux hypers ordinateurs (quantiques) a été de casser des codes d'encryptage.
- Je ne vois plus, comme par le passé, l'interdiction d'exporter les logiciels de cryptage, comme on pouvait le lire il y a (trop) longtemps dans les manuels des produits d'origine des USAs. En fait ma mémoire est confuse, mais je me souviens avoir lu ça dans des documents de produits d'origine des USAs (Digital Equipment Corporation ?). Je me dis que les ressources pour casser les codes sont suffisamment puissantes aujourd'hui pour ne plus imposer ces remarques.
- On ne manque jamais sur DVP en particulier, de parler de la NSA, des failles de sécurité, des portes dérobées et autre "grâcieusetés". L'objectif est clairement d’espionner, et comme le générateur de nombres pseudo-aléatoires est au centre du système de cryptage, je me dis qu'il parait judicieux de "contrôler" (au sens anglais) tout ce qui se publie dans ce domaine.
- En 2006, j'ai commencé à utiliser un jeu de belote qui a été développé sous WindOverDose mais qui, par chance, tournait convenablement sous Wine. J'ai souvent vécu la frustration parce que j'avais l'impression de rejouer les mêmes donnes. Je suis entré en contact avec le développeur qui a fini par se fâcher et cessé de me répondre. J'ai fini par penser que l'auteur n'était pas en cause, mais que le générateur de nombres pseudo-aléatoires, si. Il faut que le générateur de Microsoft à l’export soit faible, pour faciliter l'espionnage, mais sa faiblesse peut finir par se voir.
En 2014, j'ai commencé construire un jeu de belote fonctionnant dans un fureteur. J'ai D’abord utilisé l’objet Math, puis ai décidé d'utiliser un générateur propre à l'application. Ce premier fut une implémentation de "Richard Brent's Xorgens: xor4096 algorithm"(code ici). Mais je n'en étais pas satisfait, même si c'est un excellent générateur. Je me suis ensuite tourné vers celui-ci www.imagine-programming.com où j'ai trouvé de quoi moudre.
Pour faire un générateur aux résultats humainement très imprévisibles, j'utiliserais un compteur électronique 16 bits en boucle capable de passer très rapidement par ses 65536 états (par exemple, mais au moins !)_: il ne resterait pas plus de 1 nanoseconde sur un état (horloge à 1GHz). Considérant que deux gestes identiques répétés rapidement par un humain ne sont pas facilement espacés de moins de 100mS, ce compteur aurait eu le temps de passer ~1500 fois par tous ses états. Si on échantillonne ce compteur une fois par action, la valeur de l'échantillon peut être considérée comme aléatoire. C'est moins facile pour le suivi d'une souris : le système questionne-t-il régulièrement la souris pour en connaître la position ou la souris n'informe-t-elle le système que quand il y a un changement de position sur l’un des deux axes ? Quel espace de temps entre deux de ces événements curseur vu du système, de X ou de JavaScript ? Avec ce compteur exemple, on doit s'attendre à devoir augmenter la fréquence d'horloge pour générer de l'entropie à partir des déplacements du curseur.
Finalement je souhaite créer une graine digne de ce nom et voudrais utiliser (en JavaScript dans un fureteur, donc) souris et touches afin de créer de l'entropie, quitte à créer un court "jeu" à l'ouverture de la page. Mais les choses ne sont pas si simples qu'il semble. D'abord, j'aimerais que la répartition des bits sur une certaine quantité d'échantillons (mais combien ?) soient 50% de 1 (-: et autant de 0).
- 1er cas_: Je garde les X bits à droite du bit levé le plus significatif : par exemple 0001_0011_0110_0111 -> 12 bits 0011_0110_0111 que je "sérialise de sorte à composer un mot de N bits (32 bits à priori).
- 2nd cas_: j'échantillonne le e.timeStamp et retourne ou inverse les huit bits de poids faibles, le bit 0 étant le plus "instable", de sorte que le bit 0 devienne le bit 7, le 1 en 6, etc. Je totalise les bits de tous les échantillons et au-delà de 100 (?) d'entre eux, je favorise les 1 ou les 0 (comment ?) pour arriver à une parité de 50,00% au bout de 128 échantillons.
Il y a un problème majeur à utiliser e.timeStamp_: il me semble avoir lu dans quelque documentation (FF probablement) que ses valeurs sont modulos 5mS ou quelque chose comme ça. Mais si les 5ms ne sont pas cadensé par un échantillonnage genre "setInterval()", je crois qu'il est possible de faire bien sans e.timeStamp.
**Les réponses à cette question m'intéressent : quelqu'un aurait un exemple de source (ouverte de préférence), ou une bonne méthode pour parvenir à un résultat correct de graine, voire de générateur ?
Je vous remercie pour l’attention que vous aurez portée à ce post.
Bonjour,
J'ai eu le temps d'essayer un petit pneu, et ça ne m'a pas gonflé !
Je me suis trompé : autant que je puisse juger des résultats, l'utilisation de e.timeStamp fonctionne bien mieux (et est probablement moins "lourd") que new Date().getTime(). Ces histoires de 5mS doivent concerner la précision, "seulement". J'ai du confondre, et ai la flemme de chercher…
Le jeu utilisé permet de jouer au clavier comme à la souris. J'ai donc pu sortir les ~70 kbits rapidement en jouant avec la souris, mais ce fut bien plus long pour les ~10 Kbits en jouant au clavier !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
J'ai commencé à coder avec des opérateurs "bitwise". Je ne sais pas si on y gagne en temps d’exécution, mais le fait de pouvoir utiliser une chaîne de caractères comme un tableau, ça va bien plus vite à écrire et même tester…
Ça semble correct ! Mais ce n'est que l'appréciation d'un incompétent ! Qu'en, pensez-vous ? Je n'ai pas encore eu le temps de tester le "second cas du post précédent. Mais je me demande si ça vaut la peine.
Dans l'espoir de vous lire bientôt…
Les générateurs de nombres aléatoires
Bonjour,
J'avais lu (et relu) d'une manière approfondie l'article auquel se réfère cette discussion, et qui constituait une excellente initiation sur le sujet.
Ton intervention cite des références intéressantes, mais que je n'ai pas eu le temps d'examiner dans le détail.
Je ne suis pas spécialiste en ce domaine, mais deux remarques concernant la description de ton projet me viennent à l'esprit.
1°) Qu'entends-tu par un graine correcte, digne de ce nom ? Une séquence de caractères totalement imprévisible, dont chaque terme ne pourrait être déduit de ses prédécesseurs - à l'exact opposé de ce qu'emploierait un internaute peu imaginatif, comme par exemple:
<Timeismoney> ou <Unagneausedésaltéraitdanslecourantd'uneondepure> ?Il te faudra renoncer à tout langage humain, car je crois bien les logiciels casseurs de code capables d'identifier les mots de toute langue connue, pour peu qu'elle s'écrive (ou soit translittérable) en caractères latins ou cyrilliques.
La seule solution: un séquence pseudo-aléatoire de (n) termes, qu'il s'agisse des chiffres décimaux - ou éventuellement des caractères imprimables du code standard. Le calcul apparaît ici comme une étape obligatoire, le cerveau humain étant incapable d'assumer cette tâche; une calculatrice scientifique dont la précision est assurée sur 14 chiffres, mais dépourvue d'accès à Internet donc inaccessible à l'espionnage, fera fort bien l'affaire: il suffira pour cela de faire intervenir une fonction à valeurs irrationnelles, s'étalant sur un domaine d'étendue raisonnable, qui à tout argument banal (par exemple la date et l'heure du premier mail, ou de la création d'un fichier) pourra faire correspondre une séquence de 6 à 12 chiffres.
L'entier (x) représentant par exemple la date au format <jjmmaa>, la fonction F(x) = (x*10-4)2/3
varie de 1.008 116 884 594 0 (au 01/01/2022) à 9.894 188 790 472 5 (au 31/12/2022)et peut conduire à des séquences de 12 chiffres décimaux. Les variantes envisageables sont innombrables, dès lors qu'on en a saisi le principe.
Un logiciel de calcul présente des possibilités beaucoup plus vastes, mais son installation sur la machine rend son utilisation visible à un intrus: il faut prendre des dispositions cohérentes.
2°) La parité des chiffres binaires (0 et 1) doit-elle être exactement respectée ? Un séquence apparaît-elle moins "aléatoire" dès lors qu'elle ne comporte que 45% de (1) ? La probabilité de sortie de tels nombres est certes inférieure à celle du cas précédent, mais nullement négligeable.
Ainsi dans une séquence de 128 bits, la probabilité de présence de 64 chiffres (1) est (de tête, à vérifier):
Cnp/2n = C12864/2128 = 7.039 % (1)donc très minoritaire (moins d'une séquence sur 14).
La restriction des séquences à la condition évoquée est artificielle et excessive; en restreignant drastiquement le nombre de combinaisons, elle facilite au contraire la tâche des pirates.
De plus elle ne tient pas compte de la succession des chiffres, dont la régularité éventuelle serait rapidement détectée; prendrais-tu pour graine un nombre tel que
<1111 1111 1111 1111 0000 0000 0000 0000> ?Il paraît préférable de renoncer à toute restriction de ce genre.
D'autres manipulations, que tu as évoquées, sont sûrement plus efficaces: inversion de la séquence, mélange par énumération alternée, recours à l'opérateur Xor.
(1) https://www.wolframalpha.com/input?i...4%29%2F2%5E128
Bonjour wiwaxia et merci pour votre post.
Cette histoire de parité m'a turlupiné à cause du bout de code utilisé pour mélanger un tableau :
Je me suis demandé quel bit utiliser, parmi les 32 retournés par le générateur. Au début, j'ai écrit :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
Mais il m'est rapidement apparu que pour battre sérieusement un jeu de 32 cartes avec cette méthode, il faut décemment appeler au moins 10 fois consécutivement ArrShuff(). L'entropie peut se révéler précieuse, alors, pour écrire "vert" (-: , j'ai modifié le code de ArrShuff() pour qu'elle retourne un résultat en lien avec un seul des 32 bits d'un mot en buffer (le code est sans intérêt). Dans le premier cas j'utilisais 320x32 bits et comme j'ai poussé le battage des cartes jusqu'à 32 appels dans le second cas, je n'utilise plus que 32x32 bits. Mais avec cette modification, la parité, la "disposition" ou "répartition" des bits dans le mot ont beaucoup d'effet, surtout si on ne répète pas suffisamment l'appel à ArrShuff(). D'où cette question : quid de la parité des résultats ? Mon raisonnement est simple : ces générateurs XOR cycles plus ou moins rapidement (le moins rapidement -> le meilleur), on peut supposer que même si un nombre X se trouve N fois dans un cycle complet, tous les autres nombres devraient idéalement se retrouver également N fois dans ce cycle. Dans mon exemple de compteur 16 bits à 1GHz, ce serait évidemment vrai puisque la parité des 1 et des 0 est garantie en comptant de 0 à 65535. Si le PRNG utilisé boucle sur un nombre astronomique, il est clairement difficile d'apprécier la parité des 1 et des 0 sur un échantillon astronomiquement microscopique de 256 valeurs de 32 bits…
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
C'est vrai qu'il y a de nombreuse façons d'ensemencer un PRNG. Isaac propose rien, un nombre ou un tableau de 256 mots de 32 bits, du genre de celui dans lequel il donne ses résultats.
- Rien signifie partir du nombre 0 en quelque sorte. Cela peut être bien pendant le développement pour retrouver toujours les mêmes situations, mais surtout pas en cas d'une vraie utilisation.
- Un nombre entier de 32 ou 64 bits, c'est tout de même pas mal, mais comme le hasard ne se trouve guère que dans le temps écoulé depuis Epoch, exprimé en milliseconde, au lancement du logiciel (JavaScript dans un fureteur), je me dis qu'un malin pourrait bien y penser_! je sais bien qu'il ne s'agit que d'un tout petit jeu de belote, mais je suis parano, comme chacun aura pu le lire dans mon premier post dans ce thread_! L'utilisation simple de l'objet Math est à proscrire aussi, bien sûr.
- Au démarrage et pour ensemencer le PRNG, la meilleure solution m'a donc semblé être de récupérer le dernier tableau de 256 mots de 32 bits générés antérieurement et préalablement stocké localement ou, si ce tableau n'existe pas, de proposer un petit jeu se jouant à la souris qui nous offre un assez "pur" hasard.
En définitive, je proposerai un choix triple_: graine mémorisée | petit jeu | "automatique", parce qu'en cas d'arrêt brutal du fureteur, le joueur peut se retrouver à jouer à partir d'une graine qui a déjà été utilisée. Automatique sera la date "retournée" (-> inversion "bout pour bout" des 64 Bits les moins significatifs de la date en mS, ou quelque chose de ce genre).
Cordialement.
Les générateurs de nombres aléatoires
Encore une fois, la recherche de la conformité d'un résultat particulier aux moyennes statistiques est une impasse, car elle découle d'un travers incoercible de l'esprit humain, qui espère d'instinct que tout excès ou défaut local (dans l'espace ou dans le temps) soit immédiatement compensé par une anomalie en sens contraire. Cela n'a rien d'un reproche personnel: le cerveau est spontanément mal disposé à concevoir des évènements aléatoires.
Bien que ce soit contre-intuitif, le hasard, ce n'est pas l'uniformité.
En effet, la mesure exprimée en millisecondes du temps écoulé depuis une date convenue (01/01/1970 ?) est aléatoire au niveau de ces 3 derniers chiffres décimaux, ce qui laisse une petite marge.
Voici une autre option, histoire de passer à un autre algorithme, le recours aux suites décalées de Fibonacci définies par la relation de récurrence:
Fn = Fn-j#Fn-ket dans lesquelles l'opérateur binaire (#) correspond soit à l'addition ou la multiplication modulo (m), soit à l'opérateur XOR; dans ce dernier cas le majorant strict (m) des entiers naturels envisagés correspond à une puissance remarquable de 2:
m = 28 (Byte), 216 (Word), 232 (DWord), 264 (QWord) .La période effective de telles suites prend des valeurs théoriques énormes pour quelques paires privilégiées:
(j , k) = (7 , 10) , (5 , 17) , (24 , 55) , (65 , 71) ...celles en fait pour lesquelles le polynôme Pj,k(x) = xk + xj + 1 est premier sur {-1 , 0 , 1} (1).
Tu peux par exemple envisager une suite d'entiers au format Word, dont les (k) premiers termes seront initialisés à l'aide du générateur de ton choix; les termes suivants te donneront directement les positions des deux cartes à échanger, par les relation:
xn = Fn MOD 32 ; yn = (Fn DIV 2048) MOD 32 .Le battage du jeu comportera un nombre arbitrairement choisi de transpositions.
https://en.wikipedia.org/wiki/Lagged...acci_generator
(1) Pour celles et ceux d'entre vous à qui cela ne paraîtrait pas très clairvoir par exemple
https://www.wolframalpha.com/input?i...4%2Bx%5E71%2B1
https://www.wolframalpha.com/input?i...5%2Bx%5E71%2B1
https://www.wolframalpha.com/input?i...6%2Bx%5E71%2B1
En fait ceci est une correction du code proposé post #9, les résultats affichés en fin de CODE ne correspondent plus à la correction ci-dessous et ne sont donc pas valides. En fait, si vous regardez bien le code initial, les bits créés sont plus liés à e.timeStamp qu'à un "delta e.timeStamp" entre deux événement, ce qui faisait qu'à la souris, ça allait beaucoup vite qu'au clavier…
Voici une correction qui devrait vous permettre de tester :Dans la version actuelle, je concatène également les bits Math.abs(e.movementX)+Math.abs(e.movementY) dans le cas où l'événement est du type "mousemove".
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Cordialement
Chapeau bas...
C'était bien, mais pas aidant dans mon cas !...Pour celles et ceux d'entre vous à qui cela ne paraîtrait pas très clair
La dernière fois qu'on m'a parlé ainsi, ça date de près de 50 ans, et j'avais déjà du mal à suivre. J'ai pas eu souvent besoin d'une grande maitrise de l'outil mathématique dans ma vie : peut-être 3 fois (surtout en lien avec la géométrie), mais j'ai alors bien regretté de ne pas avoir accroché à l'époque. Trop tard !
Merci à vous.
Pas bon...
Un petit post pour vous faire part de ma conviction que la méthode que j'ai utilisée pour traiter les événements n'est pas la bonne : j'ai encore plus souvent qu'avant (le changement du PRNG) l'impression de vivre des donnes que j'ai déjà vécues. Ça me gosse(qc) balaise(fr) !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager