principe de base de compression.

[Backup]

...............

[Le Soldat Inconnu]

pourquoi ne pas l'encoder tout simplement en base 32 par exemple, tu aurais une bien meilleur compression. Puisque que tu parle de compression de nombre binaire sous forme de texte.

0 00000
1 00001
2 00010
3 00011
4 00100
5 00101
6 00110
7 00111
8 01000
9 01001
A 01010
B 01011
C 01100
D 01101
E 01110
F 01111
G 10000
H 10001
J 10010
K 10011
L 10100
M 10101
N 10110
P 10111
Q 11000
R 11001
S 11010
T 11011
U 11100
V 11101
W 11110
X 11111

[Backup]

la vérité sort de la bouche des enfants
effectivement , ça serai encore plus mieux , et on evite l’écueil de la clef de decodage comprenant "1,0"
verrai demain si j'ai le courage de proposer un code

[G-Rom]

mon algo , ne gere pas toute la 10aine de répétitions : "100000000001" , car ça va donner "11001" , la décompression ne se fera pas
j'ai pas cherché a reglé ce probleme , ceci est un exemple

Ca m'apprendra à pas lire les posts en entier , j'étais en train d'écrire que ton algo était pourri
cherche algo de haufman ou un truc du genre, c'est simple à mettre en place.

[Cool Dji]

mon algo , ne gere pas toute la 10aine de répétitions : "100000000001" , car ça va donner "11001" , la décompression ne se fera pas
j'ai pas cherché a reglé ce probleme , ceci est un exemple

Ca m'apprendra à pas lire les posts en entier , j'étais en train d'écrire que ton algo était pourri

+1
J'allais juste user d'un peu plus de diplomatie, du style :
- Dobro, l'exemple 140 peut être décodé en 10000 ou 00000000000000 (quatorze zéros), non ?
Et là, je me serais pris une baffe en réponse :
- Bordel, lis-moi complètement avant de raconter n'importe quoi...

Mais heureusement G-Rom est passé par là avant !

[Backup]

oui cette compression a ce defaut

defaut qu'on peut retrouver dans toute compression basée sur des "Balises"
qui font partie aussi des données encodées ...

10 ,100,1000, etc peuvent etre confondu puisque ces balises ressemble a du binaire ...



Mon deuxième listing (le seul affiché dorénavant...) corrige quand même le probleme..
par exemple

- Dobro, l'exemple 140 peut être décodé en 10000 ou 00000000000000 (quatorze zéros), non ?

ceci sera decodé comme etant 4 fois "0"
parce que l'encodeur ne depassera jamais 9 fois "0"
pour justement éviter d'avoir un 1 ou un 0 dans le multiplicateur

donc l'encodeur ne pourra jamais ecrire 14 fois "0"
Car s'il rencontre 14 fois "0"
il écrira 9 fois "0" puis 5 fois "0"

ce qui donnera "9050" compressé , et "00000000000000" décompressé

cherche algo de haufman ou un truc du genre, c'est simple à mettre en place.

oui certain Algo marche bien ( le Lzh , le Arc , le Pc1 etc ... )
le but etant de réinventer la roue , des fois , on peut peut etre penser a un truc qui n'a pas été pensé avant ...
se contenter de reprendre le travail des autres , n'est pas la solution pour en découvrir des nouvelles ...

enfin , je dis ça , mais ma "compression" par le binaire , ce type d'algo est deja connu

[venom]

J'aime bien l'idée






@++

[Backup]

..

[SPH]

si j'en crois certain topic , je devrai etre millionaire


voici un code qui prends un nombre binaire et le reduit en taille
ceci est une introduction a la compression ..

l'algo est le suivant

je prends un chiffre binaire :

"1000011111"

si il n'y a qu'un seul "1" ou qu'un seul "0" je l'ecris tel quel
si il y a plusieurs "0" ou plusieurs "1" qui se suivent , je les comptes , et j'ecris d'abord le nombre, puis le "0" ou le "1"

avec le binaire ci dessus le résultat donne
"14051"
car il y a un "1" ---> donc "1"
il y a quatre "0" ---> donc "40"
il y a cinq "1" -----> donc "51"
ce qui donne bien "1 40 51" ---> "14051"

le binaire qui avait 10 caractères donne une chaine de 5 caractères ( compression 50% ) !

Ca parait magique mais tu dois retomber sur terre. Transformer le binaire "1000011111" en decimal "14051" est tout sauf de la compression. Et puis ca ne veux rien dire "14051". Il pourrait s'agir de 4051 "1". Il faut y integrer une regle pour qu'on ne se trompe pas. Et la, la compression deviens de l'expension...

[Backup]

.....

[Ar-S]

Ne serait-ce pas plus efficace comme ça ?

Postulat :
0 et 1 sont remplacés par A et B (ou 2 autres caractères au choix, on s'en fout, l'important est que ce ne soit pas 0 et 1)

Du coup la limitation à 9 cars saute.
En reprenant le "1000000000000000000" comme exemple on obtiendrait : B18 ce qui est plus court que 19090

"1000011111" devient "B1A4B5" ce qui est plus long que "14051"

Mais pourquoi s'ennuyer à mettre B1 alors que B = 1 !
On peut donc simplement marquer : "BA4B5" et on obtient le même bon taux de compression de 50% !

ça me parait pas trop con comme principe.

[Backup]

...

[minirop]

j'ai aussi précisé , ( pour le contexte binaire ) , que dans certains cas de figure

justement, tu mélanges les contextes. Ta « compression » ne marche que si on le fait sur une chaine de caractères ne contenant que des 0 et 1.

car pour un binaire du genre "100" ; ça va donner "120"

100 en binaire ça donne 0x04 (qui est un caractère non imprimable), alors que pour ta compression tu l'utilises en tant que chaine de caractères ce qui donne en binaire : 0011 0001 0011 0000 0011 0000. soit 0x31 0x30 0x30.