Les logiciels de compression sont a base d'un langage haut niveau ou bas niveau?
Si tout fichier A est codée en binaire tout fichier A peuvent être écrit dans un nouveau fichier.c .
ou le fichier.C il y un tableau qui contient une suite de nombre(le fichier A)
la décompression se fera en écrivent le tableau de fichier.C dans un fichier.
que pensez vous?
Que tu ferais mieux de te renseigner sur les logiciels de compression au lieu de lancer des hypothèses gratuites.Envoyé par extrazlove
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
La meilleure façon de compresser un fichier binaire est de changer de base .
Par exemple si tu passes d'un binaire pur et dur à un hexa tu as le schéma suivant :
1010 ---> A
Tu constates le gain de place : la compression est de 4 .
On obtient des taux de compression encore plus important en utilisant des bases encore plus puissantes (nombres chinois ou aztèques).
D'où la possibilité de transformer un fichier "tartempion.bin" (binaire pur) en
"tartempion.hex" (fichier hexa)
"tartempion.chn" (fichier codé chinois)
"tartempion.azt" (fichier codé aztèque)
mais écrire un grand nombre dans un tableau de type unsigned double sa permet d'enregistrer tout un fichier dans quelque case de tableau.
Le problème c'est que tu ne peux pas changer de base : en info tout est finalement en binaire. Alors je ne vois pas où tu veux en venir, ni quel rapport ça a avec un forum de programmation.
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
la taille de unsigned double tableau [100000]={0}
= la taille de unsigned double tableau [100000]={1111111111111111...000...100 000}
si en fait un if(taillemaxvariable>tableau[i])
tableau[i]=octet*10+octet
a la fin tableau=fichier.c
taille fichier.c 1ko.
décompresser fichier.c
reviens a envoyer les tableau[i] dans les case d'un nouveau fichier copier de l'original.
Je n'ai rien compris.
Entièrement d'accord
Nous voila bien avancés: tu le stockes comment le A? Je dirais ... 10101010 ---> A
Tu constates le gain de place : la compression est de 4 .
imagine que fichier =0010 1001 0001 100011101100010010101000000010 000001110010101010101000100001 ....1010 sans espace.
compression
si en prend en met dans un variable dans la base 10 tableau[0]=0010 tableau[1]=1001 et tableau[2]=1001....tableau[nombre octet-1]=1010
tableau[0]=tableau[0]*10+tableau[1]=10*2+9=29
tableau[1]=tableau[1]*10+tableau[2]=10*9+1=91
......
tableau[i]=tableau[i]*10+tableau[i+1]=tableau[i]tableau[i+1]
resultat tableau[0]=image de fichier.c avec 1ko a la fin en supprimant tout les cases de mémoire crée de 1 a i.
décompression
écrire la valeur de variable tableau dans fichier.c dans un nouvelle fichier qui sera identique a l’orignal.
Bonjour,
Comme personne ne se dévoue, je me lance : extrazlove, tout ce que tu as écrit est un pur tissu d'absurdité.
Dans une case mémoire on peut stocker 0 ou 1. Et c'est tout. C'est ce qu'on appelle un bit (BInary digiT, c'est à dire chiffre binaire).
Pour des question de rapidité et de commodité on groupe les cases mémoires par 8 : un octet dans lequel on peut écrire une valeur entre 0 et 255 (ou [-127, 128], au choix.
Pour les même raisons, on groupe les octets par 2, 4 ou 8 (sur les machines usuelles, plus sur de gros ordinateurs) mais 8 octets, ça reste 64 bits, et certainement pas autre chose.
Tu prends vraiment les informaticiens pour des idiots d'inventer des algorithmes de compression aussi subtils que LZW ou le Codage de Huffman ou la FFT si une solution bateau comme la tienne fonctionnait ?
Bon, sans rancune
A+
Ce qui se conçoit bien s'énonce clairement ; et les mots pour le dire arrivent aisément.
Sinon, pour répondre à ta question initiale, on demande en général aux programmes de compression/décompression d'être très rapide, ce qui oblige à les écrire dans un langage d'assez bas niveau (le C ou C++, par exemple).
On descend peut-être jusqu'au niveau de l'assembleur pour des codec vidéo, mais je n'en sais rien.
Les implémentation de plus haut niveau, comme en java ou php sont faites à l'aide de méthodes "natives", c'est-à-dire écrites en C et compilées.
A+
Ce qui se conçoit bien s'énonce clairement ; et les mots pour le dire arrivent aisément.
Bjr à toi,
Je connais un sytéme tout bete qui : TANT QUE l'information est identique , on "compte" le nombre de fois l'identité et on le représente par :info initiale x fois (répétée).
Ce qui donnerait 10 10 10 10 10 10 10 10 10 = 10x fois 9 = (10x9 en écriture prends moins de place que la succsesion répétive de 10)
C'est le peu que je connaisse en terme de compression.
A+
La mesquinerie et rabrouement est un indicateur d'état d'esprit de l'auteur.
BonjourCe que tu ne vois pas, c'est que pour écrire la lettre A, on doit utiliser 8 bits (si l'on parle du caractère ASCII) :
'A' = 01000001 en binaire
Bref, au lieu de réduire la taille d'un facteur 4, on la double.
Ton erreur de raisonnement vient certainement du fait que tu considères au départ qu'un fichier binaire est un fichier de texte constitué des caractères 0 et 1. Or ce n'est pas le cas :
• Dans un fichier binaire ("tartempion.bin" par exemple), les 0 et les 1 sont stockés dans des bits. Un fichier de 1024 bits occupe 1024/8=128 octets.
• Dans un fichier texte, les caractères occupent une place variant avec le type de codage utilisé :
- un fichier HEXA ("tartempion.hex") est un fichier ASCII contenant des caractères 0 à 1 et A à F, et des caractères d'espacement et de saut de ligne. Chacun de ces caractère occupe un octet, soit 8 bits. La valeur binaire 1010 0101 0001 0100 (16 bits) est codée à l'aide des caractères "A514", qui occupent 4 octets (32 bits). Un fichier hexa représentant 1024 bits occupe plus de 2 Ko, puisqu'il inclut également des espaces, des sauts de ligne et des informations propres au format HEXA (type, adresse, checksum...).
- il en va de même pour un fichier de code source en langage C (.c), qui est également un fichier ASCII.
- un fichier texte en aztèque ("tartempion.azt") ou en chinois ("tartempion.chn") peut être représenté par des codes UNICODE, sur 17 bits pour les pictogrammes aztèques (à partir de U+15C00) et sur 18 bits pour les idéogrammes chinois (à partir de U+20000), et codé par exemple en UFT-8, qui est système dans lequel la taille de chaque caractère peut varier de 1 à 4 octets... et on a ici beaucoup plus souvent 4 octets qu'un seul, compte tenu du type de caractères à représenter. On peut donc dire qu'un tel fichier contenant 1024 de ces caractères occupe environ 4 Ko.
Comme tu peux le constater les fichiers utilisant des caractères codés prennent plus de place que le fichier binaire pur.
Ce n'est pas ce genre d'opération que tu décris qui permet de faire une compression.
Dernière modification par PA5CAL ; 21/04/2013 à 10h00.
pour moi un fichier de 30 mg c un fichier de forme 0101010101110001.....0 nombre de bit représente la taille de fichier.
et le fichier équivalent avec un mémoire de quelque k octet.
contient le chiffre de fichier dans des variables de type usine double A ou je peu écrire des grands nombre jusqu'à 3.8*104932
donc logiquement tout le fichier de 30mg sera transfert dans 1 voir 10 variable simple de type usine double qui dépasse pas quelque ko dans la mémoire .
au niveau de programmation en peut rien comprendre mais en électronique un grand chiffre c un simple calcul fait par le microprocesseur.
pour avoir le fichier orignal il suffit de décompresser les variables dans un fichier sous forme A1A2A3...AI
Dernière modification par extrazlove ; 21/04/2013 à 14h39.
Si tu faisais l'effort d'écrire correctement, avec des phrases contenant un verbe et un sujet accompagné d'un article (et je ne parle même pas de l'orthographe ni des abréviations SMS), nous aurions, toi et nous, plus de facilité à comprendre de quoi il retourne.
Le peu que je comprend est foncièrement faux. Il te suffit de prendre un fichier de 30 Mo (contenant par exemple les 250 premiers millions de bits représentant la valeur de pi), et de m'expliquer par quel miracle on peut encore faire tenir l'ensemble de ces informations dans les 40 octets qu'occupent 10 variables de type double.
Si tu penses qu'un double peut contenir n'importe quel nombre avec une précision infinie, alors je t'invite à faire le calcul suivant :
1.0e32 + 1.0e-32 = ?
En toute logique, le résultat devrait être :
1.000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 00 01 e32
mais bizarrement, le résultat obtenu n'est que 1.0e32 ! On a perdu des informations !!!
Et si tu veux, tu peux le vérifier par programme :Code:double a = 1.0e32; double b = 1.0e-32; printf("%g + %g = %g\n", a, b, a+b); if ( (a+b) == a ) printf("Egalite !\n");
Dernière modification par PA5CAL ; 21/04/2013 à 14h45.
Oups... le double est sur 8 octets, et non pas 4 comme je viens de l'écrire, ce qui correspond au float. Mais ça ne change rien au fond du problème.
Bonjour,
Si tu es capable de faire ça, je te garantis que tu seras nommé "plus grand génie de tous les temps, passés et futurs"
C'est vraiment n'importe quoi, et on peut remplacer le mot génie par un autre, beaucoup moins flatteur (je te laisse le soin de le choisir toi-même, pour - peut-être - éviter la modération).
Par exemple Alan Turing du XXIème siècle ? Ou Alan Bug ?
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Pour info, conformément à la norme IEEE 754, un double est représenté par un ensemble d'informations numériques qui sont, pour un nombre rationnel courant :
- S : le bit de signe, indiquant le signe du nombre
- E : l'exposant sous forme binaire signé, indiquant la puissance de deux par lequel on multiplie la mantisse
- M : la mantisse sous forme binaire, ôtée du premier bit de poids fort
Si le contenu d'un double s'écrit à l'aide des 64 bits :
SEEEEEEE EEEEMMMM MMMMMMMM MMMMMMMM MMMMMMMM MMMMMMMM MMMMMMMM MMMMMMMM
alors le nombre représenté est :
(-1)^S * 1.MMMM MMMMMMMM MMMMMMMM MMMMMMMM MMMMMMMM MMMMMMMM MMMMMMMM * 2^(EEEEEEE EEEE)
Comme tu le vois, il n'y a pas une infinité de "MMMM....", mais seulement 52.
Par conséquent, les nombres ne peuvent pas être représentés avec une précision meilleure que 2^-52 (soit environ 10^-15).
Autrement dit, on peut affirmer qu'un double utilisé comme tu le préconises ne contient guère plus de 52 bits d'information en moyenne.
Pour faire tenir un fichier quelconque de 30 Mo dans des double (sans autre forme de compression), il en faudrait plus de 600000 variables de ce type. Et ça prendrait 37 Mo pour les stocker.
Dernière modification par PA5CAL ; 21/04/2013 à 15h16.
Re-oup... il faut lire :
(-1)^S * 1.MMMM (...) MMMMMMMM * 2^(EEEEEEE EEEE - 63)
Alors fais-le !
Ce qui se conçoit bien s'énonce clairement ; et les mots pour le dire arrivent aisément.
pour avoir des variable usines double avec grand précision il faut utilisé des calcules des algorithmes voir http://www.siteduzero.com/forum/suje...recision-46590
puis supprimer tout pour garder que A1A2A3..AI ou un A1=A1*10+A2 représente un chiffre de <3.8*104932 soit un gain de bit de 10*104932 de bit.
Dernière modification par extrazlove ; 21/04/2013 à 16h09.
Bonjour,
bon une fois qu'on a réussi à décoder (sans jeu de mots) la pensée de extrazlove qui semble un peu «ésotérique» et pour le moins confuse, on peut arriver à supposer qu'il parle simplement du codage arithmétique utilisé je crois par bzip2 (entre autre). L'évocation du changement de caractères (chinois, aztèque) peut même faire penser des versions utilisant un encodage en bases différentes, mais bon. Sa pensée n'est pas très claire et cette méthode de compression est déjà largement étudiée et utilisée.
Quelques rappels amusants :
pour toutes suites quelconque de n bits de long (n pouvant être arbitrairement grand) il existe un algorithme de compression qui en sortie fournit un fichier de 1 bit de long
pour tout algorithme de compression il existe au moins un fichier qui ne pourra être compresséBon dimanche
C'est n'importe quoi...
Quoi que tu fasses, le contenu d'une variable en virgule flottante prend plus de place que la valeur entière qu'il peut représenter. Et si tu supprimes des bits, tu supprimes des informations que tu ne peux plus retrouver ensuite.
Donne un exemple, et tu te rendras peut-être compte de ton erreur.
Dernière modification par PA5CAL ; 21/04/2013 à 16h16.
Ce n'est pas ce que j'ai compris au travers de ses (tentatives d') explications.
Quoi qu'il en soit, il est impossible de prédire un taux de compression par cette méthode comme il le fait. A priori, un fichier binaire quelconque de 30 Mo ne tient pas dans une dizaine de variables double ... a fortiori si ce fichier est une archive .bz2 déjà fortement compressée.
Bah en fait si ... Mais la confusion vient du fait de croire qu'il existe un compresseur universel (qui quel que soit le fichier d'entrée donne un fichier plus petit qui une fois décompressé redonne le fichier d'entrée).
Mais quelque soit le fichier de 30Mo particulier tu me donnes je peux te construire un programme de compression qui compressera ce fichier particulier en un fichier de 1 bit de long et le programme de décompression qui va avec
C'est trivial à faire même mais n'est d'aucune utilité.
Ce que notre pauvre extrazlove doit comprendre est qu'il n'existe aucun compresseur universel.
Et ce programme pèsera combien ? 40 Mo ?Mais quelque soit le fichier de 30Mo particulier tu me donnes je peux te construire un programme de compression qui compressera ce fichier particulier en un fichier de 1 bit de long et le programme de décompression qui va avec
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Même si c'est vrai (avec un décompresseur qui contient déjà les 30 Mo de données attendues), tu ne devrais pas écrire ça sans explication, sinon certains pourraient croire l'inverse de ce que ça signifie.Bah en fait si ... Mais la confusion vient du fait de croire qu'il existe un compresseur universel (qui quel que soit le fichier d'entrée donne un fichier plus petit qui une fois décompressé redonne le fichier d'entrée).
Mais quelque soit le fichier de 30Mo particulier tu me donnes je peux te construire un programme de compression qui compressera ce fichier particulier en un fichier de 1 bit de long et le programme de décompression qui va avec
C'est trivial à faire même mais n'est d'aucune utilité.
Et en fait non, puisqu'on parle de compression arithmétique (sous-entendu standard), ce qui fixe a priori l'algorithme de compression et de décompression. Par conséquent il n'est pas possible d'affirmer pouvoir comprimer à 1 bit un fichier quelconque de 30 Mo par cette méthode.
Dernière modification par PA5CAL ; 21/04/2013 à 16h41.
Ça va dépendre fortement du fichier que tu vas me donner, sur quelle plateforme etc ... Si tu choisis bien ton fichier créer un couple (fichier compressé, décompresseur) dont la taille soit inférieure à la taille du fichier d'origine sera plus compliqué à trouver.
Il y a des algos de compression (sans pertes, bien sur) à base de FFT ?
Alors pour clarifier ce que je dis :
1. Les élucubrations de extrazlove peuvent de rapprocher du codage arithmétique ... pour moi cela reste des élucubrations malgré tout mais avec un fond de réalité. Dans toute la suite je ne parle plus que d'algorithmes de compression au sens large sans me référer à une technique particulière.
2. Je dis bien qu'un compresseur universel n'existe pas, on ne parle donc pas de l'algorithme de compression mais d'un algorithme de compression. Je dis aussi que quel que soit l'algorithme de compression il existe des fichiers qui ne pourront être compressés.
3. Maintenant oui il est possible de créer (plus ou moins facilement) un algorithme qui pour un fichier particulier donné en entrée va produire un fichier de 1 bit de long (évidemment ça n'existe sur aucun OS, on peut remplacer 1 bit par la taille que tu veux en octet) et le programme associé qui fait le boulot inverse. Considère simplement le fichier E que tu me donnes en challenge(qui peut d'ailleurs être un fichier déjà compressé par bzip2) comme un super grand nombre binaire B et l'algorithme de compression comme une simple fonction des entiers dans les entiers f. On construit f ainsi (c'est une construction possible) :
f(0)->B
f(B)->0
f(n)->n pour tout n autre que 0 ou B
f-1 est la décompression.
Ensuite la façon de programmer f, de la plateforme, le choix de B, ... fait qu'il est plus ou moins difficile d'obtenir ce que chacun a dans la tête comme définition «propre» de compresseur.
Edit: Je parle uniquement de compression sans perte (suite au message de Bruno)
