@Genius:
Ok, mais tu perds tout l'avantage de la compression puisque les chaînes composées de 1 caractère se retrouvent alors sous la forme de 2 caractères.
De plus tu as un problème qui survient quand tu codes la séquence "111111111111111111".

De toute façon, là n'est pas la question. Si tu veux participer, alors uilises un flag.

@Zero ptt:
9@a aa (sans espace)

@aerotec:
Toute la difficulté est là. Relis le tuto de M@teo21 et sinon, regarde dans la doc de string. Si tu trouves vraiment pas, je t'invite à créer un autre sujet sur le forum.

et si on a par exemple dans le fichier a compresser @@@@@@@@@@@@@@@@@@@@@@@@@@@
on fait 9@@@ oubien @@ @@ @@ @@...@@ ?autre question, admettons que 'x' est le frag, la syntaxe special devient @x oubien xx ?

Je te laisse réfléchir seul à ta question. J'ai donné tous les éléments nécessaires.

@Nanoc :

"Ok, mais tu perds tout l'avantage de la compression puisque les chaînes composées de 1 caractère se retrouvent alors sous la forme de 2 caractères."

Oui, je suis d'accord, mais si les nombres sont par groupes de trois ou plus, tu gagnes un caractère sur chaque groupe.

"De plus tu as un problème qui survient quand tu codes la séquence "111111111111111111"."

9191 ?

"De toute façon, là n'est pas la question. Si tu veux participer, alors uilises un flag."

Si tu y tiens vraiment, d'accord ; mais ne vaut-il pas mieux réfléchir avant de se lancer ?
Si on n'avait pas réfléchi, on aurait codé avec @0 et on aurait des problèmes...
On voir alors que certains proposent @@, on code, mais il y a toujours des problèmes...
Donc on aurait codé pour rien, étant donné que le fichier décompressé ne serait pas le même que le compressé...
Donc réflechir ne peut pas faire de mal avant de commencer, d'autant plus que l'on est le 2 juin et qu'il reste bien assez de temps pour coder

Autre chose => Je pense avoir trouvé un moyen pour éviter de transformer 123 en 111213 tout en n'utilisant pas de flag ; je continue d'y réflechir

Je vais essayer de coder un algorithme pas trop sale en python. En attendant, voilà un petit outil pour générer aléatoirement et de manière rapide des fichiers à compresser : utile pour tester votre code et comparer l'efficacité.

Bonne chance à tous.


EDIT : Jaloyan1, en l'occurence mon outil sert à ça...

je vais essayer d'élaborer un fichier texte pour le tester car on va voir si ca marche vraiment l'algorithme de compression

fini la compression.
commence le decompression

je viens d'ouvrir quelques images et a ma grande surprise, ca sert a rien l'algo de compression sur des images du type photo ou complexes.
Ca peut au maximum servir a cela.

http://www.clipart-fr.com/data/clipart [...] saire_039.gif

J'ai l'impression que vous n'avez pas très compris le fait que l'exercice soit avant tout de vous entraîner même si les applications peuvent parraître moindres. Donc on s'en contre-fiche que ce soit pas efficace sur vos images, choisissez plutôt des textes répétitifs comme celui du générateur.

Citation : Genius

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

Non, aucun problème pour moi. Si j'ai ça à compresser : @ ou @@, et bien... je ne le compresse pas (cf. énoncé, il y a moins de 3 occurrences de @, donc on compresse pas). Donc aucun soucis Compresser -> Décompresser & Décompresser -> Compresser car ça reste @ ou @@. En tout cas, ça à l'air de fonctionner chez moi... Nanoc ?

Citation : Jaloyan1

je viens d'ouvrir quelques images et a ma grande surprise, ca sert a rien l'algo de compression sur des images du type photo

La plupart des formats d'images (jpg, png,..) sont déjà compressés. Si tu veux, tu peux regarder un fichier .bmp (format non compressé) tu verra qu'il y a une certaine périodicité dans les octets qui sont proches les uns des autres. Un algorithme de type RLE peut donc être relativement efficace sur ce type de fichier.

ah ouai sur bmp ca peut etre pratique mais quand ca se suit, ca se suit pour assez longtemps.
Donc la solution du 9 caracteres repetitifs ne serait pas convenable. Il faudrait etendre a des paquets de 255.

Citation : Genius

"De plus tu as un problème qui survient quand tu codes la séquence "111111111111111111"."

9191 ?

Ok, je pensais que tu allais coder cela comme 181. Ce qui aurait posé problème.

Citation : Genius

Si tu y tiens vraiment, d'accord ; mais ne vaut-il pas mieux réfléchir avant de se lancer ?

Ce que je veux dire. C'est qu'il faut définir un cadre commun. Sinon j'aurais pu mettre une donnée du genre :

"Codez un algorithme de compression de données"

et c'est tout. C'est beaucoup trop large et largement trop compliqué pour un débutant. Je le répète encore une fois: Ces exercices sont pour débutants. Pour quelqu'un d'avancé, j'aurais plutôt proposé de coder l'algorithme utilisé dans les archives zip. C'est efficace et utilisable.

Citation : Genius

Si on n'avait pas réfléchi, on aurait codé avec @0 et on aurait des problèmes...
On voir alors que certains proposent @@, on code, mais il y a toujours des problèmes...

Oui, il y aura toujours des problèmes. Et c'est pas parce que je propose des exercices, que je ne fais pas d'erreurs. Je suis même content quand quelqu'un d'apparemment non-débutant comme toi, les corrige afin d'aider les vrais zéros.

Citation : Genius

Donc réflechir ne peut pas faire de mal avant de commencer, d'autant plus que l'on est le 2 juin et qu'il reste bien assez de temps pour coder

Tout à fait. Je discute encore volontiers pendant un mois avec vous tous sur ce sujet.

@Zopieux:
Merci bien ! Excellente initiative !
(Exercice suppléemntaire de C++ : Refaire le programme de Zopieux )

@Jaloyan1:
Bien sûr que ça marche. Et merci d'arrêter de contre-dire bêtement chaque chose que je dis.

Citation : Zopieux

J'ai l'impression que vous n'avez pas très compris le fait que l'exercice soit avant tout de vous entraîner même si les applications peuvent parraître moindres. Donc on s'en contre-fiche que ce soit pas efficace sur vos images, choisissez plutôt des textes répétitifs comme celui du générateur.

Tout à fait. Il est illusoire de penser qu'un débutant aussi motivé et intéressé soit-il puisse coder les algorithmes utilisés "industriellement". Mais les versions simplifiées sont là pour donner un aperçu et donner les intuitions nécessaires pour faire plus tard du "code de grande personne".

@Jaloyan1: S'il-te-plait. Arrête de poster 24h dans ce thread. Tu lis la donnée. Tu lis le lien wikipédia. Tu essayes dans ton coin et ensuite tu reviens. Merci.

J'ai toujours pas eu de réponse Nanoc : Quel est le problème avec @@@@ pour compresser ? J'arrive à le compresser en 4@@, et ceci se décompresse en @@@@.

Je n'ai pas compris où ça coince ?!

EDIT : J'essayerais plus tard, je suis pas encore avancer dans mon livre de C++ ...

@Kurlze:
Aucun problème. La chaîne "@@@@" sera codée comme "4#@" si # est le flag et comme "@@@@@@@@" si @ est le flag.

Je suis à peu près arrivé à créer l'algo sans flag et sans 1, il marche bien sur un fichier de test, mais sur un bmp, il s'arrête à la première ligne
Seulement cela ne semble pas provenir de l'algo, en effet si je fais un while (getline(flux, chaine)) (avec incrémentation à chaque tour, ça s'arrête à la première ligne...
Sur un autre fichier j'ai bien le nombre de lignes du fichier avec le même code...

@Nanoc : Pas débutant, c'est à voir ; peut être moins débutant que d'autres, mais bien plus débutant que toi par exemple

Pour un fichier image, as-tu penser à l'ouvrir en mode binaire ?

Je ne pense pas qu'en mode texte, la lecture puisse se faire sans encombres .

EDIT : pour ceux que ça intéresse, je me propose comme "trouveur de failles" : donnez-moi votre algo par MP, j'essaierai de trouver des chaînes qui le mettent en défaut .

Citation : Nanoc

@Kurlze:
Aucun problème. La chaîne "@@@@" sera codée comme "4#@" si # est le flag et comme "@@@@@@@@" si @ est le flag.

Si j'ai @@@@ avec @ comme flag, mon programme compresse en 4@@, donc aucun soucis, pourquoi @@@@@@@@ ?
Bon, on peut toujours utiliser un flag @ avec l'énoncé initial (Sans le double flag) ? Parce que je n'ai aucun problème avec mon programme (en utilisant le premier énoncé donné)

Parce que par définition, quand on rencontre le flag, on le compresse sous la forme spéciale @@ et pas selon le schéma habituel.

Okay, je vais donc suivre le nouvel énoncé : @ devient @@ même si on perd au lieu de gagner, et même si compresser le flag avec la méthode habituelle (@@@@ -> 4@@) me parait bonne (elle ne pose pas de problème au final).

Citation : Nanoc

Parce que par définition, quand on rencontre le flag, on le compresse sous la forme spéciale @@ et pas selon le schéma habituel.

Euh ... pourquoi? Je pensais que c'était une erreur dans l'énoncé où tu avais anticipé le point d'après, mais en fait non. Pourquoi ne pas s'autoriser à compresser le flag comme n'importe quel caractère? Pas en "4@@" bien sûr, vu qu'on ne saurait pas si la chaîne initiale est "4@" ou "@@@@" mais bien en "4@@@" comme les autres caractères. Je ne vois ce qui fait mériter une telle distinction de cas.

Citation : HunLyxxod

Citation : Nanoc

Parce que par définition, quand on rencontre le flag, on le compresse sous la forme spéciale @@ et pas selon le schéma habituel.

Euh ... pourquoi?

Parce que. Il y a pas d'aures raisons. Les deux options sont possibles. Il fallait bien en choisir une. Il n'y a aucune raison à ce choix.

Nanoc : serait il pas "mieux" que le premier caractère du fichier a decompresser soit le flag et alors lors de la compression l'utilisateur n'a pas besoin de se rappeler du flag qu'il a entré ce qui peut eviter de malencontreuses erreures.
Mais bien sur un caractère de plus dans le fichier compressé le rend moins compressé.

En théorie oui. Mais de cette manière, il y a une difficulté supplémentaire. Utiliser un argument du main comme paramètre du programme.

A bon ca pose un probleme d'utiliser un argument du main comme paramètre d'un programme ?
J'ai encore fait n'importe quoi alors parceque j'ai utilisé un argument du main comme paramètre d'une fonction sans faire attention.

Citation : poulecaca

A bon ca pose un probleme d'utiliser un argument du main comme paramètre d'un programme ?

Pas spécialement. Ca donne juste à réfléchir.

Faut il avoir la possibilité d'entrer le chemin de sorti j'imagine que oui

Soyez imaginatif !

Citation : zero ptt

admettons que 'x' est le frag, la syntaxe special devient @x oubien xx ?