Discussion :

[Touco777]

Bonjour
Pour un programme j'ai besoin de générer une vingtaine de nombres aléatoires (compris entre 1 et 52) dans un laps de temps très cours (1 à 2 secondes max ) !
Le seul moyen que j'ai trouvé de faire sa :

i =(int)((double)rand() / ((double)RAND_MAX + 1) * 52);

dans une boucle
Le Pb c'est qu'il est nécessaires de mettre un sleep d'une seconde sinon i aura toujours la même valeurs ...

J'ai penser a se referer a l'horloge atomique en fonction des millisecondes mais je ne sais pas comment faire ...

Auriez vous une solution adéquate a mon problème ??

[Kujara]

Au debut de programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

srand(time(0));

Dans ta boucle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

i = 1 + rand()%52;

Pas besoin de Sleep, rand() renvoie une valeur differente a chaque fois.

[droggo]

Lie,

Au debut de programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

srand(time(0));

Dans ta boucle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

i = 1 + rand()%52;

Pas besoin de Sleep, rand() renvoie une valeur differente a chaque fois.

On y revient toujours, utiliser le modulo pour faire ça est déconseillé (je ne vais pas répéter ici pourquoi, cela a déjà été énoncé x fois dans maints sujets).

Pour cela, la méthode utilisée par Touco777 est meilleure.

[Touco777]

Pour cela, la méthode utilisée par Touco777 est meilleure.

Certes mais elle ne marche pas comme je voudrais ...
A contrario de la methode de Kujara qui fait exactement ce que je voulais
La reponse était plus facile que ce que je pensais ! J'ai du chercher midi a 14h pour rien

Merci bien

[Kujara]

Lie,

On y revient toujours, utiliser le modulo pour faire ça est déconseillé (je ne vais pas répéter ici pourquoi, cela a déjà été énoncé x fois dans maints sujets).

Pour cela, la méthode utilisée par Touco777 est meilleure.

Link please, les arguments contre m'interessent

[koala01]

Lie,

On y revient toujours, utiliser le modulo pour faire ça est déconseillé (je ne vais pas répéter ici pourquoi, cela a déjà été énoncé x fois dans maints sujets).

Pour cela, la méthode utilisée par Touco777 est meilleure.

Normalement, il n'y a aucune différence entre les deux...

• le transtypage d'un réel en entier, sans utiliser les possibilités d'arrondi se fait en perdant la partie décimale du réel
• le modulo fournit tout simplement le reste entier de la division, et donc correspond au même résultat
• Dés le moment où l'on veut que n'importe quel nombre sélectionné de manière aléatoire entre dans un espace compris entre 0 et N, il faudra le diviser de manière à être sûr que le résultat sera compris entre 0 et N
• On ne s'intéresse pas à la partie décimale du résultat, et, de toutes manières, on ne dispose que de N possibilités...

[droggo]

Kio,

Je ne redonnerai pas les explications, qui, je le répète, ont été données x fois déjà.

En gros, les bits de poids faible sont généralement moins aléatoires, il faut donc éviter de les utiliser seuls, ce que l'on fait avec le modulo.

[Kujara]

Kio,

Je ne redonnerai pas les explications, qui, je le répète, ont été données x fois déjà.

En gros, les bits de poids faible sont généralement moins aléatoires, il faut donc éviter de les utiliser seuls, ce que l'on fait avec le modulo.

Argument valable uniquement sur un modulo en puissance de 2, auquel cas le modulo est inutile.

Pour les modulo genre modulo 3, tous les bits sont utilisés ....

Bref, j'attends les liens vers des arguments valables ...

[nicroman]

Ce n'est pas une question de bits utilisés ou non....


C'est une simple question de math (de stats en fait)...
rand doit renvoyer une valeur "uniformément répartie" entre 0 et RAND_MAX.
Une opération de modulo est obligatoirement déstructrice de ce précepte.


Prenons, un exemple "simple", en 8 bits... avec RAND_MAX à 255....

rand() => uniforme entre 0 et 255... chaque valeur a une chance de 1/256 de sortir... Espérance de 127.5

Et on veut les valeurs de 0 à 9 (soit 10 valeurs), uniformément, donc avec si possible une espérance de 4.5


rand()*10/256
0 peut venir de 0 à 25 => 26/256 chances
1 peut venir de 26 à 51 => 26/256 chances
2 peut venir de 52 à 76 => 25/256 chances
3 peut venir de 77 à 102 => 26/256 chances
4 peut venir de 103 à 127 => 25/256 chances
5 peut venir de 128 à 153 => 26/256 chances
6 peut venir de 154 à 179 => 26/256 chances
7 peut venir de 180 à 204 => 25/256 chances
8 peut venir de 205 à 102 => 26/256 chances
9 peut venir de 231 à 255 => 25/256 chances

L'espérence est de 4.484375... la répartition aussi uniforme que possible....


rand()%10
0 peut venir de 0, 10, ... 250 => 26/256 chances
1 peut venir de 1, 11, ... 251 => 26/256 chances
...
5 peut venir de 5, 15, ... 255 => 26/256 chances
6 peut venir de 6, 16, ... 246 => 25/256 chances
...
9 peut venir de 9, 19, ... 249 => 25/256 chances

L'espérence est de 4.453125... la répartition principalement au début....

[Kujara]

Oui, ça je savais.

Tu devrais aussi savoir que ça n'a aucune importance pour la quasi totalité des applications ....
Dans ton propre exemple la difference de proba n'est que de 1/26 ....
RandMax etant tres elevé ( 2 ^ 15 sur ma machine), la difference de proba entre les differents resultats est encore moindre.

A part sur une application mathematique ou tu a besoin d'une equiprobabilité guarantie, le modulo bon.

[yan]

Argument valable uniquement sur un modulo en puissance de 2, auquel cas le modulo est inutile.

Pour les modulo genre modulo 3, tous les bits sont utilisés ....

Bref, j'attends les liens vers des arguments valables ...

lol.
exemple pour modulo 3
3 est codé sur 2 bits
rand donne un 16bits (#define RAND_MAX 0x7fff)
rand()%3 équivaut grosso modo à utilise que les 2 bits de poids faible

zut ces bits ne varient pas beaucoup....

[poukill]

Au fait, y'a Boost.Random pour les nombres aléatoires.
Je sais pas si c'est assez rapide, mais vu le reste de la bibliothèque, moins de deux secondes ça me parait du gateau...

[Kujara]

lol.
exemple pour modulo 3
3 est codé sur 2 bits
rand donne un 16bits (#define RAND_MAX 0x7fff)
rand()%3 équivaut grosso modo à utilise que les 2 bits de poids faible

zut ces bits ne varient pas beaucoup....

............

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	std::cout<<" modulo 3 : "<<(0x10000001%3)<<" // "<<(0x20000001%3)<<"\n";
	std::cout<<" modulo 3 : "<<(0x10000002%3)<<" // "<<(0x20000002%3)<<"\n";

Que les bits de poids faible, hein ? Tu dois confondre & bit a bit et modulo mathematique, toi ....

[yan]

............

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	std::cout<<" modulo 3 : "<<(0x10000001%3)<<" // "<<(0x20000001%3)<<"\n";
	std::cout<<" modulo 3 : "<<(0x10000002%3)<<" // "<<(0x20000002%3)<<"\n";

Que les bits de poids faible, hein ? Tu dois confondre & bit a bit et modulo mathematique, toi ....

oui bon j'ai rien dit

[screetch]

Oui, ça je savais.

Tu devrais aussi savoir que ça n'a aucune importance pour la quasi totalité des applications ....
Dans ton propre exemple la difference de proba n'est que de 1/26 ....
RandMax etant tres elevé ( 2 ^ 15 sur ma machine), la difference de proba entre les differents resultats est encore moindre.

A part sur une application mathematique ou tu a besoin d'une equiprobabilité guarantie, le modulo bon.

je ne vois pas l'interet de faire mal quand on peut faire juste.....

[Kujara]

je ne vois pas l'interet de faire mal quand on peut faire juste.....

Vitesse d'execution, par exemple ?

Et simplicité de codage / lisibilité.

[koala01]

je ne vois pas l'interet de faire mal quand on peut faire juste.....

Le problème n'est pas tant de faire mal quand on peut faire juste, mais de faire simple quand on peut faire compliqué...

Si pour une grande majorité de cas, on peut ne pas s'inquiéter d'une différence de quelques centièmes dans une espérance, il n'y a qu'une raison à la limite de l'obsession psychologique pour "se prendre le choux" à vouloir gagner les quelques centième dont on n'a, en définitive, pas réellement besoin.

En effet, c'est oublier un peu vite les deux grands premiers principes:

• le mieux est l'ennemi du bien
• la solution la plus simple est souvent la meilleure

Si le recours au modulo permet de gagner en compréhensibilité à la relecture du code au lieu de se poser la sempiternelle question "mais à quoi correspond cette formule" et qu'il fournit une espérance correcte pour l'application, pourquoi s'en priver

Je ne dis pas qu'il n'y a aucun intérêt à savoir que l'on perd en précision, et je ne le dirai jamais, mais je dis *surtout* qu'il faut s'en souvenir quand on se trouve dans une situation qui rend la chose *réellement* importante.

Enfin, si vraiment on veut utiliser le modulo tout en gagnant un peu en espérance, il nous reste le recours à une liste circulaire pour les éléments... La position de départ changeant à chaque tirage, on rétabli l'équilibre, et je ne serais même pas surpris que l'on améliore encore les choses

[nicroman]

Dans ton propre exemple la difference de proba n'est que de 1/26 ....
RandMax etant tres elevé ( 2 ^ 15 sur ma machine), la difference de proba entre les differents resultats est encore moindre.

Sur CET example là... j'aurai pu prendre le range 0-254 par exemple.... et dans ce cas... la différence de proba aurait été de 2.... Le 0 ayant deux fois plus de chances de sortir que n'importe quel autre nombre....

Plus ennuyeux encore... l'éspérance est complètement déplacée....

Et pour finir dans certains cas, le modulo peut carrément mettre en l'air l'algorithme de génération de nombres aléatoire (par exemple en réduisant la périodicité drastiquement).

[koala01]

Et pour finir dans certains cas, le modulo peut carrément mettre en l'air l'algorithme de génération de nombres aléatoire (par exemple en réduisant la périodicité drastiquement).

Sauf que tu la réduira de toutes manières dés le moment où tu ne veux pas disposer de RAND_MAX valeurs différentes, que ce soit à coup de division ou à coup de modulo...

Quelque soit la solution envisagée, si tu n'as que 50 places pour 100 prétendants, tu ne laissera d'office la moitié sur le carreau

Je ne disconviens nullement qu'il peut être embêtant dans certaines conditions de savoir que X a une meilleur probabilité que Y d'être choisi alors que, normalement ce devrait être l'inverse, mais dans de nombreux cas, on n'en a que peu à faire...

Le but d'un nombre (pseudo) aléatoire reste, rappelons le quand même de fournir une forme de hasard là où la forme du langage et la logique l'interdit/n'en prend pas compte...

Quand on voit déjà toutes les magouilles dont les gens sont capables pour "faire pencher" le hasard dans le bon sens, on peut accepter l'idée de perdre "un peu" de celui-ci par facilité...

D'autant plus que, je le rappelle, il est *relativement* facile de rétablir l'équilibre en se facilitant la tâche pour la suite (l'usage d'une liste circulaire au lieu d'utiliser un tableau dans le cadre de tirage sans remise en est le parfait exemple)...

[EDIT]D'ailleurs, même dans le cadre d'un tirage avec remise, l'utilisation d'une liste circulaire est de nature à rétablir l'équilibre, le point de départ changeant après chaque tirage