nombre aléatoire rand

Bonjour,
Au début je souhaitait simplement générer un nombre aléatoire entre x et y j'ai donc fait une petite fonction et j'aimerais avoir quelque explications concernant ce code : (les nombres générée sont toujours les mêmes ,j'ai beau chercher je ne trouve pas)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

int rand_n(void) { int i = 0; BYTE tmp[10] = {0};   while (i < 10){ tmp[i] = (BYTE)rand() % 9; Sleep(200); i++; } return (int)tmp; }   int _tmain(int argc, _TCHAR* argv[]) { srand(time(NULL)); while (1){ cout << rand_n() << endl; Sleep(100); } getchar(); }

---

J'aimerais aussi savoir pourquoi les nombre généré par rand sont seulement sur 16 bits ?

Merci.

Bonjour,

Tu as oublié d'utiliser srand.

Code:

---

1 2 3 4 5 6 7 8 9

int _tmain(int argc, _TCHAR* argv[]) { srand(time(NULL)); while (1){ cout << rand_n() << endl; Sleep(100); } getchar(); }

---

srand est bien là , a chaque exécution j'ai un nombre différent mais si j’appelle plusieurs fois cette fonction pendant une même exécution, j'ai toujours la même chose je ne comprend pas et aussi autre chose que je ne comprend pas c'est lorsque j'ajoute des nombres dans mon tableau d'octet les nombres sont par exemple 5,8,7,1,5,0,5,8,5,3 et après le cast j’obtiens : 4716572

Mea culpa, j'ai pas vu qu'on pouvait scroller le code.

Tu convertis un pointeur (ton tableau est implicitement convertit en un pointeur sur le premier élément) en entier. Tu retournes donc l'adresse de ton tableau.

Citation:

---

Envoyé par yohann2008

Code:

---

1 2 3 4 5 6 7 8 9

int _tmain(int argc, _TCHAR* argv[]) { srand(time(NULL)); while (1){ cout << rand_n() << endl; Sleep(100); } getchar(); }

---

srand est bien là , a chaque exécution j'ai un nombre différent mais si j’appelle plusieurs fois cette fonction pendant une même exécution, j'ai toujours la même chose je ne comprend pas et aussi autre chose que je ne comprend pas c'est lorsque j'ajoute des nombres dans mon tableau d'octet les nombres sont par exemple 5,8,7,1,5,0,5,8,5,3 et après le cast j’obtiens : 4716572

---

srand(time(NULL)) ?

time() ayant une précision de l'ordre de la seconde, cette fonction initialise 10 fois srand() avec la même valeur. Nécessairement, l'appel à rand qui suit va donner 10 fois de suite la même valeur.

(et le % 9, c'est niet : ça rend plus probable l'apparition de certaines valeurs).

Maintenant, puisqu'on est sur un forum C++, pourquoi ne pas utiliser des choses plus... C++ienne ? http://www.cplusplus.com/reference/random/

Citation:

---

Envoyé par Neckara

Mea culpa, j'ai pas vu qu'on pouvait scroller le code.

Tu convertis un pointeur (ton tableau est implicitement convertit en un pointeur sur le premier élément) en entier. Tu retournes donc l'adresse de ton tableau.

---

Et comment je peut faire pour faire cette conversion ? (tableau d'octets en entier)

Citation:

---

Envoyé par Emmanuel Deloget

srand(time(NULL)) ?

time() ayant une précision de l'ordre de la seconde, cette fonction initialise 10 fois srand() avec la même valeur. Nécessairement, l'appel à rand qui suit va donner 10 fois de suite la même valeur.

(et le % 9, c'est niet : ça rend plus probable l'apparition de certaines valeurs).

Maintenant, puisqu'on est sur un forum C++, pourquoi ne pas utiliser des choses plus... C++ienne ? http://www.cplusplus.com/reference/random/

---

mon srand n'est pas dans ma boucle.
%9 ? pour avoir un nombre entre 0 et 9 non ?
En faite rand me convient pour l'instant.

Tu ne peux pas vu que le plus grand entier est (u)int64_t (= 8 octets).

Il te faut donc regarder du côté de bibliothèques permettant de manipuler de grands nombres.
Sinon quel est l'intérêt de transformer ton tableau de nombres aléatoires en un seul entier ?

Bonjour

Citation:

---

Envoyé par Neckara

Tu ne peux pas vu que le plus grand entier est (u)int64_t (= 8 octets).

---

std::intmax_t et std::uintmax_t http://www.cplusplus.com/reference/cstdint/

Si tu cherches à convertir dix chiffres en un seul entier, tu peux le faire (avec un petit calcul) car le plus grand nombre serait 9 999 999 999 et celui-ci passe dans un long long int (au moins de -9 223 372 036 854 775 807 à 9 223 372 036 854 775 807).

Emmanuel Deloget te propose des choses plus «C++ienne», c'est la bonne solution puisque rand() est "à éviter".

rand() retourne un entier entre 0 et RAND_MAX. La norme dit que RAND_MAX est d'au moins 32 767 (comme un int).

Pour information, std::vector (ou std::array selon les besoins) est le bon type pour utiliser des tableaux en C++, tu pourras utiliser ce type comme retour de fonction.

Pour tester rand(), teste le tout seul ;)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

// g++ -Wall -Wextra -Wconversion -std=c++11 -pedantic -O3 -march=native -fopenmp main.cpp -o main && ./main // g++ -Wall -Wextra -Wconversion -pedantic main.cpp -o main && ./main   #include <iostream> #include <random> #include <chrono> #include <cstdlib>     int main() { // http://www.cplusplus.com/reference/random/ std::cout << "Solution C++" << std::endl; { std::default_random_engine engine(std::chrono::system_clock::now().time_since_epoch().count());   std::uniform_int_distribution<int> distribution(0, 9);   for (int i = 0; i < 5; ++i) { std::cout << distribution(engine) << std::endl; } } std::cout << std::endl;   std::cout << "Solution C" << std::endl; { srand((unsigned int)(time(0)));   for (int i = 0; i < 5; ++i) { std::cout << rand() << std::endl; } } std::cout << std::endl;   return 0; }

---

Et pourquoi ne pas faire un seul random ?

Avec rand() ? Peut être à cause de la limite de RAND_MAX (selon la distribution voulue) (c'est une supposition).

En faite merci pour cette référence (<random>) mais ça fait encore un include a rajouter (edit: en plus comme je compte utiliser openssl je pense que je n'en aurais pas besoin), je voudrais savoir comment convertir un tableau de byte en int ? et je voudrais aussi savoir pourquoi rand est limité a RAND_MAX ?

Est-ce que ton tableau de byte représente un nombre en base 10 ou un nombre en base 256 ?

Dans le premier cas, il suffit de parcourir ton tableau de byte et de faire :

Code:

---

1 2	nombre *= 10; nombre += chiffre;

---

Dans le second cas, je maintient ce que j'ai dit, le plus grand entier standard est sur 64 bits (uint128_t n'existant pas), il te faut donc passer par une bibliothèque permettant de manipuler les très grand nombres ou de créer ton propre type entier qui sera implémenté par une structure.

Citation:

---

Envoyé par Neckara

le plus grand entier standard est sur 64 bits

---

Plus exactement, est au moins sur 64 bits. int64_t est optionnel.

Citation:

---

Envoyé par Ehonn

Plus exactement, est au moins sur 64 bits. int64_t est optionnel.

---

Je ne suis pas d'accord.

Certes la norme garantit des tailles minimales et qu'on peut éventuellement avoir des entiers de plus de 8 octets sur des architectures spécifiques.
Mais ce n'est pas parce qu'une machine spécifique a un entier sur 16 octets que les autres machines en auront un aussi.

C'est bien pour cela qu'on a inventé les (u)intXX_t, pour "garantir" une taille "fixe" et ainsi rendre le code plus portable.
Il serait ridicule d'avoir un bout de code (hors embarqué) qui fonctionne sur une architecture spécifique d'ordinateur et pas sur une autre parce que sur l'un les long long int sont sur 10 octets.

Après même si l'architecture ne gère pas les nombres sur 64 bits, on peut toujours implémenter des uint64_t et à part dans l'embarqué sur des µProcesseurs 8/16bits, on ne retrouve pas des uint64_t mais je ne pense pas qu'on en soit là.

Actuellement sur nos ordinateurs, on a pas de uint128_t, donc le plus grand entier est bien uint64_t.
On a aussi des uint_fast64_t qui peuvent être plus grand que 64 bits, mais il ne faut surtout pas l'utiliser dans l'intention de stocker des nombres sur 72 bits par exemple, on a même pas à savoir qu'il est plus grand que 64 bits, juste qu'il peut être plus grand que 64 bits.

Citation:

---

Envoyé par Neckara

Je ne suis pas d'accord.

---

Avec laquelle de ces affirmations n'es-tu pas d'accord (pour moi elles sont toutes vraies) ?

1/ Le plus grand entier standard est intmax_t et fait au moins 64 bits.

2/ int64_t n'est pas garanti exister.

3/ Il n'y a aucun type a taille fixe garanti exister.

4/ Les implémentations qui n'ont pas de int64_t sont rares au point d’être anecdotiques et ont vraisemblablement d'autres caractéristiques peu communes, l'ensemble faisant que considerer la portabilite vers ces implementations sans en disposer d'une pour tester est un exercice probablement futile.

5/ Les implementations qui ont un int64_t mais pour lesquelles intmax_t n'est pas int64_t sont possibles, elles ont des chances d'etre plus pertinentes que celle du point 4 mais je n'en connais pas (gcc a un __int128_t mais son intmax_t a 64 bits, je trouve ca bizarre et mais je suppose que c'est du a la difficulte de definir PRIxMAX en particulier pour gcc qui n'est pas lie a la libc).

Citation:

---

Envoyé par Neckara

on peut toujours implémenter des uint64_t

---

Même si cela est aussi "anecdotique", implémenter uint64_t sur une machine qui a un CHAR_BIT qui ne divise pas 64 me paraît compliqué (?)

Citation:

---

Envoyé par Ehonn

Même si cela est aussi "anecdotique", implémenter uint64_t sur une machine qui a un CHAR_BIT qui ne divise pas 64 me paraît compliqué (?)

---

Pas tant que ca. Il suffit d'utiliser un type nonsigne plus grand puis de masquer tous les resultats. (J'avais oublie que intN_t ne peut pas avoir de bits de padding)

Sauf que la taille n'est plus la même. A mon avis, si tu veux un int64_t, tu veux 64 bits, ni plus (ni moins).
Il n'y a pas très longtemps, quelqu'un sur le forum voulait une structure qui faisait exactement la même taille qu'une autre (déjà définie).

Citation:

---

Envoyé par Ehonn

Sauf que la taille n'est plus la même. A mon avis, si tu veux un int64_t, tu veux 64 bits, ni plus (ni moins).
Il n'y a pas très longtemps, quelqu'un sur le forum voulait une structure qui faisait exactement la même taille qu'une autre (déjà définie).

---

J'avais oublie que intN_t n'autorise pas les bits de paddings.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Avec laquelle de ces affirmations n'es-tu pas d'accord (pour moi elles sont toutes vraies) ?

1/ Le plus grand entier standard est intmax_t et fait au moins 64 bits.

2/ int64_t n'est pas garanti exister.

3/ Il n'y a aucun type a taille fixe garanti exister.

4/ Les implémentations qui n'ont pas de int64_t sont rares au point d’être anecdotiques et ont vraisemblablement d'autres caractéristiques peu communes, l'ensemble faisant que considerer la portabilite vers ces implementations sans en disposer d'une pour tester est un exercice probablement futile.

5/ Les implementations qui ont un int64_t mais pour lesquelles intmax_t n'est pas int64_t sont possibles, elles ont des chances d'etre plus pertinentes que celle du point 4 mais je n'en connais pas (gcc a un __int128_t mais son intmax_t a 64 bits, je trouve ca bizarre et mais je suppose que c'est du a la difficulte de definir PRIxMAX en particulier pour gcc qui n'est pas lie a la libc).

---

En tant que développeur, on a pas à savoir qu'un uint_fastXX_t est plus grand qu'un uintXX_t sur notre machine, juste qu'il peut être plus grand.
Donc en tant que développeur et sur les machines actuelles, l'entier le plus grand est uint64_t.

N'oublions pas aussi que si sur un parc de machines on a :

• pas de uint128_t sur 5% d'entre elles ;
• un uint128_t sur 95% d'entre elles.

Quel est l'entier le plus grand pour nous, développeur ? uint128_t ? Donc notre application ne pourra tourner que sur 5% des machines de notre parc ?

Même raisonnement si on a un uint_fastXX_t plus grand qu'un uintXX_t sur 60% des machines.

Si on commence à dire unsigned long long fait 10 octets sur ma machine donc je peux l'utiliser, que va-t-il se passer sur les archi où il faut que 8 octets ?

Effectivement, je me suis bien vautré sur mon analyse précédente... oups.

Citation:

---

Envoyé par yohann2008

En faite merci pour cette référence (<random>) mais ça fait encore un include a rajouter (edit: en plus comme je compte utiliser openssl je pense que je n'en aurais pas besoin), je voudrais savoir comment convertir un tableau de byte en int ? et je voudrais aussi savoir pourquoi rand est limité a RAND_MAX ?

---

En quoi un include à rajouter est-il problématique ? En quoi est-ce un problème même si on utilise openssl au final ?

OpenSSL répond à un autre problème : celui de disposer d'un générateur de nombres pseudo-aléatoire suffisamment fort pour être utilisable dans le domaine de la cryptographie. Quand bien même tu ais besoin d'un tel générateur pour un besoin précis, l'utiliser pour tous tes besoins est ce qu'on appelle communément une Erreur.

Pourquoi, me diras-tu ? (et là, je commence à simplifier, parce que le domaine est assez gros).

Pour la simple et bonne raison est qu'à part un support hardware complet (c'est à dire un générateur de nombre aléatoire hardware, ce qui pose d'autres problèmes) la seule manière d'avoir un générateur logiciel de nombre aléatoire non prédictible est d'utiliser un pool d'entropie qui est rempli par des événements non prévisibles (mouvements de la souris, espace de temps entre les frappes clavier...). Ces données sont en quantité finie : si le système ne reçoit pas d’événements pendant un temps donné, il est possible que le pool d'entropie soit vidé complètement. Dans ce cas, la récupération d'un nombré aléatoire devient impossible (il faut attendre que le pool d'entropie soit régénéré) et est implémenté généralement sous la forme d'un appel système bloquant.

Toute autre manière de faire se base sur des PRNG qui sont soit très complexes (et très lents) soit prédictibles (parce que le même seed donne la même séquence). Il existe des PRNG qui sont imprédictible lorsqu'on analyse une séquence courte produite (== après une séquence donnée, il est impossible de prédire la valeur suivante, même en connaissant l'algorithme), mais ces PRNG sont généralement coûteux en temps CPU. De plus, rallonger la séquence permet d'obtenir des informations supplémentaires qui peuvent permettre au final de deviner la suite (et donc les paramètres du PRNG, dont le seed ; à partir de là, tout est joué).

Autre manière de le dire : tous les utilisateurs de ce pool d'entropie dans le système sont arrêtés parce que tu as décidé de l'utiliser a des fins futiles.

C'est Mal. Si un programme consomme des ressources systèmes importantes alors qu'il n'en a pas besoin, c'est un bug. Il empêche d'autres programmes d'accéder à cette ressource, ce qui peut créer des problèmes en cascade (ex: "pourquoi est-ce que mon serveur web met 830 secondes à répondre à une requête HTTPS ?"). Il en faut pas le faire.

Dès lors que le besoin en PRNG (pseudo-random number generator) n''est pas un besoin avéré d'un CPRNG (cryptographic PRNG), alors il faut se contenter d'une algorithme soft qui sera de toute façon suffisant (en plus d'avoir d'autres caractéristiques intéressantes, comme la possibilité d'être rejoué une fois le seed connu).

(A noter que le standard C++ fournit aussi un device permettant de générer de vrais nombres aléatoires : random_device. Pas besoin d'OpenSSL pour ça).

On se ramène doucement à l'utilisation de <random>, qui propose des PRNG avec différentes caractéristiques (du générateur concurrentiel linéaire au mersenne twister). Son utilisation est simple, et (dès lors qu'on a pas besoin d'être au niveau crypto) suffisamment solide pour être utilisable dans tout type de projet. <random> propose même les outils permettant de généré des dés, ce qui est semblable à ton besoin (nombre entre 0 et 9).

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include <random>   std::default_random_engine my_generator; std::uniform_int_distribution<int> my_distribution(0,9); auto my_value_generator = std::bind ( my_distribution, my_generator );   int rand_n() { return my_value_generator(); }

---

Voilà. Si on veut rajouter un seed basé sur le temps, on peut procéder de la manière indiquée par Ehonn, ou tout simplement récupérer std::time(NULL).