Gestion d entree sortie

Marsh Posté le 03-04-2003 à 19:57:01

c mal :cry:

Message édité par theorie du chaos le 14-04-2003 à 21:02:31

Reply

Marsh Posté le 03-04-2003 à 19:57:01

Reply

Marsh Posté le 03-04-2003 à 20:16:49

[:rofl] [:rofl]

TDC Ze Strike Back !

et ce second TP d'asm ?

Reply

Marsh Posté le 03-04-2003 à 20:28:42

si je me souviens bien il s'agit d'associer un code a chaque lettre et chiffre en associant aux lettres les plus utilisées un petit code. Comme ca, le resultat est compressé.

exemple : le "e" sera codé par 0
le "a" par 1
le "r" par 01 en supposant que les a et les e sont les lettres les plus souvent rencontrées, suivit du r

mais une petite recherche sur google me semble appropriée

Reply

Marsh Posté le 03-04-2003 à 20:31:28

polo021 a écrit :

si je me souviens bien il s'agit d'associer un code a chaque lettre et chiffre en associant aux lettres les plus utilisées un petit code. Comme ca, le resultat est compressé.

exemple : le "e" sera codé par 0
le "a" par 1
le "r" par 01 en supposant que les a et les e sont les lettres les plus souvent rencontrées, suivit du r

mais une petite recherche sur google me semble appropriée

EDIT : http://tcharles.developpez.com/Huffman/ sacré google

Reply

Marsh Posté le 04-04-2003 à 17:00:00

l asm est a rendre une semaine apres le tp d ada...
un beau TP sur les listes...
alors priorite a Ada
meme si je prefere l asm :'(

le prof d algo nous a a moitie mache le travail pour Huffman...
le probleme c est qu on met plus de temps a lire et comprendre ses progs qu a les completer :mad:

Reply

Marsh Posté le 04-04-2003 à 18:07:35

le prof a mis des private partout :cry:

Reply

Marsh Posté le 05-04-2003 à 00:02:45

J'ai regardé ça, et ça a l'air marrant.

Je voudrais donc écrire un petit prog qui se base sur cet algo. (c'est bien mieu que le RLE )

Mais j'ai deux (très :sarcastic: ) légers problèmes...

1) Comment écrire dans un array de bytes bit par bit ?
2) Comment, à partir d'un array de bytes, contenant le fichier compressé, relire bit par bit pour parcourir mon arbre ?

PS: j'utilise du C#, mais bon, un "algo" devrait me suffir

Message édité par MagicBuzz le 05-04-2003 à 00:15:48

Reply

Marsh Posté le 05-04-2003 à 01:52:48

Bon, je me suis peut-être mal exprimé...

Mon problème :

En suivant l'algo Huffman, je me retrouve avec des séries de bits, de nombre indéfinis à écrire à la suite des autres.

Par exemple :

1110 = 'a'
01 = 's'
111101011 = 'c'

=> Pour écrire "sac" dans le fichier, je dois donc écrire les bits sous cette forme :

011110111101011.

(le '.' signifie que c'est un bit vide, je me fout de sa valeur, j'en ai pas besoin)

Bon, alors comment gérer ça ?

Actuellement, j'ai par exemple : (nombres binaires convertis en bytes)

tab[0] = 14
tab[1] = 1
tab[2] = 491

Comment faire pour les concaténer ?

Deplus, le stockage en byte me pose problème, puisque si mes séries de bits commencent par des 0, alors ils ne sont pas reconnaissables, puisque par défaut tous les bits d'un byte sont à 0, hors la présence de ces 0 est vitale, sinon je suis incapable de relire le fichier.

Pour relire bit par bit le fichier, c'est bon, je vois comment faire.
Mais là, pour écrire dedans, j'ai du mal... Je vois vraiment pas du tout comment faire :sweat:
J'ai bien une vague idée, mais c u truc de fou, je sens que je vais passer 20 nuits blanches dessus avant de réussir à le mettre en place... Il doit bien y avoir une méthode "simple" (genre la bidouille à deux balles du bon bidouilleur...)

Reply

Marsh Posté le 05-04-2003 à 02:22:36

Je vais vous donner le truc de porc quand j'avais fait ça en DEUG :whistle: .

J'avais un char tabOctet[8], dans lequel je notais les octets "incomplets" (si vous suivez pas dites le).

Ensuite dès que ce tableau tabOctet est plein --> transformation dans un vrai octet compact (cad dans un char) [:tinostar]

C'est clairement pas le plus rapide, mais c'est ultra facile à implémenter comme ça

---------------
From now on, you will speak only when spoken to, and the first and last words out of your filthy sewers will be "Sir!"

Reply

Marsh Posté le 05-04-2003 à 03:07:46

Je pensais faire un truc genre : (c'est pas mieu )

Code :

// getTabBool() retourne un array de bool pour un caractère donné de taille égale au nombre de bits conteant les bits ordonnés du plus fort = 0 au plus faible = size - 1
int position = 0;
int index = 0;
byte[] fluxDeBits;
byte temp;
for (int j = 0; j < tabChar.length; j++)
{
bool[] tabBool;
tabBool = getTabBool(tabChar[j]);
for (int i = 0; i < tabBool.length; i++)
{
fluxDeBits[index] += Maths.pow(((tabBool[i])?1:0), 7 - (position mod 8));
position++;
if (position mod 8 == 0)
{
index++;
}
}
}

Ou un truc du genre.

Mais là, c la grillade de cervelle de MagicBuzz assurée le temps de débuger cet algo

Pis alors le jour où il faut repasser derrière, laisse béton

Message édité par MagicBuzz le 05-04-2003 à 03:23:00

Reply

Marsh Posté le 05-04-2003 à 03:07:46

Reply

Marsh Posté le 05-04-2003 à 03:21:16

Après une vingtaine d'édits, il m'a l'air pas si mal cet algo

Un peu pas rapide mais bon

Reply

Marsh Posté le 05-04-2003 à 03:44:20

MagicBuzz a écrit :

Après une vingtaine d'édits, il m'a l'air pas si mal cet algo

Un peu pas rapide mais bon

il est pas terrible en fait, parce ce que tu stoque indépendement le code de hufmann de chacun des caratères de ton texte initial dans le tableau tabChar, a raison d'un par case de ce tableau.

Or il arrive souvent que le codage de hufmann d'un caractère dépasse 8 bits, et là ton code foire lamentablement [:fear]

Message édité par schnapsmann le 05-04-2003 à 03:45:15

---------------
From now on, you will speak only when spoken to, and the first and last words out of your filthy sewers will be "Sir!"

Reply

Marsh Posté le 05-04-2003 à 11:58:38

Non au contraire.

Vu que je bosse en C#, j'utilise une grammaire un peu plus compréhensible que le Java, ce qui a pu te dérouter.

En C#, un octet est un "byte" et non un "char" (ce qui est 1000 fois plus logique car un char ASCII = 7 bits, et un char UNICODE = 16 bits, alors y'a mieu pour nommer le type "8 bits"...

Je reprends mon algo ligne par ligne. Son seul défaut à priori, c'est sa relative lenteur, car pour chaque bit je suis obligé de faire pas mal de calculs.

Le code :

Code :

/*
----- Recette de la cervelle grillée -----
Admettons un array de bytes "tabData" qui contient le contenu du fichier à compresser (enfin, un buffer pointant sur le fichier)
Soit une fonction "bool[] getTabBool(byte ori)" qui à partir d'un byte passsé en paramètre, retourne un tableau de booléens contenant le code associé généré par Huffman. Le tableau en retour est correctement dimensionné.
----- Temps de cuissons 50 minutes -----
*/
int position = 0; // Position générale dans le flux de bits.
int index = 0; // Position dans le flux de bytes (concaténation des bits)
byte[] fluxDeBits; // Tableau contenant le flux de bytes
for (int j = 0; j < tabData.length; j++) // Parcours des données du fichier
{
bool[] tabBool = getTabBool(tabData[j]); // Récupération de l'encodage Huffman pour le byte courant
for (int i = 0; i < tabBool.length; i++) // Parcours du code Huffman bit par bit
{
fluxDeBits[index] += ((tabBool[i])?1:0) * Maths.pow(2, 7 - (position mod 8));
// Alors...
// (tabBool[i])?1:0) permet de retrouver si le bit traîté est un 0 ou un 1
// (position mod 8) permet de récupérer le poids du bit traîté par rapport au byte en cours de génération parmis le flux de bytes générés. En effet, "position" est incrémenté indifférement ors du taîtement de chaque bit, sans se soucier si on a changé de byte original à traîter.
// Maths.pow(2, 7 - (position mod 8)) permet de retrouver la valeur associée au poids du bit en cours de traîtement. Puisque tabBool est ordonné dans l'ordre inverse (poids le plus fort = plus petit index) on utilise la bidouille du "7 - position" pour retrouver la position par rapport au byte en cours de génération (et non pas le byte en cours de traîtement !)
position++; // On passe au bit suivant dans le byte en cours de génération.
if (position mod 8 == 0)
{
index++; // Si la position courante dans le byte en cours de génération revient à 0, alors on incrémente l'index dans le flux de bytes en cours de génération
}
}
}
/*
----- Servez c'est prêt ! -----
*/

PS: j'ai apporté quelques modifications au code, il y avait quelques grosses coquilles

Message édité par MagicBuzz le 05-04-2003 à 12:01:15

Reply

Marsh Posté le 05-04-2003 à 15:24:37

MagicBuzz a écrit :

En C#, un octet est un "byte" et non un "char" (ce qui est 1000 fois plus logique car un char ASCII = 7 bits, et un char UNICODE = 16 bits, alors y'a mieu pour nommer le type "8 bits"...

Ouais admettons, mais tu limites quand même la longueur d'un code de hufmann à la taille en bits de ton char C#. C'est mal :ange: : dans un texte ou de nombreux caractères peu fréquents sont présents, il se produit facilement des codes du hufmann de lg > 16.

---------------
From now on, you will speak only when spoken to, and the first and last words out of your filthy sewers will be "Sir!"

Reply

Marsh Posté le 05-04-2003 à 16:23:30

Mais je vois pas où tu vois que je limite quoi que ce soit :sarcastic:

Je copie les codes de huffman dans un array de bytes, au contraire, si j'ai un code sur 1024 bits ça marchera sans aucun problème mon algo.

Je crois que tu confonds remplir un byte bit par bit et remplir mon tableau... ce dernière n'a aucune limite de taille, et ne gêne en aucun cas le nombre de bits à encoder à la fois, regarde mieu l'algo, fait-le tourner, tu verras.

Même si getTabBool() retourne un array de 20 millions de lignes, ça marchera toujours.

J'utilise un tableau de bytes au lieu d'un tableau d'autrechose (Int64 ?) simplement parceque c'est sous ce format que je peux l'enregistrer sur le disque, puisque les fonctions d'accès aux fichier prennent en paramètre un tableau de bytes. Après, que les bits soient à cheva sur plusieurs lignes, je m'en fout.

Message édité par MagicBuzz le 05-04-2003 à 16:25:20

Reply

Marsh Posté le 07-04-2003 à 09:01:28

Hey c est la cat Ada

Reply

Marsh Posté le 07-04-2003 à 09:13:08

Theorie du chaos a écrit :

Hey c est la cat Ada

édite ton premier msg pour changer la cat

---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)

Reply

Marsh Posté le 07-04-2003 à 09:19:58

drasche a écrit :

édite ton premier msg pour changer la cat

nan c est mon topic :'(
et c est un TP Ada que je fais

Reply

Marsh Posté le 07-04-2003 à 09:37:00

Theorie du chaos a écrit :

nan c est mon topic :'(
et c est un TP Ada que je fais

oops j'avais loupé la mention "C#" [:fear]

---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)

Reply

Marsh Posté le 07-04-2003 à 09:49:54

bah ça change rien à l'algo, et d'après mes souvenirs, convertir e code que j'ai mis en ADA y'en a pas pour 2 heures. même en QBASIC je sais le traduire, ainsi qu'en JavaScript alors l'ADA qui est quand même un peu plus puissant devrait s'en sortir quand même

Reply

Marsh Posté le 07-04-2003 à 13:39:22

de toute facon je dois completer un prog de mon prof deja existant...
je comptais pas copier

Reply

Marsh Posté le 12-04-2003 à 12:21:45

je crois que g fini :sweat:
reste a debugger

Reply

Marsh Posté le 12-04-2003 à 12:31:26

Theorie du chaos a écrit :

sujet: compression et decompression de fichiers - Huffman

[:volta] i was here ..... c'etait un de mes projets en C l'année dernière .....pointeurs de pointeurs ... ca fait reflechir :whistle: .. et ca rend fou aussi ......

compression ok --> décompression un peu plus dur .. pas eu le temps de finir ....

---------------
from here and there -- \o__________________________________ -- la révolution de la terre, en silence

Reply

Marsh Posté le 12-04-2003 à 12:33:24

moi c le contraire

la compression est montrueuse et la decompression c tout court...

mais moi c de l Ada :cry:

Reply

Marsh Posté le 12-04-2003 à 12:36:35

Theorie du chaos a écrit :

moi c le contraire

la compression est montrueuse et la decompression c tout court...

mais moi c de l Ada :cry:

ben si tu veux .. tu rends la compression en C et la decomp en ADA :lol: :lol:

---------------
from here and there -- \o__________________________________ -- la révolution de la terre, en silence

Reply

Marsh Posté le 14-04-2003 à 19:00:20

il va etre content le prof

bon... ca compile...
si ca pouvait compresser aussi... :ange:

faut que je trouver la syntaxe...

Reply

Marsh Posté le 14-04-2003 à 19:15:10

a la base il faut que je lance
Compresser

j aimerais savoir comment faire pour l appeler sur un fichier donne...

j aurais bien utilise un Get
et declare le nom du fichier en string
mais le compilateur gueule parce que la longueur de String n est pas contrainte
en plus je ne connais pas le nom exact de la librairie qui fait un Get(String)... si elle existe...

Reply

Marsh Posté le 14-04-2003 à 21:03:00

merci de lire le post precedent

Reply

Marsh Posté le 14-04-2003 à 21:08:24

Theorie du chaos a écrit :

a la base il faut que je lance
Compresser

j aimerais savoir comment faire pour l appeler sur un fichier donne...

j aurais bien utilise un Get
et declare le nom du fichier en string
mais le compilateur gueule parce que la longueur de String n est pas contrainte
en plus je ne connais pas le nom exact de la librairie qui fait un Get(String)... si elle existe...

regarde du coté des "unbounded strings"

Reply

Marsh Posté le

Reply

Gestion d entree sortie

Sujets relatifs:

Leave a Replay