C'est le rand() modulo X qui pose des soucis de non-équiprobabilité si le modulo n'est pas un diviseur de MAX_RAND.
Il se peut (j'en sais rien, je te laisse vérifier) que parseInt utilise ce système de modulo et donc, il n'est peut-etre pas exactement équilibré.
Egalement, le problème survient si tu utilises l'arrondis du rand() (décimal):
round(rand()*K)
Le nombre "0" sera tiré si rand() vaut entre 0 et 1/2K. Le nombre 1 sera tiré si rand() vaut entre 1/2K et 3/2K.
Donc, la "plage" de nombres pour 0 est 2x plus grande que pour 1: 0 a 50% de chances de moins d'être tiré que les autres nombres.
Pour compléter Sephi, en utilisant Math.random():
Il se peut (j'en sais rien, je te laisse vérifier) que parseInt utilise ce système de modulo et donc, il n'est peut-etre pas exactement équilibré.
Egalement, le problème survient si tu utilises l'arrondis du rand() (décimal):
round(rand()*K)
Le nombre "0" sera tiré si rand() vaut entre 0 et 1/2K. Le nombre 1 sera tiré si rand() vaut entre 1/2K et 3/2K.
Donc, la "plage" de nombres pour 0 est 2x plus grande que pour 1: 0 a 50% de chances de moins d'être tiré que les autres nombres.
Pour compléter Sephi, en utilisant Math.random():
Code :
double x = Math.random()*(max + 1 - min) + min;
// x vaut de min inclus à max+1 exclus, et x est équiprobable mais décimal
int y = floor(x);
// y est un entier de 0 inclus à max+1 exclus (donc, à max inclus), et est équiprobable