d'apres ce que j'ai compris, on ne pourrait pas avoir de conteneur d'elements associé a des clefs qui sot non ordonné

noob4ever > bah t'imagines si après avoir décompressé une image les pixels seraient triés par couleur, ça le fait moyen
Je sais qu'ici c'est juste pour l'exercice, mais préserver l'information me semble un principe incontournable.

@Jaloyan :
Exactement ce à quoi je pensais durant ma douche
Il faudrait par contre exclure certains caractères (EOF...)

@noob4ever :
Bah oui quand même
T'imagines tu compresses "Bonjour" et tu te retrouve avec "ruojnoB" ?
Mais bon c'est pas vraiment un problème, il suffit d'inverser l'ordre lors de la décompression, c'est pas compliqué


Je pensais également à un truc : peut être existe t-il dans la table ASCII un nombre qui ne correspond à aucun caractère ? Si oui il pourrait être le flag

Inverser l'ordre? il a pas dit qu'il ressortait en fonction de l'alphabet?

ben le caractere EOF.

Bien pensé mais c'est déjà pris.

@Goten : Aaaah d'accord, j'avais pas compris :oups:
Ben alors faut revoir la compression je pense, le but est quand même de conserver les informations pour les restituer dans l'état initial non ? (sinon on pourrait faire un "compresseur" qui vide tout simplement le fichier, ça prendrait moins de place )

@Jaloyan : Oui, apparement la table est pleine ^^, peut être le 255, DEL ? (je vois pas comment on peut stocker DEL dans un fichier :^o )
Ou sinon 176 par exemple; bien moins utilisé que @ (je savais même pas qu'il existait ).

noob4ever: ben si pour toi décompresse un image et la décompresser pour qu'elle deviennent à l'envers n'est pas grave...
Si tu utilise un conteneur pour stocker tes string, utilise un dequeue.

Isra17, tu as mal compris (en fait tu as compris la même chose que moi tout à l'heure ; l'ordre n'est pas inversé, mais le fichier est trié dans l'ordre alphabétique.
Exemple :
fffbjaaaccbb => aaabbbccfffj

Donc là le fichier n'a plus de sens du tout.

ha, d'accord, sinon je viens de trouver un bogue dans la manière de compresser de Nanoc. C'est encore à cause du flag. Disons que nous avons cette chaîne: aaabbb1@yzzz
cela donne: 3@a3@b1@03@z
Vous voyez l'erreur?
je décompresse et j'ai:
aaabbb0zzz
je propose que nous abolissons le flag et que nous fesons comme la méthode officiel (wiki ou comme le dit Genius)
une autre méthode serait d'utiliser 0@ à la place. Ainsi il est clair que nous ne pouvons trouver ambigue de mettre 0 fois @.

Ex: aaabbb1@0zzz
cela donne: 3@a3@b10@3@z
donc: aaabbb1@zzz

le beug peut etre reglé en codant le flag @@

Il faut voir quand même que c'est Nanoc qui crée les exercices et anime ce sujet, à lui de décider (même si j'aime pas "sa" méthode :p)

poulecaca : et tu diminue encore plus la compression, 0@ marche très bien
et hop, mon encodeur marche parfaitement

ben Isra17 coder @@ ou 0@ il y a deux caractère dans les deux cas donc la compression reste la meme
Mon encodeur marche parfaitement aussi seulement d'ailleur on m'a toujours pas repondu pour l'histoire du flag entré par la personne : doit on mettre en argument le nouveau flag pour décompresser le fichier ou se débrouiller pour que le flag soit ecrit dans le fichier au risque de perdre un caractère pour le taux de décompression.

je ne trouve pas du tout de conteneurs a clefs non ordonnés, je seche vraiment là!

Citation : Isra17

Disons que nous avons cette chaîne: aaabbb1@yzzz
cela donne: 3@a3@b1@03@z
Vous voyez l'erreur?
je décompresse et j'ai:
aaabbb0zzz

Si tu respectais l'algo tu aurait pas cette erreur:
aaabbb1@yzzz
3@a3@b1@0y3@z
et en decompressant
3 fois le a, puis 3 fois le b, puis 1 fois ... ha bha non, on a dit que 1 fois on mettais direct donc c'est un 1, puis un @ pui y et 3 fois z :
aaabbb1@yzzz

D'accord freedom mais la chaîne aaabbb6@yzzz
3@a3@b6@0y3@Z
3 fois a 3 fois b 6 fois (au mince on peut très bien avoir 6 fois quelque chose) 0 1 fois y et 3 fois z
on a donc aaabbb000000yzzz oups

Mais si tu remplaces la chaîne de départ par "aaabbb3@yzzz" par exemple, le problème est toujours là

bon, il ne reste plus qu'a attendre que Nanoc revienne et change les règle. Sinon, vous êtes rendu où vous autre? Moi j'ai finis l'encodage et l'interface (ligne de commande) j'ai la possibilité de définir le flux de sortie (console ou fichier) et de définir le flux d'entré (chaine ou fichier). reste plus qu'a décoder le tout.

Citation : poulecaca

D'accord freedom mais la chaîne aaabbb6@yzzz
3@a3@b6@0y3@Z
3 fois a 3 fois b 6 fois (au mince on peut très bien avoir 6 fois quelque chose) 0 1 fois y et 3 fois z
on a donc aaabbb000000yzzz oups

Oui oui, sa je suis d'accord, je montrais juste l'exemple donné par Isra17, se compressait et decompressait tres bien avec l'algo de Nanoc

Citation : Genius

Mais si tu remplaces la chaîne de départ par "aaabbb3@yzzz" par exemple, le problème est toujours là

La d'accord aussi, le probleme se pose des qu'on a n@0, avec n compris entre 3 et 9, sinon l'algo marche.

Citation : Isra17

Sinon, vous êtes rendu où vous autre?

Me reste a mettre en place la recupération avec les parametre du main(), et la gestion des exeptions, sinon sa a l'air de marcher

vite comme ça, qu'est-ce qui ne marche pas avec n@@?

il me reste aussi les exeptions.

la solution serait de mettre n@@(comme l'a dit isra17)
Et n peut etre égal a 1 c'est de la perte d'espace mais bon il faut bien.
Comme ca on est sur que l'algo pourra marcher avec cet exemple.

Bon bon, je vois qu'une modification s'impose.

La conservation de l'ordre est important. Il faut que la compression puis la décompression d'un fichier me rende le fichier original ! Sinon, ça n'a aucun intérêt.

On ne peut pas abandonner le flag. Que ceux qui pensent ça, essayent de compresser "234555166" et ensuite de décompresser.

Pour ce qui est du choix du flag. En effet, choisir un caractère "rare" est obligatoire. Maintenant, qu'est-ce qu'un caractère rare ? Si vous laissez le choix à l'utilisateur du flag, alors il devra l'indiquer à la compression et à la décompression. Par exemple :

monProgramme -c -f="@" monFichier.txt
Compression avec le flag "@" en cours...
Compression terminée.

Pour ce qui est du codage du flag. Ok, ma méthode n'était certainement pas la meilleure. Prenons donc comme moyen de coder le flag, la syntaxe "flag flag". Ceci pose un autre problème que je vous laisse découvrir.
"333@222224" -> "3@3@@5@24"

Pour ceux qui veulent jouer avec les bits. Non. C'est trop compliqué. Vous vous êtes assez pleint la fois passée quand il fallait faire une simple multiplication de deux entiers. On va pas commencr à jouer sur des tableaux de bits en mémoire.

Je modifie les règles en conséquence.

P.S.: Pour les conteneurs à clés non-ordonnés, bien que je n'en voie pas l'intérêt ici, il n'y en a pas dans le standard.

Citation : Nanoc

On ne peut pas abandonner le flag. Que ceux qui pensent ça, essayent de compresser "234555166" et ensuite de décompresser.

Mais si Nanoc, on peut :
121314351126

Je suis d'accord que ça ne compresse pas étant donné que le résultat est plus long que le texte de départ, mais avec un flag la compression serait nulle, donc ce serait pas super utile non plus...

Par contre sur une chaine comme "1111222333334444555555", sans flag on a : 4132534465 et avec on aurait 4@13@25@34@46@5, et là la méthode sans flag est plus efficace

Le bon côté c'est qu'il ne peut y avoir aucun problème de ce type comme tu dis :
"333@222224" -> "3@3@@5@24" (flag @@)
"1116@222224" -> "3@16@05@24" (flag @0)

si il y a par exemple dans une chaine 11 de 'a', la compression devrait retourner 9@a 2@a oubien 9@a aa ?

Citation : Nanoc

Pour les "@@@", essaie de décompresser ton truc et tu verras ce qui se passe...

Quel est le problème avec n@@ ? n étant un chiffre. J'ai par exemple ceci à compresser: @@@@@@

Quand je compresse:
6@@

Et quand je décompresse je me retrouve bien avec:
@@@@@@


Si j'ai ceci à compresser: @@@@@@@@@@@@@@

Quand je compresse:
9@@5@@

Quand je décompresse:
@@@@@@@@@@@@@@

Compression & Décompression : OKAY
En tout cas je n'ai pas trouvé de bug dans mon code pour l'instant. Je vais voir si j'en trouve.

EDIT pour zero ptt : Logiquement, d'après l'énoncé de Nanoc, tu te retrouves avec 9@a aa (enfin sans espace normalement).

Salut !
Il est bien sympa ton exercice Nanoc !
J'ai décidé d'essayer de le faire mais j'ai déjà un problème

Comment découper une chaine string comme AAAAABBB juste entre le A et le B ?
J'ai pensé a maChaine.substr() comme dans le tuto de M@teo mais il faut indiquer ou couper, ce que l'on ne sait pas...

Merci

c'est u exercice ça, reflechis toi meme! et si tu bloque, je suis pret a t'aider dans un mois

Kurzle => S'il n'y a qu'un ou deux @, il y a un problème...

mais c'est quoi le prob?