Générateur de séries aléatoires sans variables cachés.

[invited494020f]

Bonjour,
Il est communément admis que les calculatrices algorithmiques ne sont pas capables de produire des séries aléatoires sans faire appel à des "variables cachés", comme p. ex. leur horloge interne, ou la désintégration d'atomes.
Ayant quelques connaissances du fonctionnement intime de ces machines, cette affirmation m'a toujours étonné. J'ai donc pris un peu de temps pour y voir clair et m'assurer que le BIOS (basic input output system) n'offrait pas une possibilité de réaliser des séries aléatoires dues uniquement au hasard, rigoureusement irréproductibles et ne nécessitant pour leur génération aucun appel à l'horloge interne.
Le programme est très simple et ne comporte que des instructions courantes, en excluant toutes celles servant à créer des séries peudo-aléatoires.
Pendant le déroulement du programme il faut appuyer sur la barre d'espace à trois reprises.
Naturellement, le programme ne pourra être publié qu'après le dépôt de l'enveloppe solo, pour établir son antériorité.
Je mets en pièce jointe une série de 36 variables obtenues par ce programme et une analyse de leurs fréquences.
Pour valider ce programme, je dois encore faire pas mal de manips, mais je vous en voulais donner la primeur!
-----

[GuYem]

C'est intéressant.
AS-tu essayé de générer un trés grand nombre de valeurs et de vérifier les moyennes et variances estimées ?

[GuYem]

Ah oui tu l'as fait excuse moi

Essayes avec beaucoup plus de tests. Je te conseille 100.000 si ce n'est pas trop long.

[equation]

vus que le hasard n'éxiste pas je doute que ton générateur de chiffre ne delivre pas c'est chiffre par un algorthyme

si c'est chiffre sont sorti c'est forcement parce que les ligue de ton programme indiquer quel chiffre sortire et non pas le fruit du hasard

d'accord je suis pas trés clair mes en programmation on utilise l'heur pour éviter de justement avoir toujour les meme numéro qui sorte mes sa change pas que si tu lance ton generateur a la meme seconde que la derniere fois il sortira les meme chiffre.

en clair ya pas de hasard possible ni dans la réaliter ni dans la programmation ni dans rien du tout

[A voir en vidéo sur Futura]

[GuYem]

vus que le hasard n'éxiste pas je doute que ton générateur de chiffre ne delivre pas c'est chiffre par un algorthyme

si c'est chiffre sont sorti c'est forcement parce que les ligue de ton programme indiquer quel chiffre sortire et non pas le fruit du hasard

d'accord je suis pas trés clair mes en programmation on utilise l'heur pour éviter de justement avoir toujour les meme numéro qui sorte mes sa change pas que si tu lance ton generateur a la meme seconde que la derniere fois il sortira les meme chiffre.

en clair ya pas de hasard possible ni dans la réaliter ni dans la programmation ni dans rien du tout

C'est bien défaitiste tout ça.
De toute façon on a besoin de générer des nombres au hasard, autant prendre les meilleures techniques.

[g_h]

en clair ya pas de hasard possible ni dans la réaliter ni dans la programmation ni dans rien du tout

Et les désintégrations radioactives alors ?

[equation]

C'est bien défaitiste tout ça.

non pourquoi, je dit que le hasard n'éscite pas mes pas que l'on peut pas essayer de l'imiter, c'es exactement comme dans le RAN pour ceux qui connaise, suffisant pour génrer un effect de hasard sans que sa en soit vraiment un.

Et les désintégrations radioactives alors ?

absolument pas du au hasard, ce n'est pas parce que noit ne somme pas capable de prévoir quand aurra lieu cette désintergration radioactif que ces forcement le fruit du hasard
c'est juste un manque de connaissance.

[invitebf65f07b]

Pendant le déroulement du programme il faut appuyer sur la barre d'espace à trois reprises.

salut,

juste pour savoir, la barre espace, c'est quand même pas pour obtenir deux ou trois nombres pour initialiser l'algo?
parce que à ce jeu là, il n'y a pas trop de différences avec le fait de prendre les secondes de l'horloge du pc pour initialiser un algo déjà connu.

sans vouloir te faire révéler tes petits secrets, bien sûr...

[invited494020f]

Ah oui tu l'as fait excuse moi

Essayes avec beaucoup plus de tests. Je te conseille 100.000 si ce n'est pas trop long.

Bonjour,
si, c'est très long! 4477 jeux, c'est déjà pas mal, mais quand j'aurai le temps, je le ferai. Pour l'instant je fignole les présentations: il existe déjà 9 progeammes alea, plus les programmes de contrôle, je m'y perds un peu. De toute façon, le générateur ALEA (quelques lignes) est toujours le même. Tout l'affaire n'a qu'une semaine d'existence et je suis étonné des résultats obtenus.

[invited494020f]

vus que le hasard n'éxiste pas

Bonjour, si tu pars de ce préalable, ce n'est pas la peine de discuter.

[equation]

je dit pas que ton programe est nul , loing dela il est peut étre meilleur pour délivrer un chiffre au hasard me se que je peut affirmer c'est que le chiffre n'est pas sorti par un pur hasard.

par contre je serai interresser de savoir comment ta construit se programme.

tu as utiliser quel langage ..visualbasic?

[invited494020f]

salut,

juste pour savoir, la barre espace, c'est quand même pas pour obtenir deux ou trois nombres pour initialiser l'algo?
parce que à ce jeu là, il n'y a pas trop de différences avec le fait de prendre les secondes de l'horloge du pc pour initialiser un algo déjà connu.

sans vouloir te faire révéler tes petits secrets, bien sûr...

Bonjour,
Il existe plusieurs versions (je suis en période de validation).
Dans la plus simple il faut, une fois le programme chargé:
1/ appuyer sur la barre d'espace de façon prolongée (puisque ceci provoque la répétition automatique de la touche, je mets un plomb de pêche dessus) pour lancer le générateur et entretenir son fonctionnement, jusqu'à ce que l'on désire obtenir les résultats. On pourrait aussi le "titiller", mais là il y aurait l'introduction d'un aléa humain, à proscrire!
2/ appuyer sur la touche "escape", ce qui lance l'impression des résultats (qui peuvent être de plusieurs sortes).
3/ appuyer sur la touche "escape" pour quitter le programme. Cette action sera supprimée et la sortie sera automatique après l'impression.
J'ai commencé ce bidule il y a une semaine, avec le handicap de me remettre à la programmation que j'ai arrêté il y a plus de vingt ans. J'ai choisi le Turbo Pascal, qui est le plus facile à utiliser. Un fois mon antériorité protégée (enveloppe solo) je publierai tout ce qu'on veut.
Pour l'instant il faut me croire sur parole!

[invité576543]

Bonjour,

Ce type de problème est parfaitement connu dans les milieux de la cryptologie.

Générer des séquences que personne ne peut démontrer n'être pas aléatoires avec les moyens disponibles est très facile, et des quantités de possibilités ont été développées dans le cadre de la cryptologie.

Théoriquement, si la taille du programme est bornée, le nombre d'algo est fini. Il "suffit" donc de les tester tous les uns après les autres, contre une séquence suffisamment longue (nettement plus grande que le nombre d'algo possibles) pour trouver l'algo. (La longueur de la séquence nécessaire est la minimale nécessaire pour qu'une divergence apparaisse entre l'algo et tout autre algo de la liste, qui sont en nombre fini.) C'est théoriquement possible (= pas de hasard), mais en pratique totalement impossible (le temps et ou les ressources nécessaires sont incommensurables à l'univers lui-même).

Les séquences proposées ne sont vraisemblablement pas assez longues pour y voir quoi que ce soit (ou alors l'algo est assez nul...). Il est très facile de générer des algos pour lesquels tous les indicateurs statistiques sont bons sur des séquence très très longues... Prenez un fichier d'une centaine de Goctets généré avec drivecrypt par exemple, en choisissant l'algo que vous voudrez dans la liste proposée, et cherchez un indicateur qui montre quelque chose...

Cordialement,

[invited494020f]

Prenez un fichier d'une centaine de Goctets généré avec drivecrypt par exemple, en choisissant l'algo que vous voudrez dans la liste proposée, et cherchez un indicateur qui montre quelque chose...

Cordialement,

Bonjour,
Je n'irai certainement pas jusque là. Mon algo joue sur l'incertitude (peut-être apparente, mais il faudrait le prouver) qui se constate en faisant tourner un programme ultrasimple, de 4 lignes (noyau du générateur) ne faisant intervenir aucun "variable caché".
Je ne prétends pas que la production de cet algo soit le fruit d'un hasard équivalent à celui qui préside à la désintégration atomique, mais seulement qu'il est irréproductible une fois sur l'autre et qu'il peut utilement remplacer les programmes aléatoires habituels reproductibles.
Ton point de vue, comme le mien, restent à prouver. Je m'y emploie.

[invitebf65f07b]

paulb,

juste pour savoir, t'es tu beaucoup renseigné sur les générateurs pseudo aléatoires?
par exemple les générateurs à congruence linéaire (parmi les plus utilisés) : .

en plus d'être simple (hormis des question de choix de paramétrage a priori), ils ne sont pas ce que j'appellerais "à variables cachées".

[inviteab763770]

Bonjour,

Ces séries me semblent bien courtes pour qu'il soit possible de les caractériser, et de valider leur caractère aléatoire.

Impossible de les traiter en "noise sphere" ou en test de Diehard.

Je me trompe ?

[invited494020f]

paulb,

juste pour savoir, t'es tu beaucoup renseigné sur les générateurs pseudo aléatoires?
par exemple les générateurs à congruence linéaire (parmi les plus utilisés) : .

en plus d'être simple (hormis des question de choix de paramétrage a priori), ils ne sont pas ce que j'appellerais "à variables cachées".

Bonjour,
Non, je joue sur les carctéristiques intimes du fonctionnement du BIOS. Pour l'instant je ne peux pas en dire plus, mais ça viendra.

[invited494020f]

Bonjour,

Ces séries me semblent bien courtes pour qu'il soit possible de les caractériser, et de valider leur caractère aléatoire.

Impossible de les traiter en "noise sphere" ou en test de Diehard.

Je me trompe ?

Bonjour,
Combien t'en faudrait-il?

[inviteb85b19ce]

Mon algo joue sur l'incertitude (peut-être apparente, mais il faudrait le prouver) qui se constate en faisant tourner un programme ultrasimple, de 4 lignes (noyau du générateur) ne faisant intervenir aucun "variable caché".

Bonsoir,

Juste une remarque gratuite car je ne peux évidemment rien dire d'autre sans connaître ton algo :
Tout ce qui rapporte à l'exécution d'instructions du processeur dépend de variables : sa fréquence, sa température, l'occurrence d'interruptions hardware pendant l'exécution etc.

J'ai vu que tu utilisais le Turbo Pascal, je suis curieux de voir ce que donnerait une adaptation du programme directement en assembleur

À bientôt.

[inviteab763770]

Bonjour Paulb,

Bonjour,
Combien t'en faudrait-il?

A partir de 10Mo pour certains tests...

Mais en général on considère qu'il faut 40000 à 50000 bits pour effectuer un test valable.

Il y a aussi une méthode des fréquences qui permet
un premier niveau de test.

[invited494020f]

Bonjour Paulb,



A partir de 10Mo pour certains tests...

Mais en général on considère qu'il faut 40000 à 50000 bits pour effectuer un test valable.

Il y a aussi une méthode des fréquences qui permet
un premier niveau de test.

Bonjour, je m'y mets!

[invite6f0362b8]

QUOTE]Et les désintégrations radioactives alors ?[/QUOTE]


aléatoire mais pas à long terme puisque les elements radioactifs ont une demi durée de vie

c'est a dire qu'ils perdent la moitié de leur radioactivité (donc moitié moins de desintegration) tous les x années .....


donc le temps entre desintegration, le nombre desintégration, fréquence desintegration ne sont pas purement aléatoire A LONG TERME ....

[spi100]

QUOTE]Et les désintégrations radioactives alors ?


aléatoire mais pas à long terme puisque les elements radioactifs ont une demi durée de vie

c'est a dire qu'ils perdent la moitié de leur radioactivité (donc moitié moins de desintegration) tous les x années .....


donc le temps entre desintegration, le nombre desintégration, fréquence desintegration ne sont pas purement aléatoire A LONG TERME ....

Oui, effectivement les valeurs moyennes sont predictibles, les fluctuations se nivellent, mais bon c'est le ba-ba des probabilités je ne vois pas en quoi cela prouve que le hasard n'existe pas.

Je te donne un exemple avec une pièce de monaie : tu jettes en l'air une pièce: face tu notes 1, pile tu notes -1. La valeur moyenne va tendre vers 0 quand le nombre de jetés tend vers l'infini. De là a en déduire que le fait de toujours trouver 0 implique que le hasard n'existe pas, je trouve que tu y vas un peu fort.

[spi100]

PaulB,
J'ai entendu que certains processeurs exploitaient le bruit des signaux électriques pour générer des nombres aléatoires. Est - ce que ça a un rapport avec ta méthode ?

[invite6f0362b8]

le probleme est justement la ...


Pour le commun des mortels, les générateurs de nombre aléatoires actuel suffisent amplement .; donc je vois pas tres bien l'interet de creer de nouveau générateur .;mais bon ...faut bien se creuser la tete un tout petit peu ..

sachant que ceux qui existe actuellement peuvent creer 'aleatoirement' des milliards de milliards de milliards de nombres

donc prendre les desintegrations du plutonium (par ex) comme generateur de nombres aleatoires n'est pas un tres bon exemple pour generer des sequences de type 10^100...

voila pourquoi j'y vais un peu fort..parceque actuellement le defi , c'est justement d'approcher des sequences de ce genre ...

[spi100]

voila pourquoi j'y vais un peu fort..parceque actuellement le defi , c'est justement d'approcher des sequences de ce genre ...

Tu y vas un peu fort surtout car tu confonds valeur moyenne et réalisation d'un évenement.

[invite6f0362b8]

PaulB,
J'ai entendu que certains processeurs exploitaient le bruit des signaux électriques pour générer des nombres aléatoires. Est - ce que ça a un rapport avec ta méthode ?

trés interessant ca ...

vu qu'on a un bruit, donc on a des vagues , donc on a un truc qui va se repeter , tout simplement parceque l'on effectue le meme programme pour generer les nombres ...

[invite6f0362b8]

Je te donne un exemple avec une pièce de monaie : tu jettes en l'air une pièce: face tu notes 1, pile tu notes -1. La valeur moyenne va tendre vers 0 quand le nombre de jetés tend vers l'infini. De là a en déduire que le fait de toujours trouver 0 implique que le hasard n'existe pas, je trouve que tu y vas un peu fort.

sauf que

si tu jettes une piece, tu n'auras pas moins de chance de faire un 1 ou un zero que le jet syuivant

mais si tu regarde les desintegration

tu auras au global plus de chance d'avoir un nombre de desintegration inferieur que la derniere fois que tu as regardé...

[invitebf65f07b]

sauf que

si tu jettes une piece, tu n'auras pas moins de chance de faire un 1 ou un zero que le jet syuivant

mais si tu regarde les desintegration

tu auras au global plus de chance d'avoir un nombre de desintegration inferieur que la derniere fois que tu as regardé...

ben non, c'est pas comme ça qu'il faut faire:

si tu veux comparer le lancer d'une pièce et la désintégration d'un groupe d'atomes radioactifs, alors il faut prendre plusieurs pièces, les lancées chacune régulièrement et éliminer à chaque fois celles qui font pile par exemple.

au final, c'est exactent la même loi de décroissance exponentielle qui décrit le nombre de pièces qu'il reste à chaque instant.

ce qu'il faut comprendre, c'est que cette demi-vie d'un élément radioactif se retrouve parfaitement en supposant qu'un atome a, à chaque instant de durée dt, toujours la même probabilité de se désintégrer.

[spi100]

trés interessant ca ...

vu qu'on a un bruit, donc on a des vagues , donc on a un truc qui va se repeter , tout simplement parceque l'on effectue le meme programme pour generer les nombres ...

Apparement l'electronique c'est pas ton fort. Tu n'a jamais entendu parler du bruit de grenaille dans les signaux electriques ?
Sur les transistors tu as aussi des fluctuations d'intensités dûes à la température, car la probabilités de saut d'un electron de la bande de conduction vers la bande de valence dépend de la température.