Salut à tous, dans le cadre d'un projet, je cherche un moyen d'obtenir un rand qui sois toujours compris entre 40 et 75...

quelqu'un sait comment y parvenir ?

pour l'instant j'ai teter comme suit :

while(nbrO<40 || nbrO>75)
{
srand (time(NULL));
nbrO= rand ()%75;
AffichageNbrO(nbrO);
}

nbrO contenant le nombre tiré en rand...
cependant, cette technique est plutôt foireuse et prend du temps...

en vous remerciant.

Fais un random entre 0 et 35, puis rajoute 40.

La méthode classique est de faire un random entre 0 et(max-min) puis rajouter min. Après, faire attention aux bornes pour ce qui doit être autorisé/rejeté.

nbrO = (rand() % 35) + 40

n'appelle pas srand dans ta boucle. Ne l'appelle qu'une seule fois au debut de ton programme!

aparament c pas toujour b1 dutiliser modulo

http://c-faq.com/lib/randrange.html

Indeed, j'avais ecrit ca sur le sujet il y a quelques annees:

http://demont.valerie.free.fr/site/momo/www.mandragor.org/article4ef9.html?id=12

(cool, ca a ete sauve par quelqu'un)

interesant javai deja aprocher le sujet pour faire une implentation du generateur mersene twister pour un langage de prog. maintenant c plus simple intel integre un generateur hardware dans ces cpu (instruction RDRAND). sur le kernel linux on peux lutiliser avec la fonction rdrand_long. je supose ke tu savai deja.

C'est bien d'être conscient de l'imperfection des fonctions de génération de pseudo-aléatoire, mais faut pas oublier que dans beaucoup de cas on peut s'en contenter sans sacrifice mesurable de qualité.

merci beaucoup pour toutes vos réponses, je vais vite lire et tester tout ca

1. Tikim Voir le profil de Tikim
2. Posté le 23 octobre 2012 à 22:45:43 Avertir un administrateur
3. C'est bien d'être conscient de l'imperfection des fonctions de génération de pseudo-aléatoire, mais faut pas oublier que dans beaucoup de cas on peut s'en contenter sans sacrifice mesurable de qualité.

je me rappelle d'un projet littéralement grêvé par ladite imperfection, c'est particulièrement dangereux de faire un modulo sur rand() en dépassant les seize premiers bits, quelquefois. les petites valeurs ont tendance à sortir plus souvent

Tikim, j'avais ecrit un generateur de lancer de de pour analyser les niveau dans earthdawn. Mon analyse etait biaise par les le LCG quand je tirais des de separement.

Utiliser une division flotante au lieu d'un modulo ne coute pas beaucoup plus cher et est plus correcte. Pourquoi faire moins bien?

Je sais pas vraiment de quoi tu parles, mais je suppose que c'est la réponse à ta question : par méconnaissance. Cela dit, cette imperfection se vérifie notamment dans le cas où l'on a besoin d'un grand nombre de valeurs aléatoires, ce qui n'est pas toujours le cas.

Maintenant j'ai jamais étudié la gestion de l'aléatoire en C, je sais juste comment ça fonctionne en gros avec le srand(time). Par contre j'ai fais différents tests récemment en Java sur des lancers de dés, avec Random.nextInt(max) (qui tire entre 0 et max non compris je crois), et avec le rand() basique et un calcul (rand()*(a-b)+b de mémoire, pas sûr). Et sur ces tests j'ai pas vu de différence significative. J'ai aussi testé en faisant instanciant un new Random() à chaque itération, ce qui n'est vraiment pas très propre, et de nouveau j'ai pas eu de différence suffisamment importante pour être citée.

Même avec dix millions de lancers (j'ai dû laisser tourner quelques minutes ), on restait de l'ordre de la 4 ou 5ème décimale il me semble.

lis l'article que je reference, tu vera dequoi je parles.

Si tu tire des couples (a,b) avec a = rand()%FOO; b = rand()%FOO; tu veras que ton tirage manque serieusement d'alea. Il y a des couples (a,b) qui ne sont pas atteignable.

Si dnas un jeu, un rpg par exemple, tu fais des tirages pour chaque personnage a son tour avec un seul objet Random, tu aura de l'alea qui est globalement uniforme, mais si tu regardes les statistiques par personnage, tu vera que l'alea n'est pas forcement uniforme a ce niveua la. C'est ca l'interet principal d'avoir plusieurs objet Random.

Note qu'en effet dnas plein d'applicatin, on s'en fout completement. Cependant, la technique a base de rand()/(float)RAND_MAX*max n'a pas autant de probleme. Alors pourquoi utiliser une technique qui pose probleme alors qu'il en existe une autre qui n'en pose pas autant et qui n'est pas plus difficile a utiliser?

J'ai l'impression d'avoir compris ton article et ton dernier message mais pas le lien entre les deux

Mais c'est vrai qu'on a trop tendance à tester la moyenne mais à ne pas se préoccuper de l'équiprobabilité de chaque valeur possible dans notre ensemble de nombres à générer...

et l'equiprobabilite n'est pas suffisante pour etre uniforme. Il ne faut pas oublier les dependances de markov.

Par exemple, cette suite est equiprobable dans [1:6], mais n'est pas aleatoire uniforme:
1,2,3,4,5,6,1,2,3,4,5,6,1,2,3,4,5,6,1,2,3,4,5,6,1,
2,3,4,5,6

La moyenne et l'equiprobabilite sont necessaire mais non suffisant pour avoir un bon generateur aleatoire.

« l'equiprobabilite n'est pas suffisante pour etre uniforme. » si, tout dépend de sur quoi porte l'adjectif uniforme.

La vraie question étant toujours de savoir si ce qu'on veut c'est une valeur, ou une suite de valeurs.

Ah du coup l'histoire du modulo a effectivement tout son sens ! J'avais jamais imaginé même ce problème. Mais ça reste un cas isolé non ? Dans le graphe de ton article, quand on voit les lignes parallèles ça veut dire que certains points ne seront pas atteints, mais ça ne veut pas dire que ceux qui seront atteints le seront dans l'ordre d'apparition sur la droite... Ou j'ai mal compris ?

le graphe dans l'article dit que tous les points ne seront pas atteint. Mon autre exemple indique juste que "toutes les combinaisons apparaissent autant de fois" ne veut pas dire "aleatoire"

Ok je comprends, merci pour les explications !