La compression est a base d'un langage haut bas niveau?
Résolu/Fermé
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
-
Modifié par extrazlove le 21/04/2013 à 20:08
Utilisateur anonyme - 25 avril 2013 à 16:56
Utilisateur anonyme - 25 avril 2013 à 16:56
A voir également:
- La compression est a base d'un langage haut bas niveau?
- Formules excel de base - Guide
- Comment compresser un fichier pdf - Guide
- Germain veut gérer les activités de son association avec une base de données. il a commencé à créer des tables dans un fichier, mais il n’est pas sûr du résultat. le fichier à télécharger contient uniquement le schéma de cette base de données. en l’état actuel, que peut-on en déduire ? - Forum Outlook
- Tnt base de données vide ✓ - Forum TNT / Satellite / Réception
- Logiciel de compression gratuit - Guide
9 réponses
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
21 avril 2013 à 20:43
21 avril 2013 à 20:43
Peu importe que le langage soit de haut ou bas niveau pour la compression de données, il faut juste pouvoir manipuler les valeurs à l'échelle du bit, ce qui est toujours possible avec les opérations de base...
Par contre, tu confonds 8192 bits et valeur de 0 à 8191! 8192 bits = valeur de 0 à 2^8192 - 01, ça n'a rien à voir!
Donc au risque de t'étonner, 8192 bits ça tient dans...8192 bits, point!
Par contre des techniques moins simplistes et plus réalistes donnent des vrais résultats: https://fr.wikipedia.org/wiki/Compression_de_donn%C3%A9es
Par contre, tu confonds 8192 bits et valeur de 0 à 8191! 8192 bits = valeur de 0 à 2^8192 - 01, ça n'a rien à voir!
Donc au risque de t'étonner, 8192 bits ça tient dans...8192 bits, point!
Par contre des techniques moins simplistes et plus réalistes donnent des vrais résultats: https://fr.wikipedia.org/wiki/Compression_de_donn%C3%A9es
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
21 avril 2013 à 20:52
21 avril 2013 à 20:52
- Une structure sont la taille est 32 bits ne peut pas contenir plus de ... 32 bits.
- La structure qui peut représenter un entier compris entre 0 et 65535 est un short int dont la taille est 16 bits.
- La structure qui peut représenter un entier compris entre 0 et 65535 est un short int dont la taille est 16 bits.
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
21 avril 2013 à 21:21
21 avril 2013 à 21:21
Oui, mais t'es quand même en train de dire qu'on peut mettre 8192 bits dans 16 bits... car c'est bien le principe de la compression dont tu parles, n'est-ce pas!
Tu te trompe en faisant des conversions qui ne sont plus comparables, et tu les compares quand même!
Une valeur de 0 à 8191 tient dans 13 bits.
8192 bits contiennent 512 structures short int...
Tu te trompe en faisant des conversions qui ne sont plus comparables, et tu les compares quand même!
Une valeur de 0 à 8191 tient dans 13 bits.
8192 bits contiennent 512 structures short int...
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
21 avril 2013 à 21:36
21 avril 2013 à 21:36
oui ,pour moi le fichiers décompressé contient qu un short int de valeur=au fichier original en décimal et d'un taille de 16 octet
pour avoir le fichier originelle il faut écrire se chiffre dans un nouveau fichier de même type que l'orignal.
pour avoir le fichier originelle il faut écrire se chiffre dans un nouveau fichier de même type que l'orignal.
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
Modifié par nicocorico le 21/04/2013 à 21:54
Modifié par nicocorico le 21/04/2013 à 21:54
Ha oui excuse-moi j'avais interprété 16 bits et non pas 16 octets, pour moi un short int c'est un mot, de deux octets donc (en delphi).
Mais bon ça change absolument rien, tu parles de décimal, alors que ce n'est qu'une représentation différente et qui n'a aucun sens ici, l'ordinateur ne comprend pas le décimal, ça sert simplement à l'humain qui l'utilise, et parfois, l'induit en erreur!
Oublie un instant la représentation décimale, et dis-toi que 16 octets ça fait 128 bits, et que dans ces 128 bits tu veux faire tenir 8192 bits!
Autrement dit:
128 = 8192
Donc maintenant sur cette base quelque peu extra-terrestre, essaie de t'expliquer comment tu parviens à le faire...
Et ensuite, de nous l'expliquer!
Mais bon ça change absolument rien, tu parles de décimal, alors que ce n'est qu'une représentation différente et qui n'a aucun sens ici, l'ordinateur ne comprend pas le décimal, ça sert simplement à l'humain qui l'utilise, et parfois, l'induit en erreur!
Oublie un instant la représentation décimale, et dis-toi que 16 octets ça fait 128 bits, et que dans ces 128 bits tu veux faire tenir 8192 bits!
Autrement dit:
128 = 8192
Donc maintenant sur cette base quelque peu extra-terrestre, essaie de t'expliquer comment tu parviens à le faire...
Et ensuite, de nous l'expliquer!
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
21 avril 2013 à 22:01
21 avril 2013 à 22:01
Ah non tu t'es juste trompé en parlant d'octets, décidément tu devrais vraiment revoir tes notions de conversions, franchement!
Tu vois dans 16 bits tu fais tenir une valeur jusqu'à 65535, une seule valeur de 0 à 65535 donc... c'est pas 65535 bits!
Tu vois dans 16 bits tu fais tenir une valeur jusqu'à 65535, une seule valeur de 0 à 65535 donc... c'est pas 65535 bits!
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
22 avril 2013 à 21:24
22 avril 2013 à 21:24
tout fichier écrire en binaire est un chiffre qui grandi selon la taille qui occupe le fichier dans la mémoire.
et si je prend ce chiffre je met dans une case mémoire voir plusieurs ca dépend de grandeur de chiffre
quand je veut avoir le fichier orignal j'écris simplement ce chiffre dans un fichier vide de même type que l'orignal.
et si je prend ce chiffre je met dans une case mémoire voir plusieurs ca dépend de grandeur de chiffre
quand je veut avoir le fichier orignal j'écris simplement ce chiffre dans un fichier vide de même type que l'orignal.
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
22 avril 2013 à 21:35
22 avril 2013 à 21:35
En fait, non!
Un fichier écrit en binaire... ça ne veut rien dire, un fichier ne peut pas être écrit autrement qu'en binaire, ce n'est qu'une facilité si tu peux écrire du texte, mais ce texte est converti en binaire, bien sûr!
Et tu parles de chiffre qui grandi, ou plutôt un nombre, alors d'accord, si on considère les bits d'un fichier comme constituants d'un même nombre, on obtient un nombre de plus en plus grand au fur et à mesure qu'on avance dans le fichier effectivement. Mais ce nombre, plus il grandi, plus il faut de bits pour le représenter, n'est-ce pas? D'ailleurs c'est bien ce qui se passe, on ajoute la valeur de chaque bit, à une position de plus en plus élevée! En fait ton fichier faisant 1 ko, on a un nombre occupant 1ko, tu comprends? Autrement dit si on reprend l'exemple avec ton smallint de 2 octets, hé bien dans ce fichier on peut en mettre 512, t'es d'accord? Donc, le fichier contient 512 smallint, comment veux-tu faire tenir ces 512 smallint dans un seul smallint?! Est-ce que tu me suis!
Là en fait ça revient à dire que 512 = 1!
Un fichier écrit en binaire... ça ne veut rien dire, un fichier ne peut pas être écrit autrement qu'en binaire, ce n'est qu'une facilité si tu peux écrire du texte, mais ce texte est converti en binaire, bien sûr!
Et tu parles de chiffre qui grandi, ou plutôt un nombre, alors d'accord, si on considère les bits d'un fichier comme constituants d'un même nombre, on obtient un nombre de plus en plus grand au fur et à mesure qu'on avance dans le fichier effectivement. Mais ce nombre, plus il grandi, plus il faut de bits pour le représenter, n'est-ce pas? D'ailleurs c'est bien ce qui se passe, on ajoute la valeur de chaque bit, à une position de plus en plus élevée! En fait ton fichier faisant 1 ko, on a un nombre occupant 1ko, tu comprends? Autrement dit si on reprend l'exemple avec ton smallint de 2 octets, hé bien dans ce fichier on peut en mettre 512, t'es d'accord? Donc, le fichier contient 512 smallint, comment veux-tu faire tenir ces 512 smallint dans un seul smallint?! Est-ce que tu me suis!
Là en fait ça revient à dire que 512 = 1!
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
Modifié par nicocorico le 22/04/2013 à 21:46
Modifié par nicocorico le 22/04/2013 à 21:46
Voilà, ce qu'il faut que tu comprennes, c'est qu'un bit c'est un chiffre, mais binaire! Donc par exemple on a un compteur à quatre chiffres décimaux, avec ce compteur on peut aller jusqu'à 9999, d'ac? Maintenant si on enlève un chiffre, on ne peut plus dépasser les 999, évidemment... Et en binaire, c'est pareil! Si tu enlève un chiffre, tu limites la valeur maximale de la même manière! Avec 4 bits, tu peux compter jusqu'à 15 (1111), si t'enlève un bit tu dépassera plus 7 (111), et voilà!
Tu t'embrouille tout simplement en faisant des conversions qui perdent leur sens! Reste dans les même mesure pour pouvoir les comparer, et tu comprendras mieux!
Tu t'embrouille tout simplement en faisant des conversions qui perdent leur sens! Reste dans les même mesure pour pouvoir les comparer, et tu comprendras mieux!
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
22 avril 2013 à 22:21
22 avril 2013 à 22:21
et pourquoi dans un fichier.c
double i=1; taille 16 octet
et double t=1.7*10308; 16 octet
si mon fichier=1.7*10305 en décimal (pour moi un chiffre décimal c une octet )
et je met tout le fichier=t le programme va pas planté car un double peut contenir ce chiffre dans 16 octet.
double i=1; taille 16 octet
et double t=1.7*10308; 16 octet
si mon fichier=1.7*10305 en décimal (pour moi un chiffre décimal c une octet )
et je met tout le fichier=t le programme va pas planté car un double peut contenir ce chiffre dans 16 octet.
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
22 avril 2013 à 22:32
22 avril 2013 à 22:32
Oui mais justement c'est bien ce que tu n'as pas compris, un nombre c'est un octet! Un octet peut contenir n'importe quel nombre de 0 à 255, c'est tout, rien de plus! Pour mettre un nombre plus grand, ou pour mettre des chiffre derrière une virgule, il faut plus de bits, c'est tout!
Et chaque variable fait une certaine taille, cette taille est indépendante de son contenu bien sûr!
Donc si tu as un smallint qui occupe 16 bits, que tu y mette 1 ou 32000 n'y change rien, il occupe 16 bits dans tous les cas! La taille d'une variable en défini les limites sans qu'il y ait de chevauchement malheureux avec une autre variable! Donc l'espace occupé est fixe!
Et chaque variable fait une certaine taille, cette taille est indépendante de son contenu bien sûr!
Donc si tu as un smallint qui occupe 16 bits, que tu y mette 1 ou 32000 n'y change rien, il occupe 16 bits dans tous les cas! La taille d'une variable en défini les limites sans qu'il y ait de chevauchement malheureux avec une autre variable! Donc l'espace occupé est fixe!
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
Modifié par extrazlove le 22/04/2013 à 22:07
Modifié par extrazlove le 22/04/2013 à 22:07
c pas grave en va mettre dans les cases mémoire que des nombres assez grand
imagine que mon fichier et sous cette forme A1A2A3....Ai en binaire
en fixons une limite pour avoir A1 assez grand avec un type long ou double combien en aura du gain de mémoire
imagine que mon fichier et sous cette forme A1A2A3....Ai en binaire
en fixons une limite pour avoir A1 assez grand avec un type long ou double combien en aura du gain de mémoire
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
22 avril 2013 à 22:04
22 avril 2013 à 22:04
Le type employé n'y change rien!
Imagine! Dans 16 bits on peut mettre une valeur jusque 65535, donc une valeur de 0 à 65535 peut tenir dans 16 bits.
Pour représenter 16 bits, il faut donc retenir une valeur comprise entre 0 et 65535... et pour retenir cette valeur comprise entre 0 et 65535 il nous faut...16 bits!
Imagine! Dans 16 bits on peut mettre une valeur jusque 65535, donc une valeur de 0 à 65535 peut tenir dans 16 bits.
Pour représenter 16 bits, il faut donc retenir une valeur comprise entre 0 et 65535... et pour retenir cette valeur comprise entre 0 et 65535 il nous faut...16 bits!
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
22 avril 2013 à 22:14
22 avril 2013 à 22:14
Allez va, travaille donc un peu tes bases pour éviter de te casser la tête pour rien! C'est important de bien comprendre comment les nombres sont traités par l'ordinateur, tu y verras plus clair!
https://fr.wikipedia.org/wiki/Syst%C3%A8me_binaire
https://fr.wikipedia.org/wiki/Syst%C3%A8me_binaire
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
22 avril 2013 à 22:51
22 avril 2013 à 22:51
Une structure sont la taille est 32 bits ne peut pas contenir plus de ... 32 bits.
- La structure qui peut représenter un entier compris entre 0 et 65535 est un short int dont la taille est 16 bits.
- La structure qui peut représenter un entier compris entre 0 et 65535 est un short int dont la taille est 16 bits.
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
22 avril 2013 à 22:58
22 avril 2013 à 22:58
Haa mais on avance dirait-on!
Donc une structure de 1024 octets contient 512 smallint, et un smallint ne peut pas contenir 512 smallint!
Pourtant c'est exactement ce que tu affirme en faisant des conversions et des comparaisons infondées!
Donc une structure de 1024 octets contient 512 smallint, et un smallint ne peut pas contenir 512 smallint!
Pourtant c'est exactement ce que tu affirme en faisant des conversions et des comparaisons infondées!
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
Modifié par extrazlove le 22/04/2013 à 23:46
Modifié par extrazlove le 22/04/2013 à 23:46
un fichier1 ko possède 1024 octet =8192 bit donc un chiffre entre 0 et un chiffre trop grand mais c pas grave même ce chiffre peut être contenu dans un structure plus petit .
chiffre trop grand impossible de le mettre dans 16 bit
mais fonction(chiffre trop grand )=un chiffre petit que en peut mettre dans 16 bit non?
et fonction-1 (un chiffre petit )= chiffre trop grand.
chiffre trop grand impossible de le mettre dans 16 bit
mais fonction(chiffre trop grand )=un chiffre petit que en peut mettre dans 16 bit non?
et fonction-1 (un chiffre petit )= chiffre trop grand.
Char Snipeur
Messages postés
9813
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 297
23 avril 2013 à 09:01
23 avril 2013 à 09:01
Salut.
belle patiente nicocorico !
Je pense que la confusion viens du double, qui peut stocké des nombres allant jusqu'à 1e330 (en décimal) je crois, c'est à dire qu'on a l'impression que la valeur codé par 8192bits tiendrais dans un double. C'est en partie vrai MAIS c'est oublié certaines spécificités des nombres à virgules flottante.
un double est codé sur 64 bits, https://en.wikipedia.org/wiki/Double_precision avec seulement 52 bits pour la mantisse. La conséquance, c'est qu'il n'y a plus aucune information au dela de 15 chiffres (décimaux) après la virgule.
Pour s'en convaincre, essai le code suivant :
tu verra que b-a retourne 0, car 1. est sous la précision de 3e20.
Renseigne toi sur les algorithmes de compression, tu verra que les plus efficaces font des hypothèses sur le type de grandeur représenté (texte, son, image).
belle patiente nicocorico !
Je pense que la confusion viens du double, qui peut stocké des nombres allant jusqu'à 1e330 (en décimal) je crois, c'est à dire qu'on a l'impression que la valeur codé par 8192bits tiendrais dans un double. C'est en partie vrai MAIS c'est oublié certaines spécificités des nombres à virgules flottante.
un double est codé sur 64 bits, https://en.wikipedia.org/wiki/Double_precision avec seulement 52 bits pour la mantisse. La conséquance, c'est qu'il n'y a plus aucune information au dela de 15 chiffres (décimaux) après la virgule.
Pour s'en convaincre, essai le code suivant :
double a=3e20;
double b=a;
for (double c=0.;c<1e13;c+=1.)
b+=1.0;
cout<<b-a;
tu verra que b-a retourne 0, car 1. est sous la précision de 3e20.
Renseigne toi sur les algorithmes de compression, tu verra que les plus efficaces font des hypothèses sur le type de grandeur représenté (texte, son, image).
nicocorico
Messages postés
799
Date d'inscription
dimanche 19 juin 2011
Statut
Membre
Dernière intervention
3 juillet 2018
138
Modifié par nicocorico le 23/04/2013 à 19:18
Modifié par nicocorico le 23/04/2013 à 19:18
@Char sniper, n'est-ce pas! C'est utile, là!
En fait Extrazlove pense qu'un nombre quel que soit sa taille est un octet, et donc tiens dans 8 bits!
Donc voilà, à nouveau:
Un nombre décimal est constitué de chiffres décimaux, si tu enlèves des chiffres, tu perds des informations, n'est-ce pas! Donc on ne peut pas diminuer ce nombre sans perdre des informations!
En binaire, c'est pareil! Un bit c'est un chiffre aussi, mais binaire cette fois.. Si tu enlève des bits, tu perd des informations! Donc tu peux considérer qu'un fichier d'un KiloOctet c'est un très grand nombre unique, mais dans ce cas c'est un nombre qui fait 8192 bits! Et tu ne peux pas en retirer sans perte! Ou alors il faut passer par des techniques de compression, et rien d'autre!
En fait Extrazlove pense qu'un nombre quel que soit sa taille est un octet, et donc tiens dans 8 bits!
Donc voilà, à nouveau:
Un nombre décimal est constitué de chiffres décimaux, si tu enlèves des chiffres, tu perds des informations, n'est-ce pas! Donc on ne peut pas diminuer ce nombre sans perdre des informations!
En binaire, c'est pareil! Un bit c'est un chiffre aussi, mais binaire cette fois.. Si tu enlève des bits, tu perd des informations! Donc tu peux considérer qu'un fichier d'un KiloOctet c'est un très grand nombre unique, mais dans ce cas c'est un nombre qui fait 8192 bits! Et tu ne peux pas en retirer sans perte! Ou alors il faut passer par des techniques de compression, et rien d'autre!
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
Modifié par extrazlove le 23/04/2013 à 20:31
Modifié par extrazlove le 23/04/2013 à 20:31
si comme même sans perte puisque un nombre grand de 8192bit= factoriel(A1 8bit)+(A2 8bit) )
donc mon nombre grand de 8192bit et représentable avec deux entier A1 et A2.
donc mon nombre grand de 8192bit et représentable avec deux entier A1 et A2.
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
Modifié par extrazlove le 23/04/2013 à 21:05
Modifié par extrazlove le 23/04/2013 à 21:05
pour avoir des variable avec grand précision il faut utilisé des calcules des algorithmes voir https://openclassrooms.com/forum/sujet/calcul-de-precision-46590
si on a A1 et A2 notre compression et fini.
pour trouver A1 et A2 faut juste faire une comparaison entre factoriel(A1 8bit)+(A2 8bit) ) et notre fichier .
si on a A1 et A2 notre compression et fini.
pour trouver A1 et A2 faut juste faire une comparaison entre factoriel(A1 8bit)+(A2 8bit) ) et notre fichier .
Nyctaclope
Messages postés
5315
Date d'inscription
dimanche 6 avril 2008
Statut
Membre
Dernière intervention
11 décembre 2022
1 250
24 avril 2013 à 15:21
24 avril 2013 à 15:21
Bonjour à tous !
Discussion passionnante ( ou monologue persistant ? ) ..
Je soumet à votre sagacité le problème suivant :
"comment compresser quelques milliards de bits sur DEUX octets ?"
Réponse :
"Pi" ( 2 octets = 16 bits )
permet de stocker un nombre de quelques milliards de digits, inclus ceux qui ne sont pas encore connus , ou ne le seront jamais ..
ou encore :
0
contient toute la présente discussion ( pas encore prête d'être terminée, j'imagine )
A+
Nyctaclope
Discussion passionnante ( ou monologue persistant ? ) ..
Je soumet à votre sagacité le problème suivant :
"comment compresser quelques milliards de bits sur DEUX octets ?"
Réponse :
"Pi" ( 2 octets = 16 bits )
permet de stocker un nombre de quelques milliards de digits, inclus ceux qui ne sont pas encore connus , ou ne le seront jamais ..
ou encore :
0
contient toute la présente discussion ( pas encore prête d'être terminée, j'imagine )
A+
Nyctaclope
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
Modifié par extrazlove le 24/04/2013 à 20:44
Modifié par extrazlove le 24/04/2013 à 20:44
oui mais la mémoire dans un ordinateur sais pas très bien gérer des nombres flottant tel que pi avec prisions....
Bon voila mon but c'est avoir un t entier assez petit qui peut s'écrire dans un octet voir deux.
Si n représente un grand nombre entier écrit en binaire sur plusieurs Go alors son image représente un couple former par (t,a) avec t et a qui peuvent s'écrire dans un octet voir deux.
tel que n=t!+a pour retrouver notre n suffit de mettre t!+a un simple calcule pour enregistrer tout un fichier en binaire a partir de deux variable t et a.
Bon voila mon but c'est avoir un t entier assez petit qui peut s'écrire dans un octet voir deux.
Si n représente un grand nombre entier écrit en binaire sur plusieurs Go alors son image représente un couple former par (t,a) avec t et a qui peuvent s'écrire dans un octet voir deux.
tel que n=t!+a pour retrouver notre n suffit de mettre t!+a un simple calcule pour enregistrer tout un fichier en binaire a partir de deux variable t et a.
rafit jad kuldinger
Messages postés
7689
Date d'inscription
dimanche 4 avril 2010
Statut
Membre
Dernière intervention
2 février 2024
1 150
24 avril 2013 à 20:44
24 avril 2013 à 20:44
tu veux compresse un nombre de x millier d octet de taille sur un paquet de deux octet !
tu nous demande l impossible.
tu nous demande l impossible.
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
Modifié par extrazlove le 24/04/2013 à 21:06
Modifié par extrazlove le 24/04/2013 à 21:06
plutôt le représenter par deux entier t et a tel que n=t!+a
pour retrouver notre n suffit d'écrire t!+a un simple calcule.
pour retrouver notre n suffit d'écrire t!+a un simple calcule.
rafit jad kuldinger
Messages postés
7689
Date d'inscription
dimanche 4 avril 2010
Statut
Membre
Dernière intervention
2 février 2024
1 150
24 avril 2013 à 21:02
24 avril 2013 à 21:02
donc si j ai bien compris tu veux représente un grand nombre sont une forme exponentiel (si mes souvenir sont bon).
extrazlove
Messages postés
2
Date d'inscription
dimanche 21 avril 2013
Statut
Membre
Dernière intervention
3 octobre 2014
Modifié par extrazlove le 24/04/2013 à 21:32
Modifié par extrazlove le 24/04/2013 à 21:32
Plutôt factoriel en utilisant des entiers pour pas avoir le problème des nombres flottant.
exemple
un nombre entier écrit dans un fichier binaire de 1Go.
je trouve un t et un a petit dans un 1ko tel qu t!+a=mon nombre entier binaire de 1Go.
exemple
un nombre entier écrit dans un fichier binaire de 1Go.
je trouve un t et un a petit dans un 1ko tel qu t!+a=mon nombre entier binaire de 1Go.
rafit jad kuldinger
Messages postés
7689
Date d'inscription
dimanche 4 avril 2010
Statut
Membre
Dernière intervention
2 février 2024
1 150
24 avril 2013 à 16:07
24 avril 2013 à 16:07
imaginons une image en noir et blanc ...
elle est donc constituer de pixel noir et blanc, en partant d principe que l image est faite d un carrée de 1000*1000 pixel.
que dans la mémoire la valeur des pixel est aligné avec un retour de ligne tous les 1000 pixel.
voila le début de l image 0 = blanc 1 = noir ..
000001111000001111110000111111000000000111
la compression va alors consisté a compte le nombre de pixel blanc et et noir ce qui donne :
5041506140619031...
sachant que chaque valeur prend 16 bit ... quel soi compresser ou non, le but de la compression réduit bien le nombre de valeur a garder mais pas la taille des octet.
dans mon exemple on passe alors de 42 paquet de 16 bit a seulement ...
16 paquet de 16 bit ... et il est la le gain de place.
mon exemple est le mode de compression le plus basique.
il en existe des bien plus complexe, par exemple pour des images la compression vectoriel, cela transforme l image en plusieurs "équation" , ansi l arc de cercle ne sera pas compresser au pixel, mais ce sera la formule de l arc de cercle qui sera utilise..
l ordi recalculera alor la forme de l arc de cercle avec la formule contenu dans le fichier, ce mode de compression est très utile pour des dessins car peu de nuance de couleur.
exemple pour un cercle : se sera la formule du cercle qui ne contiens que quelque caractère qui sera utilise.
le mp3 et le mpg sont des méthode de compression dégradante, car il réduise le nombre de valeurs a compresser, c est a dire pour le mp3 , les fréquences inaudible et pour les images, les couleurs que l on ne peu voir.
une image faite de 1 million de nuances, sera a nos yeux la même que celle a 100 000 nuances.
au passage, c est grâce a la compression direct des apn que l on peut faire des trucage photo sans retouché l image, la compression fessant le travaille de gommage du fil de pèche tenant la soucoupe volante par exemple.
elle est donc constituer de pixel noir et blanc, en partant d principe que l image est faite d un carrée de 1000*1000 pixel.
que dans la mémoire la valeur des pixel est aligné avec un retour de ligne tous les 1000 pixel.
voila le début de l image 0 = blanc 1 = noir ..
000001111000001111110000111111000000000111
la compression va alors consisté a compte le nombre de pixel blanc et et noir ce qui donne :
5041506140619031...
sachant que chaque valeur prend 16 bit ... quel soi compresser ou non, le but de la compression réduit bien le nombre de valeur a garder mais pas la taille des octet.
dans mon exemple on passe alors de 42 paquet de 16 bit a seulement ...
16 paquet de 16 bit ... et il est la le gain de place.
mon exemple est le mode de compression le plus basique.
il en existe des bien plus complexe, par exemple pour des images la compression vectoriel, cela transforme l image en plusieurs "équation" , ansi l arc de cercle ne sera pas compresser au pixel, mais ce sera la formule de l arc de cercle qui sera utilise..
l ordi recalculera alor la forme de l arc de cercle avec la formule contenu dans le fichier, ce mode de compression est très utile pour des dessins car peu de nuance de couleur.
exemple pour un cercle : se sera la formule du cercle qui ne contiens que quelque caractère qui sera utilise.
le mp3 et le mpg sont des méthode de compression dégradante, car il réduise le nombre de valeurs a compresser, c est a dire pour le mp3 , les fréquences inaudible et pour les images, les couleurs que l on ne peu voir.
une image faite de 1 million de nuances, sera a nos yeux la même que celle a 100 000 nuances.
au passage, c est grâce a la compression direct des apn que l on peut faire des trucage photo sans retouché l image, la compression fessant le travaille de gommage du fil de pèche tenant la soucoupe volante par exemple.
