cs_Kirua
Messages postés3006Date d'inscriptiondimanche 14 avril 2002StatutMembreDernière intervention31 décembre 2008 13 janv. 2005 à 16:57
euhm, chaque fois que tu appels srand, tu réinitialises le seed, et c'est le seed qui détermine la liste des nombres qui vont sortir "pseudo-aléatoirement".
#include
#include <ctime>
#include <cstdlib>
using namespace std;
ceci sort 4 fois le même chiffre car l'heure n'aura pas changé entre les appels à srand -> le seed est le même -> la liste de nombres est la même -> le premier est tjs le même! cqfd. il faut impérativement n'appeler srand qu'une seule fois!
pmbala
Messages postés30Date d'inscriptionsamedi 4 décembre 2004StatutMembreDernière intervention 2 avril 2008 12 janv. 2005 à 22:17
oué en effet,ça ne change rien de mettre srand() juste au debut,je pense plutot que c'est le compil de v c++6 qui n'est pas tres puissant... sous linux j'ai de meilleurs resultats...
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 12 janv. 2005 à 19:05
srand() serait aussi bien hors du 'do', direct dans le main() en 1ere instruction, mais bon doit pas etre dramatique.
pmbala
Messages postés30Date d'inscriptionsamedi 4 décembre 2004StatutMembreDernière intervention 2 avril 2008 12 janv. 2005 à 18:50
ok je vais tenir compte de tes remarques Brunews,après tout je suis là pour apprendre et donc je te remercie.Mais par contre il me semble avoir mis le srand() une seule fois au debut de mon mail,si c'est pas comme ça,alors je reste à l'ecoute...merci
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 12 janv. 2005 à 13:31
cosmobob
Messages postés700Date d'inscriptionmardi 30 décembre 2003StatutMembreDernière intervention27 janvier 20094 12 janv. 2005 à 13:23
si c'est intéressant, poste un exemple ici... perso je sais pas ce qu'est le 'qsort de la CRT'
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 12 janv. 2005 à 12:54
Encore une remarque transcendante....
Si je me compare a plus handicape que moi qui peux encore marche, je serai bien sur le plus rapide, pour autant je suis une tortue compare a qlqun en bonne sante.
Prends le qsort de la CRT, enleve ses appels externes, et il sera autrement plus performant que du recursif.
cosmobob
Messages postés700Date d'inscriptionmardi 30 décembre 2003StatutMembreDernière intervention27 janvier 20094 12 janv. 2005 à 12:29
et pourtant c'est le tri le plus rapide de tous, meme s'il est récursif, magique hein? (fo choisir une taille suiffisament grande de tableau pour le constater)
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 12 janv. 2005 à 08:37
Mets l'initialisation srand() 1 seule fois au lancement du prog et non dans les boucles.
Quicksort en recursif c'est "quoi de pire", l'empilage et depilage des parametres ruinent les performances.
13 janv. 2005 à 16:57
#include
#include <ctime>
#include <cstdlib>
using namespace std;
int main(int argc, char **argv)
{
srand(time(NULL));
cout << rand() << endl;
srand(time(NULL));
cout << rand() << endl;
srand(time(NULL));
cout << rand() << endl;
srand(time(NULL));
cout << rand() << endl;
cin.get();
return 0;
}
ceci sort 4 fois le même chiffre car l'heure n'aura pas changé entre les appels à srand -> le seed est le même -> la liste de nombres est la même -> le premier est tjs le même! cqfd. il faut impérativement n'appeler srand qu'une seule fois!
12 janv. 2005 à 22:17
12 janv. 2005 à 19:05
12 janv. 2005 à 18:50
12 janv. 2005 à 13:31
http://www.cppfrance.com/code.aspx?id=11151
12 janv. 2005 à 13:23
12 janv. 2005 à 12:54
Si je me compare a plus handicape que moi qui peux encore marche, je serai bien sur le plus rapide, pour autant je suis une tortue compare a qlqun en bonne sante.
Prends le qsort de la CRT, enleve ses appels externes, et il sera autrement plus performant que du recursif.
12 janv. 2005 à 12:29
12 janv. 2005 à 08:37
Quicksort en recursif c'est "quoi de pire", l'empilage et depilage des parametres ruinent les performances.