Comprendre le "hasard"
Je n'arrive pas à comprendre ce qui est plus aléatoire?
Rand()
OR
Rand() * Rand()
Je trouve ça un casse-tête, pourriez-vous m'aider?
MODIFIER:
Intuitivement, je sais que la réponse mathématique sera qu'ils sont également aléatoires, mais je ne peux m'empêcher de penser que si vous "exécutez l'algorithme de nombre aléatoire" deux fois lorsque vous multipliez les deux ensemble, vous créez quelque chose de plus aléatoire que de le faire simplement. ça une fois.
Juste une clarification
Bien que les réponses précédentes soient correctes chaque fois que vous essayez de repérer le caractère aléatoire d’une variable pseudo-aléatoire ou sa multiplication, vous devez savoir que Random () est généralement uniformément réparti, Random () * Random () n'est pas.
Exemple
Ceci est un échantillon de distribution aléatoire uniforme simulé par une variable pseudo-aléatoire:
BarChart[BinCounts[RandomReal[{0, 1}, 50000], 0.01]]
Alors que c'est la distribution que vous obtenez après avoir multiplié deux variables aléatoires:
BarChart[BinCounts[Table[RandomReal[{0, 1}, 50000] *
RandomReal[{0, 1}, 50000], {50000}], 0.01]]
Donc, les deux sont "aléatoires", mais leur distribution est très différente.
Un autre exemple
While 2 * Random () est uniformément distribué:
BarChart[BinCounts[2 * RandomReal[{0, 1}, 50000], 0.01]]
Random () + Random () n'est pas!
BarChart[BinCounts[Table[RandomReal[{0, 1}, 50000] +
RandomReal[{0, 1}, 50000], {50000}], 0.01]]
Le théorème central limite
Le théorème de la limite centrale indique que la somme de Random () tend à un distribution normale lorsque les termes augmentent .
Avec seulement quatre termes, vous obtenez:
BarChart[BinCounts[Table[RandomReal[{0, 1}, 50000] + RandomReal[{0, 1}, 50000] +
Table[RandomReal[{0, 1}, 50000] + RandomReal[{0, 1}, 50000],
{50000}],
0.01]]
Et ici, vous pouvez voir la route d’un uniforme à une distribution normale en additionnant 1, 2, 4, 6, 10 et 20 variables aléatoires uniformément réparties:
Edit
Quelques crédits
Merci à Thomas Ahle pour avoir signalé dans les commentaires que les distributions de probabilité montrées dans les deux dernières images sont connues sous le nom de distribution d'Irwin-Hall
Merci à Heike pour sa merveilleuse fonction déchirée []
Je suppose que les deux méthodes sont aussi aléatoires bien que mon instinct dirais que Rand() * Rand() est moins aléatoire, car cela générerait plus de zéros. Dès que l'un des _Rand() est 0, le total devient 0
Ni est plus «aléatoire».
Rand() génère un ensemble de nombres prévisibles basés sur une graine pseudo-aléatoire (généralement basée sur l'heure actuelle, qui est en constante évolution). La multiplication de deux nombres consécutifs dans la séquence génère une séquence de nombres différente, mais tout aussi prévisible.
Pour savoir si cela réduira les collisions, la réponse est non. En fait, cela augmentera les collisions du fait de la multiplication de deux nombres où 0 < n < 1. Le résultat sera une fraction plus petite, entraînant un biais dans le résultat vers le bas du spectre.
Quelques explications supplémentaires. Dans ce qui suit, "imprévisible" et "aléatoire" font référence à la capacité de quelqu'un à deviner ce que le prochain chiffre sera basé sur les précédents, c'est-à-dire un Oracle.
La valeur de départ x qui génère la liste de valeurs suivante:
0.3, 0.6, 0.2, 0.4, 0.8, 0.1, 0.7, 0.3, ...
Rand() va générer la liste ci-dessus et Rand() * Rand() va générer:
0.18, 0.08, 0.08, 0.21, ...
Les deux méthodes produiront toujours la même liste de nombres pour la même graine et sont donc également prévisibles par un Oracle. Mais si vous regardez les résultats pour multiplier les deux appels, vous verrez qu'ils sont tous sous 0.3 malgré une distribution décente dans la séquence d'origine. Les chiffres sont biaisés en raison de la multiplication de deux fractions. Le nombre qui en résulte est toujours plus petit, et donc beaucoup plus susceptible d’être une collision bien que tout aussi imprévisible.
Simplification excessive pour illustrer un point.
Supposons que votre fonction aléatoire ne génère que 0 ou 1.
random() est l'un de (0,1), mais random()*random() est l'un de (0,0,0,1)
Vous pouvez clairement voir que les chances d'obtenir un 0 dans le second cas ne sont en aucun cas égales à celles d'obtenir un 1.
Lorsque j'ai posté cette réponse pour la première fois, je souhaitais la garder aussi brève que possible, de sorte qu'une personne qui la lit comprendra d'un coup d'œil la différence entre random() et random()*random(), mais je ne peux m'empêcher de répondre à la question initiale ad litteram:
Qu'est-ce qui est plus aléatoire?
Étant donné que random(), random()*random(), random()+random(), (random()+1)/2 ou toute autre combinaison ne conduisant pas à un résultat fixe ont la même source d'entropie (ou le même état initial dans le cas des générateurs pseudo-aléatoires), la réponse serait qu'ils equal random (La différence réside dans leur distribution). Un exemple parfait que nous pouvons regarder est le jeu de Craps. Le nombre que vous obtenez serait random(1,6)+random(1,6) et nous savons tous que le fait d'obtenir 7 a les meilleures chances, mais cela ne signifie pas que le résultat de lancer deux dés est plus ou moins aléatoire que le résultat de lancer un.
Voici une réponse simple. Considérez le monopole. Vous lancez deux dés à six faces (ou 2d6 pour ceux qui préfèrent la notation de jeu) et prenez leur somme. Le résultat le plus commun est 7 car il y a 6 façons possibles d'obtenir un 7 (1,6 2,5 3,4 4,3 5,2 et 6,1). Alors qu'un 2 ne peut être roulé que sur 1,1. Il est facile de voir que rouler 2d6 est différent du rouler 1d12, même si la plage est la même (en ignorant que vous pouvez obtenir un 1 sur 1d12, le point reste le même). Multiplier vos résultats au lieu de les ajouter va les fausser de la même manière, la plupart de vos résultats étant situés au milieu de la plage. Si vous essayez de réduire les valeurs éloignées, c'est une bonne méthode, mais cela ne vous aidera pas à faire une distribution uniforme.
(Et curieusement, cela augmentera également les jets faibles. En supposant que votre caractère aléatoire commence à 0, vous verrez un pic à 0 car il transformera quoi que l'autre soit en un 0. Considérez deux nombres aléatoires entre 0 et 1 ) et en multipliant.Si l'un des résultats est 0, le tout devient 0, peu importe l'autre résultat. Le seul moyen d'obtenir un 1 est que les deux lancés soient un 1. Dans la pratique, cela n'aurait probablement pas d'importance. mais cela donne un graphique bizarre.)
Le obligatoire xkcd ...
Il serait peut-être utile d’y penser en chiffres plus discrets. Envisagez de générer des nombres aléatoires compris entre 1 et 36, de sorte que vous décidez que le moyen le plus simple consiste à lancer deux dés équitables à 6 faces. Vous obtenez ceci:
1 2 3 4 5 6
-----------------------------
1| 1 2 3 4 5 6
2| 2 4 6 8 10 12
3| 3 6 9 12 15 18
4| 4 8 12 16 20 24
5| 5 10 15 20 25 30
6| 6 12 18 24 30 36
Nous avons donc 36 chiffres, mais tous ne sont pas équitablement représentés, et certains ne se produisent pas du tout. Les nombres proches de la diagonale centrale (du coin inférieur gauche au coin supérieur droit) apparaissent avec la fréquence la plus élevée.
Les mêmes principes qui décrivent la répartition injuste entre les dés s’appliquent également aux nombres en virgule flottante compris entre 0,0 et 1,0.
Certaines choses à propos de "hasard" sont contre-intuitives.
En supposant une distribution plate de Rand(), les distributions suivantes vous permettront d'obtenir des distributions non plates:
- biais élevé:
sqrt(Rand(range^2)) - biais culminant au milieu:
(Rand(range) + Rand(range))/2 - low: biais:
range - sqrt(Rand(range^2))
Il existe de nombreuses autres manières de créer des courbes de biais spécifiques. J'ai fait un test rapide de Rand() * Rand() et vous obtenez une distribution très non linéaire.
"random" vs. "more random" revient un peu à demander quel est le zéro le plus nul.
Dans ce cas, Rand est un PRNG, donc pas totalement aléatoire. (En fait, assez prévisible si la graine est connue). Le multiplier par une autre valeur ne le rend ni plus ni moins aléatoire.
Un vrai RNG de type crypto sera en réalité aléatoire. Et exécuter des valeurs avec n'importe quel type de fonction ne peut pas ajouter plus d'entropie à celle-ci, et peut très probablement supprimer l'entropie, la rendant ainsi plus aléatoire.
La plupart des implémentations de Rand () ont une période. C'est à dire. après un nombre considérable d'appels, la séquence se répète. La séquence de sorties de Rand() * Rand() se répète deux fois plus vite, elle est donc "moins aléatoire" en ce sens.
En outre, sans construction minutieuse, l'exécution de calculs arithmétiques sur des valeurs aléatoires a tendance à être moins aléatoire. Un poster cité ci-dessus "Rand() + Rand() + Rand() ..." (k fois, disons) qui tendra en fait à k fois la valeur moyenne de la plage de valeurs que Rand() renvoie. (C'est une marche aléatoire avec des étapes symétriques par rapport à cela.)
Supposons que votre fonction Rand () renvoie un nombre réel aléatoire uniformément réparti dans la plage [0,1). (Oui, cet exemple autorise une précision infinie. Cela ne changera pas le résultat.) Vous n'avez pas choisi de langue particulière et différentes langues peuvent faire des choses différentes, mais l'analyse suivante tient en compte des modifications pour toute implémentation non perverse de Rand ( ). Le produit Rand() * Rand() est également compris dans la plage [0,1) mais n'est plus distribué de manière uniforme. En fait, le produit est aussi susceptible de se trouver dans l'intervalle [0,1/4) que dans l'intervalle [1/4,1). Plus la multiplication sera biaisée, plus le résultat sera proche de zéro. Cela rend le résultat plus prévisible. En gros traits, plus prévisible == moins aléatoire.
Pratiquement toute séquence d'opérations sur une entrée uniformément aléatoire sera non uniformément aléatoire, conduisant à une prévisibilité accrue. Avec précaution, on peut surmonter cette propriété, mais il aurait alors été plus facile de générer un nombre aléatoire uniformément distribué dans la plage souhaitée plutôt que de perdre du temps en calcul.
Le concept que vous recherchez est "l'entropie", le "degré" de désordre d'une chaîne De bits. L'idée est la plus facile à comprendre en termes de notion "d'entropie maximale".
Une définition approximative d'une chaîne de bits avec une entropie maximale est qu'elle ne peut pas être exprimée exactement en termes de chaîne de bits plus courte (c'est-à-dire en utilisant un algorithme pour Développer la chaîne la plus petite en arrière à la chaîne d'origine).
La pertinence de l’entropie maximale par rapport au hasard provient du fait que Si vous choisissez un nombre "au hasard", vous choisirez certainement un nombre Dont la chaîne de bits est proche de l’entropie maximale, c’est-à-dire qu’elle peut ne soyez pas compressé ..__ Ceci est notre meilleure compréhension de ce qui caractérise un nombre "aléatoire".
Donc, si vous voulez créer un nombre aléatoire à partir de deux échantillons aléatoires qui est "deux fois" comme Aléatoire, vous devez concaténer les deux chaînes de bits ensemble. Pratiquement, vous voudriez simplement insérer les échantillons dans les moitiés haute et basse d'un mot double.
Sur une note plus pratique, si vous vous retrouvez aux prises avec un Rand () merdique, cela peut parfois vous aider à analyser deux ou trois échantillons ensemble --- même si, même si c'est véritablement cassé, cette procédure ne fonctionnera pas. Aidez-moi.
La réponse acceptée est plutôt belle, mais il existe un autre moyen de répondre à votre question. La réponse de PachydermPuncher adopte déjà cette approche alternative et je vais simplement l'étendre un peu.
La façon la plus simple d’envisager la théorie de l’information est la plus petite unité d’information, un seul bit.
Dans la bibliothèque standard C, Rand() renvoie un entier compris entre 0 et Rand_MAX, limite pouvant être définie différemment selon la plate-forme. Supposons que Rand_MAX soit défini comme 2^n - 1 où n soit un entier (cela se produit être le cas dans l'implémentation de Microsoft, où n vaut 15). Ensuite, nous dirions qu’une bonne mise en œuvre renverrait n bits d’information.
Imaginez que Rand() construise des nombres aléatoires en retournant une pièce de monnaie pour trouver la valeur d'un bit, puis en répétant jusqu'à obtenir un lot de 15 bits. Ensuite, les bits sont indépendants (la valeur d’un bit n’influence pas la probabilité que d’autres bits du même lot aient une certaine valeur). Ainsi, chaque bit considéré indépendamment est comme un nombre aléatoire compris entre 0 et 1 inclus, et est "uniformément réparti" sur cette plage (aussi vraisemblablement que 0 soit égal à 1).
L'indépendance des bits garantit que les nombres représentés par des lots de bits seront également distribués uniformément sur leur plage. Ceci est intuitivement évident: s'il y a 15 bits, la plage autorisée est comprise entre 0 et 2^15 - 1 = 32767. Chaque nombre compris dans cette plage est un modèle unique de bits, tel que:
010110101110010
et si les bits sont indépendants, aucun motif n'est plus susceptible de se produire que tout autre motif. Tous les nombres possibles dans la plage sont donc également probables. Et l’inverse est donc vrai: si Rand() produit des nombres entiers uniformément répartis, ces nombres sont constitués de bits indépendants.
Pensez donc à Rand() comme une chaîne de production pour la fabrication de bits, ce qui arrive à les servir par lots de taille arbitraire. Si vous n'aimez pas la taille, divisez les lots en bits individuels, puis rassemblez-les dans les quantités de votre choix (cependant, si vous avez besoin d'une gamme particulière qui n'est pas une puissance de 2, vous devez réduire vos chiffres. , et de loin le moyen le plus simple de le faire est de convertir en virgule flottante).
Pour revenir à votre suggestion initiale, supposons que vous souhaitiez passer de lots de 15 à 30, demandez à Rand() le premier numéro, décalez-le de 15 bits, puis ajoutez-y un autre Rand(). C'est un moyen de combiner deux appels à Rand() sans perturber une distribution uniforme. Cela fonctionne simplement parce qu'il n'y a pas de chevauchement entre les emplacements où vous placez les bits d'information.
Cela est très différent d’étirer la gamme de Rand() en la multipliant par une constante. Par exemple, si vous voulez doubler la plage de Rand(), vous pouvez le multiplier par deux - mais à présent, vous n'obtenez que des nombres pairs et jamais des nombres impairs! Ce n'est pas exactement une distribution en douceur et peut être un problème grave en fonction de l'application, par exemple. un jeu de type roulette permettant supposément des paris pairs/impairs. (En pensant en bits, vous évitiez intuitivement cette erreur, car vous réaliseriez que multiplier par deux revient à déplacer les bits à gauche (signification plus importante) d'un endroit et à combler le vide avec zéro. Donc, évidemment, la quantité d’information est la même - elle s’est déplacée un peu).
De telles lacunes dans les plages de nombres ne peuvent pas être traitées dans les applications de nombres à virgule flottante, car les plages de nombres à virgule flottante comportent intrinsèquement des lacunes qui ne peuvent tout simplement pas être représentées: un infini il existe un nombre de nombres réels manquants dans l’espace entre deux nombres à virgule flottante représentable! Nous devons donc apprendre à vivre avec des lacunes de toute façon.
Comme d’autres l’ont prévenu, l’intuition est risquée dans ce domaine, en particulier parce que les mathématiciens ne peuvent résister à l’attrait des nombres réels, des choses horriblement déroutantes, pleines d’infinies et de paradoxes apparents.
Mais au moins, si vous le croyez en termes de bits, votre intuition pourrait vous amener un peu plus loin. Les bits sont vraiment faciles - même les ordinateurs peuvent les comprendre.
Comme d'autres l'ont dit, la réponse courte facile est: non, ce n'est pas plus aléatoire, mais cela change la distribution.
Supposons que vous jouiez à un jeu de dés. Vous avez des dés complètement justes et aléatoires. Les jets de dés seraient-ils "plus aléatoires" si, avant chaque lancer de dés, vous mettiez d'abord deux dés dans un bol, que vous le secouiez, que vous preniez l'un des dés au hasard, puis que vous lanciez celui-ci? Clairement, cela ne ferait aucune différence. Si les deux dés donnent des nombres aléatoires, alors choisir au hasard l'un des deux dés ne fera aucune différence. Dans les deux cas, vous obtiendrez un nombre aléatoire compris entre 1 et 6 avec une distribution égale sur un nombre suffisant de rouleaux.
Je suppose que dans la vie réelle, une telle procédure pourrait être utile si vous soupçonniez que les dés n'étaient PAS équitables. Si, par exemple, les dés sont légèrement déséquilibrés, on a tendance à donner 1 plus souvent que 1/6 du temps, et un autre tendance à donner 6 inhabituellement souvent, alors choisir au hasard entre les deux aurait tendance à masquer le biais. (Bien que dans ce cas, 1 et 6 soient toujours supérieurs à 2, 3, 4 et 5. Eh bien, je suppose que cela dépend de la nature du déséquilibre.)
Il existe de nombreuses définitions du hasard. Une définition d'une série aléatoire est qu'il s'agit d'une série de nombres produits par un processus aléatoire. Selon cette définition, si je lance un dé juste 5 fois et que je reçois les nombres 2, 4, 3, 2, 5, il s’agit d’une série aléatoire. Si je lance ensuite le même dé mort 5 fois de plus et que j'ai 1, 1, 1, 1, 1, alors c'est aussi une série aléatoire.
Plusieurs affiches ont souligné que les fonctions aléatoires sur un ordinateur ne sont pas vraiment aléatoires, mais plutôt pseudo-aléatoires, et que si vous connaissez l'algorithme et le germe, ils sont complètement prévisibles. C'est vrai, mais la plupart du temps, complètement hors de propos. Si je mélange un jeu de cartes et que je les retourne ensuite un par un, cela devrait être une série aléatoire. Si quelqu'un jette un coup d'œil sur les cartes, le résultat sera tout à fait prévisible, mais selon la plupart des définitions de hasard, cela ne le rendra pas moins aléatoire. Si la série passe avec succès des tests statistiques d’aléatoire, le fait que j’ai jeté un coup d’œil aux cartes ne changera rien. En pratique, si nous misons de grosses sommes d’argent sur votre capacité à deviner la prochaine carte, le fait que vous ayez jeté un coup d’œil aux cartes est très important. Si nous utilisons la série pour simuler les choix de menus des visiteurs de notre site Web afin de tester les performances du système, le fait que vous avez jeté un coup d'œil ne fera aucune différence. (Tant que vous ne modifiez pas le programme pour tirer parti de cette connaissance.)
MODIFIER
Je ne pense pas pouvoir commenter le problème de Monty Hall, alors je vais mettre à jour ma réponse.
Pour ceux qui n'ont pas lu le lien Belisarius, l'essentiel est le suivant: un candidat au jeu télévisé a le choix entre 3 portes. Derrière l'un se cache un prix précieux, derrière les autres, il y a quelque chose d'inutile. Il prend la porte n ° 1. Avant de révéler s'il s'agit d'un gagnant ou d'un perdant, l'hôte ouvre la porte 3 pour indiquer qu'il s'agit d'un perdant. Il donne ensuite au candidat la possibilité de passer à la porte n ° 2. Le concurrent doit-il faire ceci ou pas?
La réponse, qui choque l'intuition de beaucoup de gens, est qu'il devrait basculer. La probabilité que son choix initial soit le gagnant est de 1/3, que l'autre porte est gagnante, de 2/3. Mon intuition initiale, ainsi que celle de nombreuses autres personnes, est qu’il n’y aurait aucun gain à changer, que les probabilités viennent tout juste d’être changées à 50:50.
Après tout, supposons que quelqu'un ait allumé le téléviseur juste après que l'hôte ait ouvert la porte perdue. Cette personne verrait deux portes fermées restantes. En supposant qu'il connaisse la nature du jeu, il dirait qu'il y a une chance sur deux que chaque porte cache le prix. Comment les chances pour le spectateur peuvent-elles être de 1/2: 1/2 alors que les chances pour le concurrent sont de 1/3: 2/3?
Il fallait vraiment que je réfléchisse à cela pour que mon intuition prenne forme. Pour vous en assurer, comprenez que lorsque nous parlons de probabilités dans un problème comme celui-ci, nous entendons la probabilité que vous attribuez en fonction des informations disponibles. Pour un membre de l'équipage qui a placé le prix derrière, disons, la porte n ° 1, la probabilité que le prix soit derrière la porte n ° 1 est de 100% et la probabilité qu'il se trouve derrière l'une ou l'autre des deux portes est égale à zéro.
Les chances du membre de l'équipage sont différentes de celles du concurrent car il sait quelque chose que le candidat ignore, à savoir quelle porte il a cachée. De même, les chances du participant sont différentes de celles du spectateur, car il sait quelque chose que le spectateur ignore, à savoir quelle porte il a initialement choisie. Ce n'est pas sans importance, car le choix par l'hôte de la porte à ouvrir n'est pas aléatoire. Il n'ouvrira pas la porte choisie par le concurrent et il n'ouvrira pas la porte qui cache le prix. Si ce sont la même porte, cela lui laisse deux choix. Si ce sont des portes différentes, il n'en reste qu'une.Alors, comment pouvons-nous arriver avec 1/3 et 2/3? Lorsque le concurrent avait choisi une porte, il avait 1/3 de chance de choisir le gagnant. Je pense que cela est évident. Cela signifie qu'il y avait une chance sur deux que l'une des autres portes soit gagnante. Si l'hôte lui offre la possibilité de passer sans donner d'informations supplémentaires, il n'y aurait aucun gain. Encore une fois, cela devrait être évident. Mais une façon de voir les choses est de dire qu’il a une chance sur deux de gagner en changeant de poste. Mais il a 2 alternatives. Ainsi, chacun n'a que 2/3 divisé par 2 = 1/3 chance d'être le gagnant, ce qui n'est pas meilleur que son choix d'origine. Bien sûr, nous connaissions déjà le résultat final, cela ne fait que le calculer différemment.
Mais maintenant, l'hôte révèle qu'un de ces deux choix n'est pas le gagnant. Donc, sur les 2/3 des chances qu’une porte qu’il n’a pas choisies soit gagnante, il sait maintenant que l’une des deux alternatives n’est pas celle-là. L'autre pourrait être ou ne pas être. Donc, il n'a plus deux tiers divisés par 2. Il a zéro pour la porte ouverte et 2/3 pour la porte fermée.
But now the Host reveals that one of those two choices is not the winner. So of the 2/3 chance that a door he didn't pick is the winner, he now knows that 1 of the 2 alternatives isn't it. The other might or might not be. So he no longer has 2/3 dividied by 2. He has zero for the open door and 2/3 for the closed door.
Considérez que vous avez un problème simple de retournement de pièce où même est considéré comme une tête et impaire est considéré comme une queue. L'implémentation logique est:
Rand() mod 2
Sur une distribution suffisamment grande, le nombre de nombres pairs doit être égal au nombre de nombres impairs.
Maintenant, considérons un léger tweak:
Rand() * Rand() mod 2
Si l'un des résultats est pair, alors le résultat doit être complet. Considérez les 4 résultats possibles (pair * pair = pair, pair * impair = pair, impair * pair = pair, impair * impair = impair). Maintenant, sur une distribution assez large, la réponse devrait être même 75% du temps.
Je parierais si j'étais toi.
Ce commentaire explique davantage pourquoi vous ne devriez pas implémenter une fonction aléatoire personnalisée basée sur votre méthode plutôt qu’une discussion sur les propriétés mathématiques de l’aléatoire.
En cas de doute sur le sort des combinaisons de vos nombres aléatoires, vous pouvez utiliser les leçons que vous avez apprises en théorie statistique.
Dans la situation de OP, il veut savoir quel est le résultat de X * X = X ^ 2 où X est une variable aléatoire répartie le long de l'uniforme [0,1]. Nous allons utiliser la technique CDF puisqu'il s'agit simplement d'un mappage un à un.
Depuis X ~ Uniform [0,1], cdf est: fX(x) = 1 Nous voulons la transformation Y <- X ^ 2 donc y = x ^ 2 Trouver l'inverse x (y): sqrt (y) = x cela nous donne x en fonction de y . Ensuite, trouvez le dérivé dx/dy: d/dy (sqrt (y)) = 1/(2 sqrt (y))
La distribution de Y est donnée par: fY(y) = fX(x (y)) | dx/dy | = 1/(2 sqrt (y))
Nous n'avons pas encore terminé, nous devons obtenir le domaine de Y. Puisque 0 <= x <1, 0 <= x ^ 2 <1so Y est compris dans l'intervalle [0, 1) . Si vous voulez vérifier si le pdf de Y est bien un pdf, intégrez-le sur le domaine: Intégrez 1/(2 sqrt (y)) de 0 à 1 et effectivement, il apparaît en tant que 1. Également, notez la forme de ladite fonction ressemble à ce que belisarious posté.
En ce qui concerne des choses comme X1 + X2 + ... + Xn, (où Xje ~ Uniforme [0,1]), nous pouvons simplement faire appel au théorème de la limite centrale qui fonctionne pour toute distribution dont les moments existent. C'est pourquoi le test Z existe réellement.
Parmi les autres techniques permettant de déterminer le pdf résultant, on peut citer la transformation jacobienne (qui est la version généralisée de la technique cdf) et la technique MGF.
EDIT: Pour clarifier, notez que je parle de la distribution de la transformation résultante et non de son randomness. C'est en fait pour une discussion séparée. De plus, ce que j'ai réellement dérivé était pour (Rand ()) ^ 2. Pour Rand () * Rand (), c'est beaucoup plus compliqué, ce qui, dans tous les cas, n'aboutira pas à une distribution uniforme de toutes sortes.
Ce n'est pas exactement évident, mais Rand() est généralement plus aléatoire que Rand()*Rand(). Ce qui est important, c’est que ce n’est pas vraiment très important pour la plupart des utilisations.
Mais tout d’abord, ils produisent des distributions différentes. Ce n'est pas un problème si c'est ce que vous voulez, mais c'est important. Si vous avez besoin d'une distribution particulière, alors ignorez la question «qui est plus aléatoire». Alors pourquoi Rand() est-il plus aléatoire?
La raison principale pour laquelle Rand() est plus aléatoire (en supposant que cela produit des nombres aléatoires à virgule flottante avec la plage [0..1], ce qui est très courant) est que lorsque vous multipliez deux FP nombres avec Beaucoup d'informations dans la mantisse, vous obtenez une perte d'informations à la fin; il n'y a tout simplement pas assez de bits dans un flottant à double précision IEEE pour contenir toutes les informations contenues dans deux flotteurs à double précision IEEE sélectionnés de manière uniforme dans [0..1], et ces bits d'informations supplémentaires sont perdus. Bien sûr, peu importe puisque vous (probablement) n'allez pas utiliser cette information, mais la perte est réelle. De plus, la distribution que vous produisez n'a pas vraiment d'importance (c'est-à-dire l'opération que vous utilisez pour effectuer la combinaison). Chacun de ces nombres aléatoires contient (au mieux) 52 bits d'informations aléatoires - c'est ce que peut contenir un double IEEE - et si vous combinez deux ou plus en un, vous êtes toujours limité à avoir au maximum 52 bits d'informations aléatoires.
La plupart des utilisations de nombres aléatoires n'utilisent même pas autant de valeurs aléatoires que celles réellement disponibles dans la source aléatoire. Obtenez un bon PRNG et ne vous inquiétez pas trop à ce sujet. (Le niveau de “bonté” dépend de ce que vous en faites; vous devez faire attention lorsque vous effectuez une simulation ou une cryptographie Monte Carlo, mais vous pouvez probablement utiliser la norme PRNG car elle est généralement beaucoup plus rapide.)
Les aléas flottants sont basés, en général, sur un algorithme qui produit un entier compris entre zéro et une certaine plage. En tant que tel, en utilisant Rand () * Rand (), vous dites essentiellement int_Rand () * int_Rand ()/Rand_max ^ 2 - ce qui signifie que vous excluez tout nombre premier/Rand_max ^ 2.
Cela change la distribution randomisée de manière significative.
Rand () est uniformément distribué sur la plupart des systèmes et difficile à prévoir s'il est correctement ensemencé. Utilisez-le sauf si vous avez une raison particulière de faire du calcul (c'est-à-dire, façonner la distribution selon une courbe nécessaire).
Multiplier les nombres aboutirait à une gamme de solutions plus petite en fonction de l'architecture de votre ordinateur.
Si l'écran de votre ordinateur affiche 16 chiffres, Rand() serait, par exemple, 0.1234567890123 Multiplié par une seconde Rand(), 0.1234567890123, donnerait quelque chose à 0.0152415 Vous trouveriez certainement moins de solutions si vous répétiez l'expérience 10 fois .
La plupart de ces distributions se produisent parce que vous devez limiter ou normaliser le nombre aléatoire.
Nous le normalisons pour qu'il soit tout à fait positif, s'insère dans une plage et même dans les limites de la taille de la mémoire pour le type de variable attribué.
En d'autres termes, comme nous devons limiter l'appel aléatoire entre 0 et X (X étant la taille limite de notre variable), nous aurons un groupe de nombres "aléatoires" compris entre 0 et X.
Maintenant, lorsque vous ajoutez le nombre aléatoire à un autre nombre aléatoire, la somme se situera entre 0 et 2X ... ceci détourne les valeurs des points Edge (la probabilité d'ajouter deux petits nombres ensemble et deux grands nombres est très petite quand vous avez deux nombres aléatoires sur une large plage).
Pensez au cas où vous aviez un nombre proche de zéro et que vous l'ajoutez avec un autre nombre aléatoire, il deviendra certainement plus grand et plus éloigné de 0 (cela sera vrai aussi bien pour les grands nombres que pour les deux grands (nombres proches de X) renvoyés deux fois par la fonction Aléatoire.
Maintenant, si vous deviez configurer la méthode aléatoire avec des nombres négatifs et des nombres positifs (s'étendant de manière égale sur l'axe zéro), cela ne serait plus le cas.
Disons, par exemple, RandomReal({-x, x}, 50000, .01), vous obtiendrez une distribution égale des nombres avec un côté positif et si vous additionnez les nombres aléatoires, ils conserveraient leur caractère "aléatoire".
Maintenant, je ne suis pas sûr de savoir ce qui se passerait avec Random() * Random() avec une plage négative à positive ... ce serait un graphique intéressant à voir ... mais je dois revenir à l'écriture de code maintenant. :-P
More random n'existe pas. C'est aléatoire ou pas. Aléatoire signifie "difficile à prédire". Cela ne signifie pas non déterministe. Random () et random () * random () sont également aléatoires si random () est random. La distribution est hors de propos en ce qui concerne le hasard. Si une distribution non uniforme se produit, cela signifie simplement que certaines valeurs sont plus probables que d'autres; ils sont encore imprévisibles.
Comme le pseudo-aléatoire est impliqué, les nombres sont très déterministes. Cependant, le pseudo-aléatoire est souvent suffisant dans les modèles de probabilité et les simulations. Il est bien connu que rendre compliqué un générateur de nombres pseudo-aléatoires le rend difficile à analyser. Il est peu probable que le hasard soit amélioré. cela lui fait souvent échouer les tests statistiques.
Les propriétés souhaitées des nombres aléatoires sont importantes: répétabilité et reproductibilité, caractère statistique de l’aléatoire, (généralement) uniformément réparties et une grande période en font quelques-unes.
Concernant les transformations sur des nombres aléatoires: Comme quelqu'un l'a dit, la somme de deux ou plus uniformément réparties donne une distribution normale. C'est le théorème de limite central additive. Cela s'applique quelle que soit la distribution source tant que toutes les distributions sont indépendantes et identiques. Le théorème limite central multiplicative dit que le produit de deux ou plus de deux variables aléatoires indépendantes et réparties de manière indentique est lognormal. Le graphe créé par quelqu'un d'autre a l'air exponentiel, mais il est vraiment lognormal. Donc random () * random () est lognormalement distribué (bien qu'il puisse ne pas être indépendant puisque les nombres sont extraits du même flux). Cela peut être souhaitable dans certaines applications. Cependant, il est généralement préférable de générer un nombre aléatoire et de le transformer en un nombre lognormalement distribué. Random () * random () peut être difficile à analyser.
Pour plus d'informations, consultez mon livre sur www.performorama.org. Le livre est en construction, mais le matériel pertinent est là. Notez que les numéros de chapitre et de section peuvent changer au fil du temps. Chapitre 8 (théorie des probabilités) - sections 8.3.1 et 8.3.3, chapitre 10 (nombres aléatoires).
Nous pouvons comparer deux tableaux de nombres relatifs à l’aléatoire en utilisant Complexité de Kolmogorov Si la séquence de nombres ne peut pas être comprimée, c’est le plus aléatoire que nous puissions atteindre à cette longueur ... Je sais que ce type de mesure est davantage une option théorique ...
En fait, lorsque vous y réfléchissez, Rand() * Rand() est moins aléatoire que Rand(). Voici pourquoi.
Essentiellement, il y a le même nombre de nombres impairs que de nombres pairs. Et en disant que 0,04325 est impair, et que 0,388 est pair, et que 0,4 est pair et que 0,15 est impair,
Cela signifie que Rand() a une chance égale d'être un nombre décimal pair ou impair.
Par contre, Rand() * Rand() a ses chances empilées un peu différemment… .. Disons:
double a = Rand();
double b = Rand();
double c = a * b;
a et b ont tous les deux une chance sur deux d'être pair ou impair. Sachant que
- même * même = même
- pair * impair = pair
- impair * impair = impair
- impair * même = même
signifie qu'il y a 75% de chance que c soit pair, alors que seulement 25% de chance est impair, rendant la valeur de Rand() * Rand() plus prévisible que Rand(), donc moins aléatoire.
Utilisez un registre à décalage à retour linéaire (LFSR) qui implémente un polynôme primitif.
Le résultat sera une séquence de 2 ^ n nombres pseudo-aléatoires, c'est-à-dire que rien ne se répète dans la séquence où n est le nombre de bits dans le LFSR ... donnant lieu à une distribution uniforme.
http://en.wikipedia.org/wiki/Linear_feedback_shift_register http: //www.xilinx.com/support/documentation/application_notes/xapp052.pdf
Utilisez une graine "aléatoire" basée sur les microsecs de l'horloge de votre ordinateur ou peut-être un sous-ensemble du résultat md5 sur des données changeant continuellement dans votre système de fichiers.
Par exemple, une LFSR 32 bits générera 2 ^ 32 numéros uniques en séquence (aucun 2 identiques) à partir d'une graine donnée. La séquence sera toujours dans le même ordre, mais le point de départ sera différent (évidemment) pour une graine différente . Donc, si une séquence qui se répète éventuellement entre les semis n’est pas un problème, cela pourrait être un bon choix.
J'ai utilisé des LFSR 128 bits pour générer des tests aléatoires dans des simulateurs matériels en utilisant une graine qui correspond aux résultats de md5 sur des données système en constante évolution.
En supposant que Rand() renvoie un nombre compris entre [0, 1), il est évident que Rand() * Rand() sera biaisé vers 0. Cela est dû au fait que multiplier x par un nombre entre [0, 1) donnera un nombre inférieur à x. Voici la distribution de 10000 plus nombres aléatoires:
google.charts.load("current", { packages: ["corechart"] });
google.charts.setOnLoadCallback(drawChart);
function drawChart() {
var i;
var randomNumbers = [];
for (i = 0; i < 10000; i++) {
randomNumbers.Push(Math.random() * Math.random());
}
var chart = new google.visualization.Histogram(document.getElementById("chart-1"));
var data = new google.visualization.DataTable();
data.addColumn("number", "Value");
randomNumbers.forEach(function(randomNumber) {
data.addRow([randomNumber]);
});
chart.draw(data, {
title: randomNumbers.length + " Rand() * Rand() values between [0, 1)",
legend: { position: "none" }
});
}<script src="https://www.gstatic.com/charts/loader.js"></script>
<div id="chart-1" style="height: 500px">Generating chart...</div>Si Rand() renvoie un entier compris entre [x, y], la distribution est la suivante. Notez le nombre de valeurs impaires vs paires:
google.charts.load("current", { packages: ["corechart"] });
google.charts.setOnLoadCallback(drawChart);
document.querySelector("#draw-chart").addEventListener("click", drawChart);
function randomInt(min, max) {
return Math.floor(Math.random() * (max - min + 1)) + min;
}
function drawChart() {
var min = Number(document.querySelector("#Rand-min").value);
var max = Number(document.querySelector("#Rand-max").value);
if (min >= max) {
return;
}
var i;
var randomNumbers = [];
for (i = 0; i < 10000; i++) {
randomNumbers.Push(randomInt(min, max) * randomInt(min, max));
}
var chart = new google.visualization.Histogram(document.getElementById("chart-1"));
var data = new google.visualization.DataTable();
data.addColumn("number", "Value");
randomNumbers.forEach(function(randomNumber) {
data.addRow([randomNumber]);
});
chart.draw(data, {
title: randomNumbers.length + " Rand() * Rand() values between [" + min + ", " + max + "]",
legend: { position: "none" },
histogram: { bucketSize: 1 }
});
}<script src="https://www.gstatic.com/charts/loader.js"></script>
<input type="number" id="Rand-min" value="0" min="0" max="10">
<input type="number" id="Rand-max" value="9" min="0" max="10">
<input type="button" id="draw-chart" value="Apply">
<div id="chart-1" style="height: 500px">Generating chart...</div>