Phenix tu confirmes que lorsque tu dis "rapproché", tu parles de plusieurs minutes ? Parce que moi aussi j'avais compris genre dans le même script, tu fais plusieurs fois appel à mt_rand, et c'est à ce moment là qu'il te donnerai des valeurs proches...
Mais si c'est espacé de plusieurs minute, je ne pense pas, moi non plus, qu'il puisse y avoir un lien entre les valeurs...
je confirme que mt_rand, meme dans un temps tres raproché (genre une boucle for en php) est fiable, et avec une dispertion des valeurs suffisante pour dire que c'est aléatoire.
J'ai fais des tests pour 100.000 résultats d'une roulette de casino (1d37 vu que je ne me suis pas servir du double zéro)
Hé bien j'ai pu constater, que dans une série d'attaque a disont 60% de chance de réussir on obtient souvent des résultat qui semble a première vue ce suivre. L'intervalle entre les attaque doit être d'une ou 2 seconde, le temps de cliquer sur le bouton. Par exemple, si je réussi ma première attaque on peux dire que je suis dans un bonne série, les chances de réussir les autres semble plus grande et inversement.
Je suis pas le seul a constater cela, j'ai déjà vu (sur épic-war par exemple) des gens qui obtenaient des taux de réussite plus grand simplement parce qu'ils "testaient" la série et s'il ratais leur première attaque attendais 1 minutes ou 2 avant de retenter...
Maintenant, il est vrai que ce n'est que pure spéculation sur des resentit, si on boucle 10000 fois un mt_rand, il n'en ressortira sûrement rien d'étrange...
Phenix
Oui, c'est le hasard.
Et les joueurs ont vite fait de spéculer dessus. Quand je faisais des jeux de plateau et que les bons jets ne venaient pas, je me sentais persécuté par dame Fortune.
Sephi-Chan
Coucou,
L'idée consistant à loguer les résultat aléatoire dans un fichier, séparé par un point virgule me semble une bonne idée. Tu pourrais nous fournir une journée de fichier de test ?
Salut,
Kéké.
Hello, je sais que ce post est vieux, mais plutôt que d'en créer un nouveau j'aimerais poursuivre un peu sur l'aléatoire.
Je me demandais si quelqu'un savait comment cela fonctionne exactement (le calcule même s'il est complexe) ou l'endroit où trouver ce calcule? (sans doute basé sur la date)
Et puisque l'algo se base souvent sur la date, il serait intéressant de voir si les random reste équiprobable dans des tranches horaires différents.
Car de ce que j'ai constaté, comme dis dans ce post, si on fais un test sur un 1 million de boucle de random et qu'on regarde les pourcentages, cela tant a se ressemblé.
Mais es-ce vrai si on prend en compte la variable du temps?
Que donnerait ce même algo si on l'exécute a des tranches horaire différente?
Ou encore faire des exécutions a plusieurs tranche horaire et en faire une moyenne sur le tout... es-ce que cela concernerait les mêmes pourcentages?
(11-06-2010, 11:54 AM)Argorate a écrit : [ -> ]Je me demandais si quelqu'un savait comment cela fonctionne exactement (le calcule même s'il est complexe) ou l'endroit où trouver ce calcule? (sans doute basé sur la date)
Tu peux chercher dans le source du PHP et... remonter à la source :
http://lxr.php.net/opengrok/s?refs=mt_ra...ct=PHP_5_3
A+
Pascal
Sinon voici ce qu'indique la doc:
Citation :De nombreux générateurs de nombres aléatoires provenant de vieilles bibliothèques libcs ont des comportements douteux et sont très lents. Par défaut, PHP utilise le générateur de nombres aléatoires de libc avec la fonction rand(). mt_rand() est une fonction de remplacement, pour cette dernière. Elle utilise un générateur de nombres aléatoire de caractéristique connue, le " » Mersenne Twister " qui est 4 fois plus rapide que la fonction standard libc.
Et wikipedia anglophone indique le détail de l'algo:
http://en.wikipedia.org/wiki/Mersenne_twister
Par contre comme certains générateurs de nombre aléatoire se basent sur une suite numérique, par exemple la méthode de Von Neumann, je me demande si on ne pourrait pas prédire, avec un pourcentage d'erreur évidement, le nombre qui suivra celui qu'on vient d'obtenir.
Bon c'est trivial pour la méthode de Von Neumann puisqu'elle réutilise directement le résultat précédent.
Mais moi je parle d'un trucs plus fin ou on estimerait le nombre de nombre aléatoire tiré depuis le début et ou on calculerais ensuite X nombres suivant.
On regarde dans les nombres obtenue ceux qui corresponde à celui qui vient d'être obtenue et on met le nombre qui suit dans le tableau des valeurs plus probable.
Ainsi on peut forcer un peu plus le destin.
Bon le seul trucs c'est que si on ajoute un salt (ou une donnée temporaire comme Mersenne Twister avec le registre à décalage) çà ne fonctionne plus du tout lol. Ou alors il faudrait vraiment obtenir une longue liste pour récupérer le salt en faisant tourner un pc pendant un certains temps.
Il me semble que le temps n'est que le la graine de hasard utilisé.
Si je me souviens de mes cours de C, le hasard informatique se calcule avec des fonctions polynomiales possédant une bonne 50 aines d'exposant (Ax^n + Bx^(n-1) + Cx^(n-2) ...) ; dans cet exemple, A B C... sont appelés une graine.
puis on prend au hasard, l'une des décimales de cette fonction, pour X = 1, puis pour X=2, etc ...
L'avantage de ce système est qu'il est possible d'améliorer le hasard en itérant le principe. Ainsi, on pourrait initier le polynome avec la graine A=1, B=1, C=1 ... On pourrait ainsi récupérer quelques chiffres assez peu hasardeux pour former une deuxième graine. Cette deuxième graine pourrait former un hasard un peu plus hasardeux pour former une troisième graine, etc.
Alors à partir de quand déclarer que l'on est en face d'un vrai hasard ? Mathématiquement, c'est impossible ... cherchez pas. Un pc n'est pas empli de doute. Le hasard lui est totalement inconnu. Cependant, le comportement humain considère qu'il y a un hasard à partir d'une certaine itération.
L'idée principale étant de trouver un moyen pour accéder dès le début à une graine contenant un potentiel suffisamment hasardeux.
Il me semble que en C/C++/C#, la première graine se calcule en fonction de l'une des décimales du voltage de la carte mère... D'autres méthode se basent sur le nombre de milisecondes du pc au moment de la recherche de la graine.
http://www.commentcamarche.net/faq/7070-...-avec-rand
Kéké qui peut dire plein de bêtises tellement son cours de C remonte loin ^^
la décimale du voltage de la carte mère... donc, si un programme compilé en C doit tourner sur un pc, il doit intégrer un driver permettant un accès au chipset qui va relever (de manière tres précise) les décimales du voltage de ta carte mère (peut importe le pc, même les low-cost dépourvus de ces sondes!) ^^
J'avais entendu pas mal de choses, mais a vrai dire, celle là je ne l'avait pas encore entendue ^^
J'avais entendu la valeur des axes du joystick analogique, ou un la valeur d'une adresse aléatoire de la RAM (bonjour le "segment fault" et autre crasses!), la prise microphone (suffit de chanter pour améliorer son lancer de dé? ^^), ... je pense que ce qui est suffisament aléatoire serait le up-time + le microtime de l'heure courante + temps d'exec du script + ...
mais il ne faut pas chercher des trucs trop farfelus ^^