Effectivement, rand() % 10 est biaisé, mais tellement peu que ça n'a pas d'importance : ça peut dépendre des machines, mais RAND_MAX doit tourner dans les 2^32. Donc la probabilité de tomber dans un cas problématique (pour %10, entre RAND_MAX arondi à la dizaine inférieure et RAND_MAX) est de l'ordre de 10/RAND_MAX, ce qui doit tourner dans les 10^-10. Du coup, la différence de probabilités est de cet ordre : c'est largement négligeable pour la majorité des applications (voire toutes ?). Ca serait dangereux si on voulait, disons, un nombre entre 0 et RAND_MAX / 1.5, vu que là ça fausse carrément les probabilités (celles de la moitié inférieure ont deux fois plus de chance de sortir que celles de la moitié supérieure)
Je ne connais pas d'algorithmes qui combinent l'équiprobabilité de la méthode de relance et un temps d'éxécution déterministe (et raisonnable, sinon c'est trop facile), mais ça doit exister.
[^] # Re: .
Posté par smeuuh . En réponse au journal Hasard 0.8 : bibliothèque de génération des nombres aléatoires. Évalué à 4.
Je ne connais pas d'algorithmes qui combinent l'équiprobabilité de la méthode de relance et un temps d'éxécution déterministe (et raisonnable, sinon c'est trop facile), mais ça doit exister.