Il est optimiser pour etre le plus rapide possible
Il compresse a moins d'un Mo la seconde
Il est basé sur une architecture d'arbre et de liste chainée le tous avec une bonne dose de pointeur.
bonsoir j'ai telechrgé votre programme parce que je l'ai comme projet de fin d'etude mais je voulais vous demander est ce que c'est possible de m'expliquer que fait les fonctions correpondance_code,ecriture_lettre,nouveau_code et nouveau_code et j'aimerai bien comprendre qu'est ce qu'on ecrit dans le fic_ecr
je souhaite avoir une reponse le plus vite possible(au max 3jours)
Salut, je me réinterresse a la compression, et je cherchais a me remémorrer le huffman. Bien joué pour le code.
Cependant y'a 2 truc pour améliorer:
- le calcul de puissance : si tu ne fait que des puissance de 2 tu peut éviter la boucle (si tu regarde en asm, ça bouffe vite des instructions et de la meme) tu peut direct utiliser un décalage :
return 1 << position; ---> ça fait 2^position (permet aussi de positionner un bit)
- L'algorithme est le huffman statique en 2 passes, si tu veut faire du temps réelle, faudrait passer en dynamique, le truc que je cherchais justement, c'est la manière de se passer de la création de l'arbre a chaque évennement ajouté... la je vois pas.
Bon courage pour la suite
Merci pour le code, j'ai essayé de faire le projet moi même, mais j'avais un problème au niveau de construction de l'arbre ,mais avec ce code, j'ai bien trouvé la solution, encore merci.
10/10 ... n'importe quoi, on aura tout vu.
Je ne comprend pas celui qui met 10/10 vu les problemes suivants :
* deux fonctions 'val', je sais c'est pas un probleme en C++, la signature fait la difference, mais la le boulot des deux fonctions est different, donc pour plus de clarte il faut deux noms differents pour eviter que se perde
* gros probleme de liberation memoire, les arbres ne sont pas liberes, et les piles ne sont pas toujours videes !!
* beaucoup trop de variables globales, (cpt_arbre_code,nb_char_dif,nb_lettre par exemple) dont l'initialisation n'est faite d'une fois au debut du programme, or si je veux utiliser la compression plus d'une fois dans un programme, la compression plante violemment car les variables n'ont pas ete reinitialisees
* BUG : dans la reconstruction, "pile" doit etre initialise a NULL
* BUG : dans depiler, le teste n'est pas "p != NULL" mais plutot "(*p) != NULL"
* lorsque le fichier est uniforme (i.e. le meme caractere a chaque fois dans le fichier de depart) alors il y a une bloc memoire qui n'est pas libere
22 mai 2009 à 22:11
je souhaite avoir une reponse le plus vite possible(au max 3jours)
merci d'avance
28 janv. 2009 à 10:35
4 juin 2007 à 21:38
Cependant y'a 2 truc pour améliorer:
- le calcul de puissance : si tu ne fait que des puissance de 2 tu peut éviter la boucle (si tu regarde en asm, ça bouffe vite des instructions et de la meme) tu peut direct utiliser un décalage :
return 1 << position; ---> ça fait 2^position (permet aussi de positionner un bit)
- L'algorithme est le huffman statique en 2 passes, si tu veut faire du temps réelle, faudrait passer en dynamique, le truc que je cherchais justement, c'est la manière de se passer de la création de l'arbre a chaque évennement ajouté... la je vois pas.
Bon courage pour la suite
20 avril 2007 à 02:08
3 août 2006 à 15:19
Je ne comprend pas celui qui met 10/10 vu les problemes suivants :
* deux fonctions 'val', je sais c'est pas un probleme en C++, la signature fait la difference, mais la le boulot des deux fonctions est different, donc pour plus de clarte il faut deux noms differents pour eviter que se perde
* gros probleme de liberation memoire, les arbres ne sont pas liberes, et les piles ne sont pas toujours videes !!
* beaucoup trop de variables globales, (cpt_arbre_code,nb_char_dif,nb_lettre par exemple) dont l'initialisation n'est faite d'une fois au debut du programme, or si je veux utiliser la compression plus d'une fois dans un programme, la compression plante violemment car les variables n'ont pas ete reinitialisees
* BUG : dans la reconstruction, "pile" doit etre initialise a NULL
* BUG : dans depiler, le teste n'est pas "p != NULL" mais plutot "(*p) != NULL"
* lorsque le fichier est uniforme (i.e. le meme caractere a chaque fois dans le fichier de depart) alors il y a une bloc memoire qui n'est pas libere
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.