bonjour,
j'ai un problème dans un programme en C que je vien de faire
j'ai fait une boucle et tant que le random n'a pas trouver le chiffre de sorti de la boucle il recommence
et bien sur pour voir commet il travailler j'ai mit un printf et la je me suis rendu compte que au lieu de prendre des chiffre totalement au hasard(ex:12/34/20/99...), le random donnait des chiffre qui ce suivaient (ex:2/5/8/11/14/17).
comment faire pour qu'il ne ce suive pas??
merci d'avance.
Montre-nous ton code, mais il n'y a aucune raison que les nombres se suivent...
La seule chose qui peut poser problème, c'est si tu as oublié de "seeder" le random (fonction srand), mais ça ne donnerait pas ce symptome.
CODE:
je travaille sur dev c++ si sa peux t'aiderCode:#include <time.h> int main(int argc, char *argv[]) {long code = 0; do { const long max = 100, min = 1; srand(time(NULL)); code = (rand()%(max - min + 1)) + min; printf("%d\n", code); }while (code != 52);
Dernière modification par yoda1234 ; 05/09/2009 à 22h07.
Bonjour,
srand ne doit être utilisé qu'une fois dans le programme, et en tout cas, pas dans une boucle.
pourquoi il ne peux pas ètre dans une boucle ??
dans ma boucle il fonctionne bien
Tu n'as pas bien compris le fonctionnement de srand et de rand.Envoyé par blender
rand utilise un algo capable de générer des nombres pseudo-aléatoires de manière séquentielle. L'algo qui est derrière est un bijou de technique et de mathématiques pour avoir une distribution des valeurs correcte.
Sa seule "faiblesse" c'est qu'avec une même initialisation, il donne toujours le même premier chiffre... Il faut donc UNE initialisation et le reste sera un pseudo-aléatoire de qualité.
Mais toi, tu initialises avant chaque appel de rand. Donc tu fous en l'air tout le travail de l'algo ! Il est possible que ta suite ne soit plus du tout aléatoire !
Cela dit, ça n'explique pas forcément ton problème. Mais corrige le code et poste nous 5 ou 6 séries de nombres, stp
bon bé merci beaucoup sa fonctione bien
suite aléatoire:
24/54/11/29/99/35/8/41/81/78/79/8/17.
Bonjour,
Compte tenu de la boucle en question, l'initialisation se fait à chaque tour avec une valeur très proche - et supérieure - de la précédente, et le calcul conduit à des valeurs croissantes (mais avec un autre compilateur utilisant un autre calcul, ce pourrait être différent).
Oui, c'est ce que je supposais... mais je suis assez surpris qu'une suite croissante d'init donne une suite croissante de premiers chiffres... J'aurais vu ça un peu plus chaotique !
Bonjour,
C'est parce qu'il ne faut pas confondre processus d'initialisation et calcul des valeurs suivantes.
Et comme déjà dit, un autre générateur pourra très bien donner un résultat très différent.
dans le man de randil est clairement dit de ne pas utiliser les bits de poids faible pour réduire la plage de résultat: donc au lieu de:In Numerical Recipes in C: The Art of Scientific Computing (William H. Press, Brian P. Flannery, Saul A. Teukolsky, William T. Vetterling; New York: Cambridge University Press, 1992 (2nd ed., p. 277)), the following comments are made:"If you want to generate a random integer between 1 and 10, you should always do it by using high-order bits, as inRandom-number generation is a complex topic. The Numerical Recipes in C book (see reference above) provides an excellent discussion of practical random-number generation issues in Chapter 7 (Random Numbers).j = 1 + (int) (10.0 * (rand() / (RAND_MAX + 1.0)));and never by anything resembling
j = 1 + (rand() % 10);(which uses lower-order bits)."
il vaut mieux écrire:Code:code = (rand()%(max - min + 1)) + min;
Le résultat sera "plus" aléatoire.Code:code = (rand()*(max - min + 1)) / (RAND_MAX + 1.0) + min;
(attention, à la définition du rand() dans des compilos exotiques et à la taille de la variable code)
Bonjour,
Et écrit comme ça, tu fausses la suite générée.
rand()*(max - min + 1) à de bonnes chance de dépasser RAND_MAX, et donc problème d'overflow, qui va ajuster la valeur calculée, sans prévenir !!
Il faut passer par des double pour éviter ça.
Mais non!!!Bonjour,
Et écrit comme ça, tu fausses la suite générée.
rand()*(max - min + 1) à de bonnes chance de dépasser RAND_MAX, et donc problème d'overflow, qui va ajuster la valeur calculée, sans prévenir !!
Il faut passer par des double pour éviter ça.
RAND_MAX = 215-1 = 32767
donc , si la plage attendue est du même tonneau, le produit ne peut pas dépasser 1G, donc il reste un bit pour un long... et comme code est défini comme un long, il n'y a aucun problème.
(ne pas confondre avec RANDOM_MAX qui vaut 231-1 soit 2G)
et puis sinon, il vaut mieux asser par les "long long" (64 bits significatifs) que par les "double" (48 bits significatifs).
Bonjour,
désolé, mais RAND_MAX dépend de l'implémentation, il ne faut donc pas faire de supposition sur sa valeur précise.
c'est aussi pour ça que j'avais mis au départ:Bonjour,
désolé, mais RAND_MAX dépend de l'implémentation, il ne faut donc pas faire de supposition sur sa valeur précise.bon ok, c'est pas obligatoirement exotique...(attention, à la définition du rand() dans des compilos exotiques et à la taille de la variable code)
donc long long si possible
Bonjour,
J'ajouterais qu'il est temps que les principales implémentations, qui utilisent effectivement RAND_MAX = 32767, passent à la vitesse supérieure et cessent donc de brider leur générateur à uniquement 32767 valeurs possibles, ce qui est parfaitement ridicule.
Il y a bien longtemps que j'ai implémenté mes propres générateurs en 32 et 64 bits (de bons générateurs, créés en tenant compte de tout ce qu'en dit Knuth dans
le tout vérifié ailleurs).Code:Référence : [1] Donald E. KNUTH "The Art of Computer Programming", Vol 2: Seminumerical Algorithms 3rd ed., Addison-Wesley, Reading Mass., 1997
