mais pour un générateur produisant des octets, cela n'est pas valide.
RAND_MAX vaut au minimum 2^15 - 1
?! oui et ? on ne parlait pas de rand() (dont personne ne connaît l'implémentation, enfin pas moi) en particulier mais des générateurs en général - et certains produisent des octets, d'autres des int32, d'autres des paquets de 160 bits, etc.
les valeurs centrales sont plus probables, mais sont entre-elles équiprobables;
Non.
pardon ? soit on ne sais plus de quoi on parle (et en effet on a dérivé par rapport au point qui me titillait) soit une "distribution binomiale" des 0 et des 1 conduit nécessairement à une très forte probabilité, utilisant un mot de 32 bits, de trouver 16 bits à '1' et à une très faible prob. de trouver 0 ou 32 bits à '0'; d'où mon point les sommes 15 ou 16 sont (quasi) équiprobables.
qu'importe, quand j'ai parlé de cette façon (somme des bits), je pensais à un calcul de parité pour générer *1* bit aléatoire, j'ai ajouté "pour des petits nombres inf. à 8 ou 16", mon erreur, ma très grande erreur.
lorsque (cas extrême) n vaut 1 ou 2 [...]
Ça peut marcher pour certains cas, mais ça ne marche pas d'une manière générale.
oui, je disais 1 ou 2, pas 7. c'est idiot "de manière générale".
Sylvain.
Richard Delorme a écrit :
mais pour un générateur produisant des octets, cela n'est pas valide.
RAND_MAX vaut au minimum 2^15 - 1
?! oui et ? on ne parlait pas de rand() (dont personne ne
connaît l'implémentation, enfin pas moi) en particulier
mais des générateurs en général - et certains produisent des
octets, d'autres des int32, d'autres des paquets de 160 bits,
etc.
les valeurs centrales sont plus probables, mais sont entre-elles
équiprobables;
Non.
pardon ? soit on ne sais plus de quoi on parle (et en effet
on a dérivé par rapport au point qui me titillait) soit une
"distribution binomiale" des 0 et des 1 conduit nécessairement
à une très forte probabilité, utilisant un mot de 32 bits, de
trouver 16 bits à '1' et à une très faible prob. de trouver 0
ou 32 bits à '0'; d'où mon point les sommes 15 ou 16 sont
(quasi) équiprobables.
qu'importe, quand j'ai parlé de cette façon (somme des bits),
je pensais à un calcul de parité pour générer *1* bit aléatoire,
j'ai ajouté "pour des petits nombres inf. à 8 ou 16", mon erreur,
ma très grande erreur.
lorsque (cas extrême) n vaut 1 ou 2 [...]
Ça peut marcher pour certains cas, mais ça ne marche pas d'une manière
générale.
oui, je disais 1 ou 2, pas 7. c'est idiot "de manière générale".
mais pour un générateur produisant des octets, cela n'est pas valide.
RAND_MAX vaut au minimum 2^15 - 1
?! oui et ? on ne parlait pas de rand() (dont personne ne connaît l'implémentation, enfin pas moi) en particulier mais des générateurs en général - et certains produisent des octets, d'autres des int32, d'autres des paquets de 160 bits, etc.
les valeurs centrales sont plus probables, mais sont entre-elles équiprobables;
Non.
pardon ? soit on ne sais plus de quoi on parle (et en effet on a dérivé par rapport au point qui me titillait) soit une "distribution binomiale" des 0 et des 1 conduit nécessairement à une très forte probabilité, utilisant un mot de 32 bits, de trouver 16 bits à '1' et à une très faible prob. de trouver 0 ou 32 bits à '0'; d'où mon point les sommes 15 ou 16 sont (quasi) équiprobables.
qu'importe, quand j'ai parlé de cette façon (somme des bits), je pensais à un calcul de parité pour générer *1* bit aléatoire, j'ai ajouté "pour des petits nombres inf. à 8 ou 16", mon erreur, ma très grande erreur.
lorsque (cas extrême) n vaut 1 ou 2 [...]
Ça peut marcher pour certains cas, mais ça ne marche pas d'une manière générale.
oui, je disais 1 ou 2, pas 7. c'est idiot "de manière générale".
