bonjour,
 
ce sujet n'a rien d'un fake car j'ai la certitude mathematique de pouvoir réduire 4096 cas (2^12 bits) en 4016.
L'eccueil de ce systeme est de devoir travailler sur 26x12 bits (je gagne à peine 2% sur chaque groupe de 12 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

Tu peux nous donner la description ?
 
Parce que je pige pas trop 4096 -> 4016 ? C'est pas un super taux de compression...

 
 
c'est pas un super taux mais c'est une certitude.  
 
la plupart des compresseurs sont stastistiques et donc taux variables, du moins pour la compression non destructive.
 
C'est bien le probleme de cet algo, il fonctionne mais il est lent à moins de passer par des procédés ultra optimisés et des processeurs puissants.

En tous cas, y'en a qui sont pas d'accord avec toi, cf. wikipedia (Lossless data compression must always make some files longer)

 
wikipedia ne conjecture pas, ils font des constats sur l'existant.
 
là, j'ai la confirmation que ça fonctionne. J'imagine que beaucoup diront que c'est du pipot mais c'est leur probleme. La question que je pose est en fait commerciale, j'ai aussi posté un sujet sur windows,logiciels & réseaux.
2% c'est effectivement dérisoire pour un groupe de 12 bits mais optimisé ça peut le faire.  
 
gagner 1 bit sur un "morceau" défini, c'est garantir une compression définie et donc infinie. Le GROS probleme c'est le temps.  Je peux gagner pas mal en stockant sur 12 (ou 24 bits) des résultats prédifinis mais ça ne m'exonere pas des operations binaires et c'est là que ça coince.  Faire une multiplication ou une division sur des chaines aussi longues engendre des temps de traitements à priori redhibitoires.
 
Le tout est de savoir si le consommateur s'en accomoderait (le procédé est arithmétique, facilement implementable en hard, et les conséquences d'un tel algo sont énormes: platine dvd pouvant stocker à l'infini, exportable sur clé usb, idem pour tout ce qui concerne le son, allegement du réseau et tutti quanti)  

• Il y a déjà un brevet sur la capacité à compresser n'importe quel fichier en réduisant sa taille d'un bit sans pertes d'informations, et en pouvant appliquer cette compression récursivement
• Appliquer récursivement ce genre de fantaisie signifie que n'importe quelle information peut-être compressée en un unique "0" ou un unique "1", puis décompressée sans perte d'information. Peux tu me dire comment tu décompresses un "0" ou un "1", comment tu décides à quelles données décompressées il correspond? Je serais curieux de le savoir
• Tu devrais arrêter la drogue

TRIPLE post de gingembre :
http://forum.hardware.fr/hardwaref [...] 8260-1.htm
http://forum.hardware.fr/hardwaref [...] 4553-1.htm

 
1- montre moi ce brevet que j'evite de perdre mon temps
2- ta demontrastion anéantie la 1ere
3- pere de famille, je ne permettrais pas
 
je peux réduire 4096 en 4016, et aucunement je ne dévoilerais la méthode.  Tu as le droit de ne pas me croire mais pas le droit de nier en bloc sur des concepts que tu connais et déjà limités ( comme l'algo LZW )
 
A te lire, Hardware n'est le meilleur terreau pour developper des nouveautés  

c'est d'une violence ici.  
 
le plus impressionnant est de lire la certitude de certains ayant apparement fait le tour de la science.

US patents 5533051 et 5448364

Tu devrais apprendre à utiliser correctement le français, mon premier point était une déclaration pas une démonstration, et le dépot d'un brevet n'a jamais prouvé la validité ou la correction d'un processus breveté (l'INPI donne encore des brevets pour des machines à mouvement perpétuel)

Je n'ai en rien besoin de ta permission pour traiter ce genre d'âneries comme des âneries

Je dois avouer n'en avoir cure

Je ne nie pas, il n'y a rien à nier quand quelque chose est strictement impossible (mouvement perpétuel, énergie du vide, compression lossless infinie)

HWFR n'est effectivement pas un lieu ou répandre ce genre de salades, prière d'emmener tes stupidités ailleurs.

pour répondre à "La question est de savoir si les consommateurs, vous, moi, seraient capable de patience ?", avec le matériel hardware que nous, grand public, nous pouvons avoir, non. Le temps d'attente serait trop long et on a "autre chose à foutre" (excuse moi de dire ça)
 
Sinon, dans l'idée, je me dis que ça pourrait se faire (réduire beaucoup plus). Mais réduire n'importe quelle donnée en moins de bits possibles, il va y avoir un problème en fin de compression : on va atteindre un seul bit ? et comment fera-t-on pour décompresser ? Je ne vois pas très bien là

On ne peut pas, et ce paradoxe suffit à démontrer que la "compression infinie" est une douce fantaisie.

Ok, mon doute est dissipé.

 
 
tu n'as pas compris le principe mais tu n'en connaitras pas non plus la substance. Pour toi c'est tout réduire à 0 ou 1. Débilissime.  
 
Il s'agit d'une méthode pour "gratter" quelque cas. Suffisamment pour gagner une certitude sur nombre défini de bits. Il faut aussi me comprendre que je n'ai pas envie de dévoiler cette derniere.  Evidemment que vous êtes dubitatifs, c'est légitime. Sauf que cette méthode existe mais a la lacune d'être lente. C'est tout le sujet de ma question: jusqu'où votre patience peut aller ?  
 

C'est pourtant exactement ce que tu proposes: un gain fixe sur n'importe quelle donnée sans perte d'informations (voir la quote juste en dessous), donc une réduction ultime à un bit unique d'information par application récursive du protocole sur son propre résultat, ce qui est une impossibilité mathématique.

Aucune importance, essaie bien de comprendre que tout le monde se fout de la méthode, parce qu'elle est erronée.

Jusqu'à la fin de l'univers, il faudra bien ça.
 
 
PS: gingembre, je te conseille de te renseigner sur le concept de 'information entropy', ça pourrait t'être utile.

Un doute ma bits à l'infinie.

 
 
non, on atteint pas 1 bit mais 26x12 = 312.
 
ne te laisse pas induire en erreur pas un réfractaire à ses convictions.

Je pencherais pour une autre question : pourquoi compresser autant ?

 
j'ai développé cette question qu'il me semblait évidente : platine de salon pouvant stocker à l'infini, export sur clé usb, idem pour le son, les auto radios, l'allegement du réseau, sans compter les applications informatiques telles que l'archivage.  
 
je suis juste confronté à un probleme humain: l'attente.  Et c'est un facteur commercial important.  

Moi le point qui me le rend le plus dubitatif c'est : il existerait une méthode arithmétique et simple de compression que des labos et des millions de dollars aurait manqué pendant des années, et qu'un type seul trouverait seulement maintenant ?  
J'ai un peu de mal à croire que ce genre de "miracles" puisse encore exister de nos jours (mais si c'est le cas, tant mieux pour toi gigembre1 ). En tout cas j'aurais plutôt tendance à dire qu'on a abandonné ce genre de voies à cause des inconvénients que tu soulèves toi-même...

Quelle importance?
 
Admettons qu'on puisse compresser n'importe quelle source à 312 bits.  
 
312 bits correspondent à un maximum de 2**312 sources différentes possible et pas une de plus, or tu déclares pouvoir compresser n'importe quelle donnée jusqu'à 312 bits.  
 
Considérons un instant que tu ais la capacité hypothétique de compresser sans perte d'information n'importe quelle source jusqu'à 312 bits.
 
Celà nous limite à un maximum total de 10**93 sources différentes, donc tu vas nécessairement avoir des collisions dans ton domaine (parce que le nombre de sources potentielles est infini), donc deux sources amenant à strictement le même fichier compressé, amenant aux mêmes 312 octets.
 
Comment vas tu faire pour les décompresser, pour différencier l'un de l'autre?
 
Tu ne peux pas.
 
Donc ta compression n'est pas sans perte.
 
Je te re-conseille de te renseigner sur le concept d'entropie appliquée à la théorie de l'information, et aux écrits de Shannon.

Le seul inconvénient est que la chose est tout simplement impossible, je le répète c'est du niveau du mouvement perpétuel, et les deux idioties sont défaites par la même "loi" universelle: l'entropie

 
 
ta derniere remarque est celle qui justement m'interpelle le plus: pourquoi moi j'aurai trouvé alors que c'est pas sorcier ? surement à cause de ces problemes de temps.  
Et là, je sais plus quoi faire parcequ'il m'étonnerait que j'obtienne des infos qui à mon avis vont restées bien gentiment dans les cartons de multinationales jusqu'au jour où ......

 
Pas sûr, feuillette deja les bouquins qui font référence dans le domaine de l'algo (et de la compression en particulier), et tu trouveras peut-être des infos.
 
Et puis bon, même si ce truc là ne marche pas, ça prouve que tu as des idées, tu pourras peut-être faire des trucs intéressants plus tard, genre de la recherche (à moins que tu ne sois un vieux retraité ?   ).
 

 
inutile d'insister. Tu n'obtiendras pas la méthode.  
Tu peux me traiter de tous les adjectifs que tu veux, que m'importe, je ne faisais que sonder les attentes en matiere commerciale.  
J'ai déjà eu 2 réponses: l'un qui me dit qu'il est pret à plusieurs jours et un autre qui me répond qu'il n'attendra pas.  
 
C'est tout ce que je demande. Pour le reste, que m'importe  et les réponses de Siluro sont pertinentes: il doit exister cet algo mais il faut de la puissance pour l'exploiter

Non ce n'est pas d'une violence. Peut-être que Masklinn est un peu sec dans ses propos, mais il a entièrement raison. N'importe quel article sur la compression t'explique, de manière mathématique, que l'on ne peut pas *tout* compresser. Il y a forcément une suite de bits qui ne pourra pas l'être... C'est pourtant logique

 
 
il y a une maniere d'agencer les données et d'obtenir un résultat par déduction. Je n'en dirais pas plus.  
 
Et uniquement en exploitant un seul cas de figure, d'où les 80 obtenus sur les 4096 et qqchose me dit que c'est encore perfectionnable. Pragmatisme et theorique, un bien long débat.  
 
J'imagine que certains salivent de connaitre cette "anomalie" et pourtant......  
 
ça fonctionne sur 18 bits (6 de masques avec propriétés particulières), reste 12 bits pour stocker les solutions restantes.  En réalité il faut 18x26 bits de lecture, et 12x26 d'encodage. Et dans tout ça, je "gratte" 2% par groupe de 12 bits "travaillables".
 
En ayant conscience de tout ça, on peut me traiter de mytho et autres, la seule question en suspens, c'est le temps de traitement.  Certains septiques vont déjà s'y atteler.  
 
 
 

J'ai une meilleure idée Fait nous un soft d'exemple, file-le nous, et on verra bien

 
contre un paquet de clops, le marché me semble équitable  

Remarque, les fabricants ont bien réussi à compresser un paquet de 21 à 20 clopes en gardant le même prix

Mais pourquoi ne coderai tu pas un petit prog minimaliste (avec disons une limite de la taille d'entrée) qui montrerai au monde entier que tu ne fait pas que du e-mytho ?

 
pour la simple raison que tout le monde connaitrait le principe de fonctionnement.  
 
Ca ne semble pas le bon forum pour les principes de respect, d'ouverture, et d'entre-aide.  

 
Ca veut dire quoi ça ? que ton algo est exponentiel ? que pour une taille d'entrée t'atteint vite les 10 heurs de calculs ?
 
C'est quoi la complexité de ton algo au fait ?

Bien-sûr que si. Il y a ici beaucoup de développeurs professionnels. Sauf qu'on a tous appris qu'on ne peut pas avoir un taux fixe de compression, t'es le premier être humain sur terre à nous parler du contraire. C'est normal que l'on est un petit peu sceptique

tout le monde s'acharne à contester l'existence d'un algo capable de réduire indéfiniment au dépend d'un traitement a priori rédhibitoire face à la patience d'un consommateur lambda, j'attend juste des réponses simplissimes: êtes vous patient face à un gain notable et nouveau, et on cherche pas divers moyens à me tirer les vers du nez, ce qui, je le conçois, peut vous interroger.  
 
Si certains ont des supers méthodes pour des opérations binaires sur une chaine de 312 bits .....

 
la compression video/audio:  compression destructive
compression logiciel: taux plus que variables et compression basée sur la fréquence d'apparition d'un modele.
compression absolue: non destructive mais super lente.    On peut pas tout avoir.
 
Maintenant je vais stopper le débat et sonder de façon differente sur les attentes quoique vous m'ayez fourni quand meme qq elements de réponse: interessant mais un peu frustant cet algo.  
 
rdv dans qq temps pour en parler, car à part certains, j'ai pas trouvé l'accueil super agréable  

 
le temps de calcul est fixe. Tout est basé sur 312 bits réduits en 311.  

 
C'est marrant quand même, dans ton cas donner la preuve c'est forcement donner la solution et apparament pour toi le seul problème c'est le temps d'attente.
 
Tu sais, moi en tant que futur utilisateur je ne me vois pas attendre une semaine pour compresser un mp3.  
Surtout aujourd'hui, vu la vitesse à laquelle la taille de nos DD augmente.  
 
Si c'est ca que tu voulais entendre ...
 
Par contre si c'est le temps d'attente d'arrivé des softs de ton algo, si ca arrive dans 10 ans on s'en fout ...

 
Dans les cas que tu cites (platine DVD de salon, clé USB, ...), on a plutôt besoin d'un temps d'attente minimum, alors le "plusieurs jours" j'y crois moyen...
 
Même si ton système de compression fonctionne vraiment (j'avoue en douter légèrement   ), j'ai peur que des temps de calcul trop élevés le rendent inintéressant face à l'augmentation rapide des espaces de stockage.
 
Quelqu'un t'a demandé la complexité de ton algorithme, je ne crois pas que tu y aies répondu, ça serait pourtant intéressant... Sinon, des exemples de temps de compression?
 
PS: Dans le style des réponses, on dirait presque Mikhail, sans les fautes!  

 
eh bien alors dès que tu sortira le programme commercial qui te rendra riche, tout le monde saura comment ca marche, c'est inévitable, il est possible de reverse-engineerer n'importe quel programme. Ne dis pas avoir une protection infaillible, ca n'existe pas, ou alors les producteurs de jeux vidéos/sharewares ont dû louper quelque chose

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...