Reprise du message précédent :
Et surtout attendre aussi longtemps pour si peu Tu rar un machin, t'as en général 50-75% de compression, donc 4096 réduits en 3072 en moyenne...

 
les applications sont tout autres: dans la vidéo et le son mais ça demandera une grande puissance de calcul ou des architectures adaptées.  
Les capacités de stockages sont en constante augmentation mais ça n'enlevera en rien que des limites seront atteintes.  Va mettre un DD de 18000000 Go dans ton autoradio, ton dvd de salon ou autres.  Va mettre 6 plombes pour un divx sans garantie de qualité.  L'essentiel c'est encore et toujours le temps de traitement. C'est le compromis difficile entre temps de chargement et la quantité.
 
Et aujourd'hui pourquoi des archives zip,rar, uharc ?  Ce ne sont pas simplement des archiveurs  

 
 
C'est le vrai probleme que tu cites: le temps d'attente. Et celui que je sonde depuis le 1er post mais j'ai l'impression d'avoir un public plus curieux que lecteur de la 1ere question.  
 
Pour des raisons commerciales évidentes comme évoquées precedemment, je ne vais pas donné la recette. Le temps de calcul se situe dans les opérations binaires.  
 
un ex de temps de compression ?  je code en php (moins chiant que le C): 1 Go en 3h.... et encore, tout dépend de la qualité de mon code.  
 
 
 

 
ça aussi c'est un probleme: il n'existe pas de brevetage sur les concepts intellectuels mais si un industriel en fait sa marque, tout comme GIF est devenu propriétaire, en quoi une exploitation hard n'est elle pas lucrative, licenciable et redevable par les autres fabricants ?  Dans le domaine du logiciel, c'est devenu un peu n'importe quoi.
 
 

 
c'est de l'histoire ancienne depuis peu ça.

TU M'ETONNE QUE CA PRENNE DES PLOMBES §§§
 
Il prend le langage le plus lent de la planète pour faire de la compression  
 
 
Aller j'y crois plus. C'est le multi de qui ? Stiffler, c'est pas drôle

c'est lassant.
 
Considérons que vous soyez des clients hyper impatients et super chiants, rien ne vous contentera, à la limite vous seriez prets à fondre votre processeur tout seul dans la cuisine.  
 
LE hic, c'est le temps de calcul mais à chaque fois, c'est une tentative de savoir comment cet algo fonctionne.
 
Si à chaque fois qu'on vous sonde, vous cherchez à comprendre comment on fait du papier ......

Mais non ! Le temps de calcul vient uniquement du langage pourrave que tu utilises !!!

 
 
j'ai exposé le pourquoi du choix du langage, maintenant si effectivement on peut encore améliorer tant mieux.  
 
parcequ'il faut être une bete de programmation pour inventer un truc ?  Ca devient merdeux ici

on verra bien dans qq temps.  Ici j'abandonne mon sondage

Bon allez ça suffit, t'essayes de nous faire croire que t'arrives à faire qui est impossible à faire, c'est même mathématiquement démontré que c'est impossible, tu codes en PHP, c'est trop gros là

Et cette information-là tu la stockes aussi pour pouvoir la décompresser plus tard, j'imagine ?
 
 

 
Tu crois que lui aussi a l'aval d'un chercheur russe ?    
 
 
 
Question subsidiaire : pourquoi ce sujet dans la catégorie "Langage C" ?

C'est ce que je trouve louche... J'ai plus l'impression que son algo sert à rien, vu qu'il perd en metadata ce qu'il a gagné en "compressouillant"

Non.  Google "entropie shannon" et reviens nous voir quand tu as tout lu.
 

Tu devrais abandonner ton idée hautement ridicule, te couler les deux pieds dans du béton et te jeter dans le fleuve le plus proche.
Pour info, c'est quoi ton niveau en maths ? Parce que j'ai déjà connu un mec qui prétendait compresser à l'infini ou presque. Il y croyait à mort, il pensait même "révolutionner la théorie du chaos" (j'invente pas). Aujourd'hui il fait des jeux pour téléphones mobiles en Java.
 
T'es pas le premier à penser avoir eu l'idée de génie, et t'es pas le premier à avoir l'air ridicule non plus. Tu t'en remettras.

T'es vraiment bouché comme gars
 
Je me fous de "la méthode" comme je me fous des plans d'une machine à mouvement perpétuel, parce que ton truc c'est du vent

Siluro ne sait pas de quoi il parle, et toi tu es en plein délire

Personne ne va s'y atteller, parce que c'est un grand n'importe quoi.
 
L'informatique et l'algorithmie ce n'est pas de la magie noire, et les règles découvertes par Shannon ne sont pas négociables, pas plus que la thermodynamique ne l'est en physique  
 
Maintenant sois gentil et va jouer ailleurs, genre sur developpez.com ou -- mieux -- sur ONCT, je suis sûr que tu t'y trouveras des potes

C'est du Mikhail a tous les niveaux: un délire à la noix sans fondements et remettant en cause toute la théorie de l'information, un refus d'écouter ou de réfléchir et une attitude bornée  

 
On atteint des sommets invaincus là, le sauveur de l'humanité, remettant en cause toute la théorie de l'information, découvreur de la compression infinie, qui code en PHP

Nan mais arrêtez
 
Ya rien de louche dans son truc, c'est juste un grand n'importe quoi de bout en bout

+1(bit) avec Machinne
 
Pour avoir déjà croisé un inventeur de compression infinie, ça fait bizarre là. Je me sens revenu 6 ans en arrière

Désolé, masklinn, mais tu as tort. J'ai moi-même créé un algorithme de compression très performant, qui permet d'encoder n'importe quoi sur 1337 bits (mais apparemment gingembre1 a trouvé mieux).
 
C'est pourtant pas difficile.
 
Bon, le seul souci c'est que c'est non bijectif.

C'est parce que tu n'es pas sur le bon forum, tu devrais aller sur la cat Sciences @ Discussions. Il y a là quelques experts qui accueilleront tes idées comme elles le méritent, notamment le dénommé Mikhail. C'est pas comme ici, il est ouvert et sympa, tu verras.

bonjour,
 
ce sujet n'a rien d'un fake car j'ai la certitude mathematique de pouvoir réduire 8192 cas (2^13 bits) en 8100.
L'eccueil de ce systeme est de devoir travailler sur 26x13 bits (je gagne à peine 2% sur chaque groupe de 13 bits).
 
Les avantages liés à cet algo sont évidents mais le probleme est le temps de compression. (bcp d'operations pour gagner 1 bit mais gain garanti !)
 
La question est de savoir si les consommateurs, vous, moi, seraient capable de patience ?  
 
ps: ne me demandez pas la description de celui ci, pour des raisons commerciales évidentes
 
 
 

 
 
OK lol

Il a déjà attaqué science@discu, mais bresse a locké son topack

Oh le méchant !    
Attaquer le progrès ainsi, c'est Galilée qu'on bâillonne !

gingembre >> si tu as la certitude d'obtenir le taux de compression que tu indiques, j'ai moi la certitude de multiplier la vitesse de ton algo de façon exponentielle. je te propose donc de te le recoder entièrement en assembleur, et on fait fifty-fifty. qu'en penses tu ?

MOOOOOOOOUUUUUUUUAAAAAAAAAARRRRRRRRRFFFFFFFFF
 
OK, on peut fermer le sujet.
 

je crois que j'ai compris sa technique:
 
il prends 26 mots de 18bits, les réordonnes de manière à avoir les 6bits de poids forts de croissant, perds les 6bits, émets les 12bits restant, et reconstruit la séquence à la décompression avec les cookies d'amazon.com !!
 
je suis trop fort!

 
C'est pas plus ridicule que de coder en C.

sympa ce topic
Déjà c'est impossible, c'est un principe fondamental de la théorie de l'information. On ne peut pas représenter TOUTE suite de n bits en moins de n bits. Mais on peut représenter CERTAINES suites avec moins de n bits. Attention car si on utilise un dictionnaire, il faut le prendre en compte. Passer de 1024 bits à 1022 bits avec un dictionnaire de 16 bits, ce n'est pas de la compression car 1022 + 16 > 1024.
 
gingembre1 : soit t'es un blagueur, soit t'es sincère mais tu te trompes. C'est tu es dans le dernier cas voici une démonstation de ton erreur autre que le principe de récursivité qui ramène tout à 1 bit :
 
- tu peux compresser toute suite de 4096 bits en 4016. Et ensuite les décompresser pour repasser à 4096. C'est ce que tu dis.
 
- Tu as donc un algo bijectif : chaque groupe de 4096 peut se transformer en groupe de 4016 et vice-versa.
 
- Or il y a 2^4096 groupes de 4096 bits et seulement 2^4016 de 4016 bits. Ton domaine 'arrivée étant plus petit que ton domaine de départ, il n'y a pas bijectivité.
 
- Donc tu as tord, CQFD

 
Ce sont les pires.

les + tétus surtout...
 
je rajoute au passage la réplique à ta future remarque : "j'ai pas dit que mon algo était bijectif !"
Et bien si ton algo n'est pas bijectif, ce n'est pas un algo de compression mais un algo de transformation, ce qui n'a rien à voir.

ça dépends si il veut t'opérer les amygdales ou pas.

tiens c'est pas mal ça, moi j'avais croisé l'inventeur du langage à terminaison deterministe. Le principe : pas de boucle, pas de goto, pas de récursivité.
On a beau eu lui dire que ce langage était inexploitable il a jamais rien voulu comprendre...

Shanon doit se retourner dans sa tombe

Je ne pense pas, m'est avis qu'il pique une crise de fou-rire là tout de suite

je comprends que certains soient attirés par le chant des sirènes de la compression absolue. Il y a des théories presque vraies qui soutiennent cette thèse, comme :
 
- On peut compresser de n bits à n-1 bits tant que l'antropie n'est pas maximale.
- On finit par être bloqué à m bits avec m plus petit que n. Or on sait que ce nombre de m bits est à antropie maxiamle. Et il y a peu de nombres de m bits à antropie maximale. Du moins il y en a moins de 2^m. On peut donc indexer ces nombres sur moins de m bits, disons k bits avec k < m, avec des index de 0 à 2^k-1. La plupart des nombres entre 0 à 2^k-1 on une antropie faible. On peut alors recompresser cet index récursivement pour atteindre encore moins de bits, et ainsi de suite...
 
ça à l'air juste, non ?
Et bien c'est faux :
- un nombre non compressible n'a pas forcément une antropie maximale. Entropie élevée, certes, mais pas toujours maxiamle.
- Il faut à chaque étape connaître k, or cette valeur k doit être stockée et prend de la place... au moins autant de place que gagnée à l'étape précédente.
 
alors non, non et non, on ne peut pas prendre en défaut la théorie de l'information, désolé
 
edit : orthographe

Ca me rappelle lzip

même en mettant le DVD dans un micro-onde pour rendre sa capacité de stockage illimitée ? (en plus c'est joli)

 
         trop fort ton lien !

surtout en mettant un DVD dans un micro-onde