je suis hors charte mais la compression c'est de la
representation de donnees donc a la louche du cryptage
donc apres ce grand ecart
je voudrais savoir si vous avez deja entendu
parler d'une methode de compression
similaire les matheux d'a cote me font la tete
ils ne veulent meme pas me dire que cela ne fct pas :-)
donc l'idee de base prendre un fichier deja compresse
ou
remplacer toutes les sequences de fichiers a compresser
en hex
00 00 00 00 00 00 00 00 ->8 00
en gros
000 ...000 ->nb 0
ensuite
l'on concatenne au hasard 8 octets
l'on calcule la racine carree entiere
l'on concatenne les 8 suivants calcul
etc
mx=bx^2+r
recherche de la plus petite racine carree
bmini avec bmini entier bien sur
mx-bmini^2
et l'on ecrit r et bmini bien sur
mais bon c'est tellement trivial que cela doit deja exister
il suffisait simplement de remarquer que l'on ne pouvait pas avoir de 0
ecrit avec n octet dans un fichier compresse ou de s'arranger pour que cela
soit le cas
Le 20-12-2004, à propos de compression, remy écrivait dans fr.comp.os.linux.debats :
bonjour
je suis hors charte mais la compression c'est de la representation de donnees donc a la louche du cryptage
donc apres ce grand ecart
je voudrais savoir si vous avez deja entendu parler d'une methode de compression similaire les matheux d'a cote me font la tete
En tant que bipède faisant entre autre de la théorie de l'information, je fais aussi la tête... ;-)
Il y a un truc de biaisé dès le début (googliser sur entropie de l'information et/ou côté nécessairement aléatoire de l'information transmise).
ils ne veulent meme pas me dire que cela ne fct pas :-)
donc l'idee de base prendre un fichier deja compresse ou remplacer toutes les sequences de fichiers a compresser en hex 00 00 00 00 00 00 00 00 ->8 00 en gros 000 ...000 ->nb 0
ensuite l'on concatenne au hasard 8 octets l'on calcule la racine carree entiere l'on concatenne les 8 suivants calcul etc mx=bx^2+r recherche de la plus petite racine carree bmini avec bmini entier bien sur
mx-bmini^2 et l'on ecrit r et bmini bien sur
mais bon c'est tellement trivial que cela doit deja exister il suffisait simplement de remarquer que l'on ne pouvait pas avoir de 0 ecrit avec n octet dans un fichier compresse ou de s'arranger pour que cela soit le cas
merci remy
JKB
Le 20-12-2004, à propos de
compression,
remy écrivait dans fr.comp.os.linux.debats :
bonjour
je suis hors charte mais la compression c'est de la
representation de donnees donc a la louche du cryptage
donc apres ce grand ecart
je voudrais savoir si vous avez deja entendu
parler d'une methode de compression
similaire les matheux d'a cote me font la tete
En tant que bipède faisant entre autre de la théorie de l'information,
je fais aussi la tête... ;-)
Il y a un truc de biaisé dès le début (googliser sur entropie de
l'information et/ou côté nécessairement aléatoire de l'information
transmise).
ils ne veulent meme pas me dire que cela ne fct pas :-)
donc l'idee de base prendre un fichier deja compresse
ou
remplacer toutes les sequences de fichiers a compresser
en hex
00 00 00 00 00 00 00 00 ->8 00
en gros
000 ...000 ->nb 0
ensuite
l'on concatenne au hasard 8 octets
l'on calcule la racine carree entiere
l'on concatenne les 8 suivants calcul
etc
mx=bx^2+r
recherche de la plus petite racine carree
bmini avec bmini entier bien sur
mx-bmini^2
et l'on ecrit r et bmini bien sur
mais bon c'est tellement trivial que cela doit deja exister
il suffisait simplement de remarquer que l'on ne pouvait pas avoir de 0
ecrit avec n octet dans un fichier compresse ou de s'arranger pour que cela
soit le cas
Le 20-12-2004, à propos de compression, remy écrivait dans fr.comp.os.linux.debats :
bonjour
je suis hors charte mais la compression c'est de la representation de donnees donc a la louche du cryptage
donc apres ce grand ecart
je voudrais savoir si vous avez deja entendu parler d'une methode de compression similaire les matheux d'a cote me font la tete
En tant que bipède faisant entre autre de la théorie de l'information, je fais aussi la tête... ;-)
Il y a un truc de biaisé dès le début (googliser sur entropie de l'information et/ou côté nécessairement aléatoire de l'information transmise).
ils ne veulent meme pas me dire que cela ne fct pas :-)
donc l'idee de base prendre un fichier deja compresse ou remplacer toutes les sequences de fichiers a compresser en hex 00 00 00 00 00 00 00 00 ->8 00 en gros 000 ...000 ->nb 0
ensuite l'on concatenne au hasard 8 octets l'on calcule la racine carree entiere l'on concatenne les 8 suivants calcul etc mx=bx^2+r recherche de la plus petite racine carree bmini avec bmini entier bien sur
mx-bmini^2 et l'on ecrit r et bmini bien sur
mais bon c'est tellement trivial que cela doit deja exister il suffisait simplement de remarquer que l'on ne pouvait pas avoir de 0 ecrit avec n octet dans un fichier compresse ou de s'arranger pour que cela soit le cas
merci remy
JKB
remy
"JKB" a écrit dans le message de news:
Le 20-12-2004, à propos de compression, remy écrivait dans fr.comp.os.linux.debats :
bonjour
je suis hors charte mais la compression c'est de la representation de donnees donc a la louche du cryptage
donc apres ce grand ecart
je voudrais savoir si vous avez deja entendu parler d'une methode de compression similaire les matheux d'a cote me font la tete
En tant que bipède faisant entre autre de la théorie de l'information, je fais aussi la tête... ;-)
Il y a un truc de biaisé dès le début (googliser sur entropie de l'information et/ou côté nécessairement aléatoire de l'information transmise).
tu me dis si je comprends bien
qu'a l'arrivee entre l'ecriture de bmin et le gain de place cree par mx-bmin^2 cela ne vaut pas le coup
ou que qt x de mx ->+inf bmin ->0 meme si je remplace 00000 par 5 0 c'est ca ?
ils ne veulent meme pas me dire que cela ne fct pas :-)
donc l'idee de base prendre un fichier deja compresse ou remplacer toutes les sequences de fichiers a compresser en hex 00 00 00 00 00 00 00 00 ->8 00 en gros 000 ...000 ->nb 0
ensuite l'on concatenne au hasard 8 octets l'on calcule la racine carree entiere l'on concatenne les 8 suivants calcul etc mx=bx^2+r recherche de la plus petite racine carree bmini avec bmini entier bien sur
mx-bmini^2 et l'on ecrit r et bmini bien sur
mais bon c'est tellement trivial que cela doit deja exister il suffisait simplement de remarquer que l'on ne pouvait pas avoir de 0 ecrit avec n octet dans un fichier compresse ou de s'arranger pour que cela
soit le cas
merci remy
JKB
"JKB" <knatschke@chezmoi.com> a écrit dans le message de news:
slrncsdpue.5gb.knatschke@rayleigh.systella.fr...
Le 20-12-2004, à propos de
compression,
remy écrivait dans fr.comp.os.linux.debats :
bonjour
je suis hors charte mais la compression c'est de la
representation de donnees donc a la louche du cryptage
donc apres ce grand ecart
je voudrais savoir si vous avez deja entendu
parler d'une methode de compression
similaire les matheux d'a cote me font la tete
En tant que bipède faisant entre autre de la théorie de l'information,
je fais aussi la tête... ;-)
Il y a un truc de biaisé dès le début (googliser sur entropie de
l'information et/ou côté nécessairement aléatoire de l'information
transmise).
tu me dis si je comprends bien
qu'a l'arrivee entre l'ecriture de bmin et le gain de place
cree par mx-bmin^2 cela ne vaut pas le coup
ou que qt x de mx ->+inf bmin ->0
meme si je remplace 00000 par 5 0
c'est ca ?
ils ne veulent meme pas me dire que cela ne fct pas :-)
donc l'idee de base prendre un fichier deja compresse
ou
remplacer toutes les sequences de fichiers a compresser
en hex
00 00 00 00 00 00 00 00 ->8 00
en gros
000 ...000 ->nb 0
ensuite
l'on concatenne au hasard 8 octets
l'on calcule la racine carree entiere
l'on concatenne les 8 suivants calcul
etc
mx=bx^2+r
recherche de la plus petite racine carree
bmini avec bmini entier bien sur
mx-bmini^2
et l'on ecrit r et bmini bien sur
mais bon c'est tellement trivial que cela doit deja exister
il suffisait simplement de remarquer que l'on ne pouvait pas avoir de 0
ecrit avec n octet dans un fichier compresse ou de s'arranger pour que
cela
Le 20-12-2004, à propos de compression, remy écrivait dans fr.comp.os.linux.debats :
bonjour
je suis hors charte mais la compression c'est de la representation de donnees donc a la louche du cryptage
donc apres ce grand ecart
je voudrais savoir si vous avez deja entendu parler d'une methode de compression similaire les matheux d'a cote me font la tete
En tant que bipède faisant entre autre de la théorie de l'information, je fais aussi la tête... ;-)
Il y a un truc de biaisé dès le début (googliser sur entropie de l'information et/ou côté nécessairement aléatoire de l'information transmise).
tu me dis si je comprends bien
qu'a l'arrivee entre l'ecriture de bmin et le gain de place cree par mx-bmin^2 cela ne vaut pas le coup
ou que qt x de mx ->+inf bmin ->0 meme si je remplace 00000 par 5 0 c'est ca ?
ils ne veulent meme pas me dire que cela ne fct pas :-)
donc l'idee de base prendre un fichier deja compresse ou remplacer toutes les sequences de fichiers a compresser en hex 00 00 00 00 00 00 00 00 ->8 00 en gros 000 ...000 ->nb 0
ensuite l'on concatenne au hasard 8 octets l'on calcule la racine carree entiere l'on concatenne les 8 suivants calcul etc mx=bx^2+r recherche de la plus petite racine carree bmini avec bmini entier bien sur
mx-bmini^2 et l'on ecrit r et bmini bien sur
mais bon c'est tellement trivial que cela doit deja exister il suffisait simplement de remarquer que l'on ne pouvait pas avoir de 0 ecrit avec n octet dans un fichier compresse ou de s'arranger pour que cela
soit le cas
merci remy
JKB
Sam Hocevar
On Mon, 20 Dec 2004 16:09:06 +0100, remy wrote:
qu'a l'arrivee entre l'ecriture de bmin et le gain de place cree par mx-bmin^2 cela ne vaut pas le coup
ou que qt x de mx ->+inf bmin ->0 meme si je remplace 00000 par 5 0 c'est ca ?
Ta méthode fonctionne bien si tu as beaucoup de suites de bits identiques. D'ailleurs elle existe déjà sous divers noms, dont RLE (run length encoding). Mais elle trouve très vite ses limites dans des fichiers très simples : par exemple 1010101010 sera codé 11101110111011101110, ce qui double au moins sa taille. L'idée de la compression c'est de bien réagir lorsqu'il y a des redondances ; or ici la méthode se ramasse complètement, malgré la redondance évidente.
Sam. -- Sam Hocevar <http://sam.zoy.org/> Software should be free -- http://www.debian.org/ Media access should be free -- http://www.videolan.org/ Knowledge must be free -- http://www.wikipedia.org/
On Mon, 20 Dec 2004 16:09:06 +0100, remy wrote:
qu'a l'arrivee entre l'ecriture de bmin et le gain de place
cree par mx-bmin^2 cela ne vaut pas le coup
ou que qt x de mx ->+inf bmin ->0
meme si je remplace 00000 par 5 0
c'est ca ?
Ta méthode fonctionne bien si tu as beaucoup de suites de bits
identiques. D'ailleurs elle existe déjà sous divers noms, dont
RLE (run length encoding). Mais elle trouve très vite ses limites
dans des fichiers très simples : par exemple 1010101010 sera codé
11101110111011101110, ce qui double au moins sa taille. L'idée de la
compression c'est de bien réagir lorsqu'il y a des redondances ; or ici
la méthode se ramasse complètement, malgré la redondance évidente.
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/
qu'a l'arrivee entre l'ecriture de bmin et le gain de place cree par mx-bmin^2 cela ne vaut pas le coup
ou que qt x de mx ->+inf bmin ->0 meme si je remplace 00000 par 5 0 c'est ca ?
Ta méthode fonctionne bien si tu as beaucoup de suites de bits identiques. D'ailleurs elle existe déjà sous divers noms, dont RLE (run length encoding). Mais elle trouve très vite ses limites dans des fichiers très simples : par exemple 1010101010 sera codé 11101110111011101110, ce qui double au moins sa taille. L'idée de la compression c'est de bien réagir lorsqu'il y a des redondances ; or ici la méthode se ramasse complètement, malgré la redondance évidente.
Sam. -- Sam Hocevar <http://sam.zoy.org/> Software should be free -- http://www.debian.org/ Media access should be free -- http://www.videolan.org/ Knowledge must be free -- http://www.wikipedia.org/
Galkine Guy
Le Mon, 20 Dec 2004 15:53:35 +0100, remy a écrit :
bonjour
je suis hors charte mais la compression c'est de la representation de donnees donc a la louche du cryptage
donc apres ce grand ecart
je voudrais savoir si vous avez deja entendu parler d'une methode de compression similaire les matheux d'a cote me font la tete ils ne veulent meme pas me dire que cela ne fct pas :-)
donc l'idee de base prendre un fichier deja compresse ou remplacer toutes les sequences de fichiers a compresser en hex 00 00 00 00 00 00 00 00 ->8 00 en gros 000 ...000 ->nb 0 des truc commce ça ?
http://tcharles.developpez.com/Huffman/
Le Mon, 20 Dec 2004 15:53:35 +0100, remy a écrit :
bonjour
je suis hors charte mais la compression c'est de la representation de
donnees donc a la louche du cryptage
donc apres ce grand ecart
je voudrais savoir si vous avez deja entendu parler d'une methode de
compression
similaire les matheux d'a cote me font la tete ils ne veulent meme pas me
dire que cela ne fct pas :-)
donc l'idee de base prendre un fichier deja compresse ou
remplacer toutes les sequences de fichiers a compresser en hex
00 00 00 00 00 00 00 00 ->8 00
en gros
000 ...000 ->nb 0
des truc commce ça ?
Le Mon, 20 Dec 2004 15:53:35 +0100, remy a écrit :
bonjour
je suis hors charte mais la compression c'est de la representation de donnees donc a la louche du cryptage
donc apres ce grand ecart
je voudrais savoir si vous avez deja entendu parler d'une methode de compression similaire les matheux d'a cote me font la tete ils ne veulent meme pas me dire que cela ne fct pas :-)
donc l'idee de base prendre un fichier deja compresse ou remplacer toutes les sequences de fichiers a compresser en hex 00 00 00 00 00 00 00 00 ->8 00 en gros 000 ...000 ->nb 0 des truc commce ça ?
http://tcharles.developpez.com/Huffman/
Thierry Boudet
On 2004-12-20, remy wrote:
je suis hors charte mais la compression c'est de la representation de donnees donc a la louche du cryptage
<luc2>
Ce qui est cryptique est FORCEMENT non-convivial. </luc2>
-- _/°< coin
On 2004-12-20, remy <remy@fctpas.fr> wrote:
je suis hors charte mais la compression c'est de la
representation de donnees donc a la louche du cryptage
<luc2>
Ce qui est cryptique est FORCEMENT non-convivial.
</luc2>
On comprend mieux pourquoi tu t'es fait jetter... -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
On comprend mieux pourquoi tu t'es fait jetter...
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
On comprend mieux pourquoi tu t'es fait jetter... -- ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc - http://faq.fcolc.eu.org/ Linux User Group sur Orléans et alentours. Tél: + 33 2 38 76 43 65 (France)
Jérémy JUST
On Mon, 20 Dec 2004 14:55:10 +0000 (UTC) JKB wrote:
entropie de l'information et/ou côté nécessairement aléatoire de l'information transmise).
À ce propos, je viens de compresser ma partition de news, et vu le taux record atteint (89% avec bzip2), je me dis qu'il ne doit pas s'échanger beaucoup d'information sur Usenet...
-- Jérémy JUST
On Mon, 20 Dec 2004 14:55:10 +0000 (UTC)
JKB <knatschke@chezmoi.com> wrote:
entropie de l'information et/ou côté nécessairement aléatoire de
l'information transmise).
À ce propos, je viens de compresser ma partition de news, et vu le
taux record atteint (89% avec bzip2), je me dis qu'il ne doit pas
s'échanger beaucoup d'information sur Usenet...
On Mon, 20 Dec 2004 14:55:10 +0000 (UTC) JKB wrote:
entropie de l'information et/ou côté nécessairement aléatoire de l'information transmise).
À ce propos, je viens de compresser ma partition de news, et vu le taux record atteint (89% avec bzip2), je me dis qu'il ne doit pas s'échanger beaucoup d'information sur Usenet...
-- Jérémy JUST
JKB
Le 23-12-2004, à propos de Re: compression, Jérémy JUST écrivait dans fr.comp.os.linux.debats :
On Mon, 20 Dec 2004 14:55:10 +0000 (UTC) JKB wrote:
entropie de l'information et/ou côté nécessairement aléatoire de l'information transmise).
À ce propos, je viens de compresser ma partition de news, et vu le taux record atteint (89% avec bzip2), je me dis qu'il ne doit pas s'échanger beaucoup d'information sur Usenet...
C'est une façon de voir les choses ;-) Usenet travaille en ASCII, donc avec une répartition des caractères pas du tout aléatoire (en gros 64 caractères sur 256 et une distribution non uniforme, d'où des taux de compression _hénaurmes_ et au final un fichier dont la probabilité d'occurence de chaque motif est uniforme sur l'ensemble).
JKB
Le 23-12-2004, à propos de
Re: compression,
Jérémy JUST écrivait dans fr.comp.os.linux.debats :
On Mon, 20 Dec 2004 14:55:10 +0000 (UTC)
JKB <knatschke@chezmoi.com> wrote:
entropie de l'information et/ou côté nécessairement aléatoire de
l'information transmise).
À ce propos, je viens de compresser ma partition de news, et vu le
taux record atteint (89% avec bzip2), je me dis qu'il ne doit pas
s'échanger beaucoup d'information sur Usenet...
C'est une façon de voir les choses ;-) Usenet travaille en ASCII,
donc avec une répartition des caractères pas du tout aléatoire (en
gros 64 caractères sur 256 et une distribution non uniforme, d'où
des taux de compression _hénaurmes_ et au final un fichier dont la
probabilité d'occurence de chaque motif est uniforme sur
l'ensemble).
Le 23-12-2004, à propos de Re: compression, Jérémy JUST écrivait dans fr.comp.os.linux.debats :
On Mon, 20 Dec 2004 14:55:10 +0000 (UTC) JKB wrote:
entropie de l'information et/ou côté nécessairement aléatoire de l'information transmise).
À ce propos, je viens de compresser ma partition de news, et vu le taux record atteint (89% avec bzip2), je me dis qu'il ne doit pas s'échanger beaucoup d'information sur Usenet...
C'est une façon de voir les choses ;-) Usenet travaille en ASCII, donc avec une répartition des caractères pas du tout aléatoire (en gros 64 caractères sur 256 et une distribution non uniforme, d'où des taux de compression _hénaurmes_ et au final un fichier dont la probabilité d'occurence de chaque motif est uniforme sur l'ensemble).
