Générer un positif aléatoirement
Bonjour ,
Je veux créer un algorithme qui génére un positif aléatoirement , puis s'arréte quand c'est fait .
Je sais que je dois utiliser une boucle , mais je ne sais pas comment ?
Avez-vous une piste , des idées ?
En gros ça donnerait :
Code:
1
2
3
4
5
6
7
8
|
loop
choix_positif : Positive ;
--ensuite une valeur exacte positive est généré
exit loop |
Générer un positif aléatoirement
Bonsoir,
Citation:
Envoyé par
Flodelarab
Le lien renvoie à un article intéressant, qui donne envie d'approfondir le sujet (pour moi difficile, compte tenu de mes lacunes), et d'effectuer des tests graphiques sur des séries de nombres pseudo-aléatoires: voilà de nouvelles idées de programmation !
Citation:
Envoyé par
Flodelarab
Il faut casser le mythe : Les ordinateurs ne tirent pas de nombres aléatoires. On parle de "pseudo-aléatoires". Le processus est totalement déterministe. Mais on prend une part de l'information déterministe dont la logique nous échappe pour faire comme si c'était aléatoire.
Exemple: je tire 1 si le nombre de millisecondes est impair et 0 s'il est pair. (Choisis ton horloge). J'obtiens:
0110101011101010001101010101
Et voilà! Un nombre apparemment totalement aléatoire !
Cette suite l'est - à quelques restrictions près, liées à aux conditions matérielles d'éxécution - parce que les résultats obtenus découlent de la rencontre de deux séries causales indépendantes: le fonctionnement de l'horloge interne, et l'appui sur la touche déclenchant la sortie du résultat. Procéder de la sorte, c'est utiliser l'ordinateur comme un système physique, ici une roulette qui serait graduée de 0 à 999, avec des cases peintes en couleurs alternées. On obtiendrait encore un résultat semblable en demandant le nombre d'octets (modulo N) qui mesure le volume des fichiers temporaires accumulés dans le cache du navigateur (à condition bien sûr que celui-ci n'ait pas été vidé quelques instants auparavant, et que N ne soit pas trop grand) ... C'est en gros ce qui est fait lors de l'appel de randomize (ou son équivalent).
C'est évidemment plus rapide et moins fatigant que d'aller sur le palier noter le nombre de litres affichés par le compteur de gaz, ou de se rendre à la plus proche station de carburant pour lire le nombre de centimes sur l'une des pompes (1) ... toutes machines à "fabriquer du hasard", qui répondent honorablement à tous les tests connus, de la même façon que le lancer de dés, le tirage de cartes (2) ou la consultation du bilan mensuel de votre carte bancaire (en centimes d'euros, modulo 1000).
Cordialement, W.
(1) procédés un peu rustres, mais diététiquement salutaires pour les accros de la programmation, peu soucieux de la promenade quotidienne.
(2) le paquet ayant été battu par une personne à l'honnêteté irréprochable, cela va de soi.
Générer un positif aléatoirement, ou: du bon usage d'un compteur à gaz
Bonjour, et bonne année à tous ! :D
Citation:
Envoyé par
dourouc05
@wiwaxia : tes techniques génèrent-elles des nombres uniformément répartis ? Pour ton compteur à gaz, tu as une évolution temporelle : si tu connais la valeur précédente, tu peux déjà estimer pas mal sur la prochaine valeur, sauf peut-être sur les dernières décimales, en fonction de tes besoins. Tu risques donc de générer certains nombres plus souvent que d'autres, sans une totale indépendance statistique — pas des propriétés attendues, en général.
C'est exact, et il m'a fallu ressortir d'anciens relevés pour étayer ma réponse de données réelles.
Soit un pavillon isolé, dont la chaudière consomme en moyenne 6.4 m3 de gaz par jour en automne, avec une variation de +-25 % en fonction de la température extérieure. Deux relevés consécutifs espacés d'une semaine conduiront donc par différence à un volume de valeur moyenne Vm = 44.8 m3, et d'incertitude absolue Ev1 = 0.25*Vm = 11.2 m3; ajoutons à ceci un éventuel décalage horaire (pour le second relevé) de +-3 heures, susceptible de faire varier le résultat de +-6.4*(3/24) = +-0.8 m3: le résultat final sera donc affecté d'une incertitude totale Ev = Ev1 + Ev2 = 12.0 m3, et le volume affiché situé dans un intervalle de centre (Vm) et de largeur Lv = 2*Ev = 24.0 m3 = 24000 L, soit 24 séquences complètes des 3 décimales <abc> donnant le volume résiduel, en litres.
On devine que la probabilité de sortie d'un triplet donné (par ex. 827) est alors quasiment fixe, et très proche de 1/1000.
Je n'ai malheureusement pas de lien sous la main, pour une illustration. Ce n'est cependant pas très compliqué:
a) Imaginer une fonction continue de densité de probabilité, nulle en-dehors de [V1 = 32.8 m3 ; V2 = 56.8 m3] , et maximale en x = Vm = (V1 + V2)/2 ;
b) découper l'aire sous-jacente, par définition égale à l'unité, en 24000 (!) tranches verticales de largeur h = 0.001, et correspondant au semi-ouvert
[Xk = V1 + h*(k-1) ; Xk+1 = Xk + h[ avec k entier naturel situé dans [1 ; 24000];
c) la probabilité de sortie d'un triplet donné <abc> (par ex. 827) est alors donnée par la somme des aires des 24 tranches correspondantes:
P(<abc>) = A(32.827) + A(33.827) + A(34.827) + ... + A(55.827) .
Le fonctionnement de la machine est bien associé à un autre phénomène, non (ou mal) maîtrisé: ici la météo (principalement), et le délai (Dt) séparant les deux repérages.
L'exemple ci-dessus montre qu'un système physique générateur de hasard se caractérise par un temps mort (Tm) en-dessous duquel la distribution des résultats successifs s'éloigne beaucoup de l'uniformité statistique; si l'on note (Tc = V0/6.4 = 0.156 j = 3.75 h) la période d'un cycle correspondant à l'écoulement d'un volume V0 = 1 m3 = 1000 L, donc au premier retour à <000> des 3 derniers chiffres affichés, le délai (Dt) précédemment évoqué doit ainsi vérifier: ─ Dt >> Tc ,
─ et en ce qui concerne l'incertitude associée au résultat: Ev >> V0 , soit encore: Ev*(6.4*Dt/Vm) >> V0 ,
ce qui donne: Dt >> (V0/6.4)*(Vm/Ev) = 3.73 * Tc = 0.583 j = 14.0 h ,
et conduit à choisir à l'estime un temps mort Tm ~ 10 * Tc = 37.5 h = 1.56 j .
L'opportunité d'une telle limite dépend évidemment de la loi de densité de probabilité sur le domaine [V1 ; V2] , loi qu'il faut connaître pour comparer P(<abc>) à la valeur idéale (1/1000) attendue.
Prenons par exemple la plus simple des fonctions de densité de probabilité, le polynôme du 2nd degré s'anullant aux bornes de l'intervalle [a; b]:
d(x) = M*(x - a)*(b - x) , avec M = 6/(b - a)3
et admettant pour primitive: F(x) = M*(-a*b*x + (a+b)*x2/2 - x3/3) , laquelle vérifie F(b) - F(a) = 1 .
L'aire de la tranche construite sur le domaine [v, v+h[ est alors: A(v, v+h) = F(v+h) - F(v) = h*[d(v) + M*((a+b)/2 - h/3 - v)] ; et l'on obtient en reprenant l'exemple précédent (V1 = 32.8 m3 , V2 = 56.8 m3 , M = 0.006/243 m-3):
P(<827>) = 0.99854E-3 - soit un écart relatif de 1.46E-3 par rapport à la valeur idéale (1E-3);
Les valeurs extrêmes ne diffèrent aussi que de 1 à 2 millièmes:
P(<800>) = 0.99827E-3 , P(<300>) = 1.00087E-3 , et le système envisagé est bien susceptible de fournir (dans les conditions précisées plus haut) une liste de valeurs aléatoires; on ne pourrait observer des écarts significatifs qu'au delà de plusieurs dizaines de milliers de termes (soit au minimum 43 ans ...).
Le recours à l'horloge interne égrainant les millisecondes, avec une période de cycle (Tc) ramenée à une seconde, apparaît sous cet aspect incomparablement plus souple que le compteur à gaz (ce n'est sûrement pas un scoop ! :mrgreen: ), et il est intéressant d'observer l'évolution des probabilités en fonction de l'étalement des valeurs enregistrées.
La dispersion des résultats découle ici de la variabilité (inconnue, mais seulement encadrée) de l'intervalle de temps (Dt) séparant deux frappes consécutives de la touche déclenchant l'enregistrement de l'heure.
La valeur obtenue est ici le temps quotidien affiché par l'horloge, à priori situé dans l'intervalle: [V1 = N1*Tc , V2 = V1 + N*Tc], ce qui implique: Vm = (N1 + N/2) * Tc et Lv = N * Tc ; le recours aux entiers positifs (N, N1) permet d'éliminer les discontinuités, donc des complications inutiles. Par ailleurs, la séquence des décimales étant conservée par décalage du temps d'un nombre entier de secondes, on peut imposer au graphe de densité une translation horizontale conduisant à une équation plus simple; on posera ainsi:
a = V1 - N1*Tc = 0 ; b = [V2 - N1*Tc = N * Tc = Lv , pour obtenir l'expression numérique de la probabilité:
A(x, x+h) = M*(x*(N - x) + h(p - x)) , avec h = 1E-3 , M = (6*h) / N3 , p = (N/2) - (h/3) et 0 <= x < N*Tc .
Les résultats obtenus confirment ce qui a été indiqué plus haut (il y a une symétrie par rapport à la médiane 499.5 qui dispense de la moitié des calculs); ils se rapprochent d'autant plus de la vapeur idéale (1/1000) que le nombre (N) de cycles contenus dans l'intervalle est plus élevé; au-delà de N = 10 , les écarts observés deviennent inférieurs à 1 % (ils apparaissent d'ailleurs proportionnels à (1/N2)):
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
| Valeurs de 1000*P(<abc>)
<abc> 000 250 499
N = 1 0.002998 1.126498 1.449998
3 0.889222 1.014055 1.055555
10 0.990030 1.001265 1.005000
32 0.999026 1.000124 1.000488
100 0.999900 1.000013 1.000050 |
Il résulte de ce qui précède que des appels manuels successifs de l'horloge interne fournissent des résultats aléatoires, s'ils sont espacés d'au moins une minute et indépendants de tout affichage externe du temps: l'exécutant ne doit pas percevoir un signal sonore ou lumineux énumérant les secondes !
