Beste svaret
Hvis du med «best» mener du kompresjonsforhold, så i henhold til Stor tekstkomprimeringsbench det er CMIX. Det eneste problemet er at du trenger en datamaskin med 32 GB minne for å kjøre den. Og så vil det ta 4 dager å komprimere eller dekomprimere 1 GB tekst.
Som de fleste av de topprangerte programmene, bruker CMIX forhåndsbehandling av ordboken og kontekstblanding i PAQ-stil. Forprosessoren erstatter ord med 1 til 3-bits symboler fra en ordbok og utfører annen behandling, for eksempel å erstatte store bokstaver med et spesialsymbol og det tilsvarende små bokstaver. Det kan også analysere vanlige prefikser og suffikser.
En kontekstmodell tar en kontekst (for eksempel de siste n bitene) og gjetter en sannsynlighet p at neste bit blir 0 eller 1. Resultatet blir matet til en aritmetisk koder, som koder biten veldig nær Shannon-grensen for log2 1 / p bits. Kompresjonsforholdet avhenger derfor helt av hvor godt p er estimert. En kontekstblandingsalgoritme gir svært nøyaktige spådommer ved å kombinere spådommer fra mange uavhengige modeller. CMIX bruker flere hundre modeller, og det er derfor det krever så mye tid og minne. Grunnen til at det er så mange modeller er at det er mange forskjellige mulige sammenhenger, mange måter å konvertere en kontekst til en prediksjon, mange måter å oppdatere modellen på, og mange måter å adaptivt kombinere spådommer fra andre modeller og velge de beste ved hjelp av et hierarki av miksere. Praktiske kontekstmikser kan bruke 2 til 20 modeller, noe som ofrer noe komprimering for enkelhet og brukervennlighet.
De beste kompressorene kommer nær faktisk forståelsen av tekst. De modellerer språkets leksikale, semantiske og grammatiske struktur. For eksempel er ordboken organisert ved å gruppere relaterte ord sammen, for eksempel mor med far og mandag med tirsdag . Dette resulterer i ordbokskoder som bare skiller seg i de lave bitene. Så vil noen av kontekstmodellene slippe de lave bitene, slik at kompressoren kan forutsi Jeg så faren min på mandag etter å ha sett Jeg så moren min på tirsdag .
De tekniske detaljene kan være ganske involvert. Hvis du er interessert i å lære mer, se Datakomprimering forklart .
Svar
Forutsatt at du snakker om tapsfri komprimering (tekster kan for eksempel være komprimert med SMS-språk), er det velkjent at du ikke kan komprimere tapsfri «noen» binærfil. Med andre ord, noen filer vil øke størrelsen. Dette skyldes koderhodefiler og grunnleggende matematikk med umulige sammenhenger mellom [0, …, N] og [0, …, N-1] eller Dirichlet pigeon-hole-prinsippet (Schubfachprinzip). Se http://en.wikipedia.org/wiki/Pigeonhole\_principle
Som sagt før, refererer «best» generelt til noe gjennomsnittlig kompresjonsforhold @ Sam-Jp. Tegnsettet med tekster (f.eks. Ascii 7 eller 8 biter betyr noe) og deres type er også viktig. «Best komprimering» på rene menneskeskrevne tekstfiler oppfører seg annerledes på skriverens postscript, rtf, doc eller til og med pdf-filer som inneholder tekst, siden noen formater allerede innkapsler komprimering. Følgelig avhenger «best» i kompresjonsforhold av databaseinnholdet, homogeniteten og typologien til tekstfiler, som sett engelsk tekstkomprimering gitt i @ Igor-Carron-lenke: http://www.maximumcompression.com/data/text.php
Speed @ Jonathan-Hseu er også ganske viktig. Avhengig av applikasjonen din (fra arkivering til databaseinteraksjoner @ Daniel-Lemire), fokuserer man enten på komprimering eller dekompresjon (vanligvis komprimere en gang, dekomprimere mange) hastighet, eller begge deler.
Men andre funksjoner kan vurderes som vel, spesielt med fremveksten av enorme datasett og mangfoldige anskaffelsessystemer: – tilfeldig tilgangsytelse eller søkefunksjon i komprimerte filer – feilresistens (motstand mot ødelagte biter) – online-evne, dvs. å kunne komprimere datastrømmen effektivt som den kommer – komprimering av tekster strukturert ikke bare i rasterrekkefølge, men i trær, grafer – lav kompleksitet eller energisk effektivitet til koderen, eller dekoderen, eller begge deler – mulig parallellisering – muligheten for distribuert koding (komprimeringsarbeid delt på forskjellige noder i et nettverk)
Etter hvert, selv for tekst, kan man tenke ut av den tapsfrie boksen. Og vi går tilbake til SMS sitert tidligere, hvor mening er viktig, men kanskje ikke riktig stavemåte, se f.eks.Kaufman & Klein, semi-lossless komprimering http://www.computer.org/portal/web/csdl/doi/10.1109/DCC.2004.1281520
Som vanligvis løser spørsmålet om «best» i å foredle spørsmålet om det faktiske formålet, ved å definere ytterligere målinger av kvalitet og passende vekting av disse beregningene for å definere «ditt» beste @ Alex-Kamil. Temaene i følgende kilder er inspirerende:
* IEEE Transactions on Information Theory http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=18 * IRE Transactions on Information Theory http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=4547527 * Datakompresjonskonferansesider.cs.brandeis.edu/~dcc/
Endelig, siden jeg ikke er spesialist, men amatør innen tapsfri komprimering, har jeg nylig blitt overrasket over ytelsen (i kompresjonsforhold) til Deplump (http://www.deplump.com/index.html ) eller Franck Woods nettside http://www.stat.columbia.edu/~fwood/