Ilustruj na nekim primerima.

Očigledno ne razumeš dobro engleski:



Dakle, možeš da koristiš SAMO SADRŽAJ komprimovanog fajla, a ne da koristiš ime, ekstenziju ili bilo koji sadržaj koji nije deo sadržaja takvog fajla.



Drugi deo istog izazova je:



Ovih 415,241 bajtova je nekakav slučajan broj, ako imaš algoritam. Poenta je da uz pomoć tog algoritma možeš da komprimuješ i fajl koji predstavlja milion slučajnih brojeva i to 1000 takvih fajlova.

Dakle, prvi deo, napraviti algoritam koji komprimuje SVE fajlove dužine 400k (i dekomprimuje koristeći samo sadržaj fajla) a onda isti algoritam primeniti na 1000 fajlova dužine 375MB koje će postavljač teme dati algoritmu.

_{[Ovu poruku je menjao djoka_l dana 25.01.2017. u 23:35 GMT+1]}

A evo i zašto tvoj "algoritam" ne radi.

Pretpostavimo da fajl na početku ima 1-7 bitova koji se ponavljaju. Dakle, ti NE MOŽEŠ da uštediš bajt jer se fajl ujpisuje u BAJTOVIMA. Poslednji bajt ćeš morati da dopuniš nečim, recimo nulama. Kako ćeš znati koliko mesta u desno treba da šiftuješ bitove?

Primer:

Fajl počinje sa 1011 a završava se sa 00000000

Dobićeš komprimovani fajl koji počinje sa
011 a završava se isto sa 8 nula.

Koliko jedinica treba da dodaš na početak fajla? (1 do 8)

Volim matematičare zato što se sažeto a opet precizno izražavaju. ŠTA da ilustrujem na nekim primerima? Dao sam link do "izazova", prepisao ceo sadržaj challenga, svoj predlog kako bi moglo da se odradi, njegov odgovor...

Ako treba pojašnjenje za predlog veoma je jednostavno: odseci vodeće bitove bilo koje da su vrednosti 0 ili 1, a kad dekompresuješ i kad pročitaš prvi bit kompresovanog fajla onda znaš koja je vrednost (0 ili1) bitova koji su odsečeni (kontra od tog prvo pročitanog) pa samo nadopuniš do dužine fajla koju se on zeznuo da da unapred, ovo ne važi samo za dva fajla onaj sa svim nulama i onaj sa svim jedinicama jer kad bi njima odsekao vodeće bitove odsekao bi ceo sadržaj fajla, pa zato za ta dva fajla posebna ekstenzija i u sadržaju dovoljno samo po jedan bit (ako je moguće) da naznači koje je vrednosti bio sadržaj originalnog fajla i onda samo napraviš ceo originalni fajl od tih bitova pošto već znaš koje je dužine potrebno da bude. Pošto je tražio da se naprvi sistem koji bi kompresovao a zatim i dekompresovao svaki (bilo koji) fajl dužine 415,241 bajtova time je zadatak ispunjen?




Ne razumem dobro engleski ali tu piše da mogu da koristim samo taj kompresovani fajl da restore the original data, da je hteo da kaže to što ti tvrdiš morao bi da napiše use only the content of that compressed file to restore the original data?






Pa dobro, al ovo mu više važi za prvi čelindž jer tu ima smisla da ne bi neko sakrio podatke negde pa ih onda samo isporučio tvrdeći da ih je komresovao, za drugi i nema baš mnogo smisla što i on sam kaže kompresor može biti veliki koliko hoćeš jer "there is no data to hide", tu više ne možeš da profitiraš ni ako sve moguće fajlove te veličine sakriješ u kompresor pa tvrdiš da si podatke kompresovao na samo jedan bit ili koliko god, jer sad moraš nekako da razlikuješ te pothranjene fajlove tj. da signaliziraš koji se zahteva da se restore a za to ti opet treba 2^N različitih uputstava, osim toga ne krijem podatke ni na kakav način koji bi se mogao nazvati krivenje podataka kao u primeru sa imenima fajlova gde preručuješ podatke iz fajla u ime a bez krompesije, koristim osobine fajl sistema to da, ali ne krijem nikakve podatke nigde, dokaz je da slobodno može da odabere skraćenice za ekstenzije kakve god želi, ako ja krijem nekakve podatke iz fajla to ne bi mogao :)

Drugi deo istog izazova je:



Ovih 415,241 bajtova je nekakav slučajan broj, ako imaš algoritam. Poenta je da uz pomoć tog algoritma možeš da komprimuješ i fajl koji predstavlja milion slučajnih brojeva i to 1000 takvih fajlova.

Dakle, prvi deo, napraviti algoritam koji komprimuje SVE fajlove dužine 400k (i dekomprimuje koristeći samo sadržaj fajla) a onda isti algoritam primeniti na 1000 fajlova dužine 375MB koje će postavljač teme dati algoritmu.

_{[Ovu poruku je menjao djoka_l dana 25.01.2017. u 23:35 GMT+1]}[/quote]

Gde nadje tih 375MB duge fajlove? Ja nisam tako razumeo, on ima jedan taj random fajl dužine 415,241 bajta (random sadržaja) i ako neko tvrdi da ima algoritam koji će da kompresuje takav fajl ali ne može po chalenge 1 da zadovolji sve uslove tj. kompresor je npr. veličine 100 MB, onda će prvo da proveri da li će da uspe da kompresuje taj jedan, a ako uspe to, onda na još 1000 drugih da proveri, ali iste te dužine 415,241 bajta, gde si našao tih 375 MB?

"Dakle, prvi deo, napraviti algoritam koji komprimuje SVE fajlove dužine 400k (i dekomprimuje koristeći samo sadržaj fajla)..." Ne samo sadržaj, nego samo fajl :) : "use only that compressed file to restore the original data"

Pa jednu? :)

E pa vidiš ovo me zanimalo, znači mora da se skrati bar za bajt da bi moglo da se računa da je skraćeno, ne može za bit?

A što se tiče primera, ponašaj se kao postavljač kontesta pa reci unapred koliko su dugački fajlovi za koje želiš sistem koji će da ih skrati, ako bi ti rekao da želiš da skratiš sve fajlove dužine npr. 20 bita, onda bi ja znao na na osnovu dužine 19 bita da fali tačno jedan bit, a na osnovu prvog bita iz "kompresovanog" fajla (nula) znao bih da nedostaje jedinica na početku, ali ako sam dobro razumeo ne može biti fajl od 20 bita već mora ili od 16 ili od 24 jer se fajl, bilo koji,upisuje u bajtovima?

Ma znam ja da nisam nikakav chalenge osvojio, niti da je to ono što je postavljač "izazova" hteo, tema je šaljive prirode, ali možemo da pričamo...da je neki ozbiljniji čelindž da li bi ono "there is no data to hide" bilo obavezujuće za njega, ne može posle da me optužuje da sam "hide data".

Direktive

i


se svode na isto značenje.

Evo zašto:

Ako se prihvati uslov druge direktiva tada se koristi samo sadržaj fajla. Naziv fajla nije sastavni deo sadržaja fajla.

Medjutim, ako je druga direktiva u kolizija sa prvom tada je fajl kompresovan. Ali ekstenzija koju si naveo nije kompresovana.
Pošto se može koristiti samo kompresovan fajl zato se ne može koristiti ekstenzija koja nije kompresovana, sledi da se korišćenjem ekstenzije narušava prva direktiva.

Dakle i iz prve direktive sledi da se može kosristiti SAMO SADRŽAJ kompresovanog fajla!
Zato se može reći da je prva direktiva dovoljno jasno formulisana.

Budimo realni: ti si deo podataka kodirao u naziv fajla. A naziv fajla i sam fajl su zapravo dva fajla.
Koristio si komprimovan fajl dužine 415,241 bajta plus 3 bajta ekstenzije = 415,244 bajta što narušava uslov zadatka.


Još nešto: dužina fajla 415,241 bajtova nije slučajna, a autor čelendža je dao objašnjenje.

Šta napisa čovek, da me zablokira na tri godine da bilo šta napišem. Ko zna zašto je to dobro :) Ali moram da izjavim da ovakvu čudnu papazjaniju od obrazloženja davno nisam video, samo liči na razuman razgovor, koristi reči i rečenice, ali sadržaj ravno nula, odnosno ima jedna tačna rečenica. Skoro da bi se ceo post mogao proglasiti za random fajl, toliko malo smislenog sadržaja ima.



Ne svode se, kao kad bi rekao da se frižider i sadržaj frižidera svode na isto značenje. Osim toga drugi citat ne postoji u originalnom tekstu challeng-a, zapravo istrgao si drugi citat iz konteksta gde ja objašnjavam šta bi moralo biti napisano da bi se smatralo da mogu da koristim samo sadržaj fajla:



I onda uzmeš to što sam napisao da bi moralo da bude napisano, a nije, i svoje objašnjenje zašto misliš da je to isto kao ono prvo započinješ sa "ako prihvatimo drugu (dakle nepostojeću) direktivu" da bi dokazao da je ta druga isto što i prva???



Pa hajde da vidimo zašto je kutija sa cipelama isto što i cipele, a cipele verovatno isto što i noge, pošto je sadržaj isto što i sadržaj sa pakovanjem, te sadržaj fajla isto što i fajl, valjda dok sadržaje fajlova isporučuju u kofama ko ribu, umesto zapisane negde upotrebom fajl sistema i os-a.



Ne prihvata se uslov druge direktive, zapravo ni druga direktiva, ni "uslov" druge direktive ne postoje u challeng-u, i tada, pošto se to ne prihvata, zbog toga se ne koristi samo sadržaj fajla, nego onako kako je napisano koristi se fajl.



Ovo je ona jedna jedina istinita rečenica u celom izlaganju, i na njoj ti čestitam, ali iako stoji ovde kao zrnce istine u celom čudnom postu, i dalje je prilično beskorisna... ali slažem se, naziv fajla nije deo sadržaja fajla.



Bokte, kako dolazi do ovako čudnog razmišljanja? Fajl je komresovan kad ga propustiš kroz kompresor, pa ako tad zauzima manje mesta nego originalni, i ako postoji način da ga dekompresuješ, vratiš u prvobitno stanje i oblik. Fajl nije kompresovan ako je nekakva druga izmaštana direktiva u koliziji sa nekom prvom direktivom...



:) Eto ti sad, baš ona koju sam ja naveo? A kad Ziper od fajla tekst.txt napravi falj tekst.zip ekstenzija .zip je kompresovana, je l da?



Pa eto zaokruži ti celinu razmišljanja, i stiže na početak do "prve" (zapravo jedine) direktive, ali kako? : Pošto Ziper može da koristi samo komresovan fajl tekst a ne može da koristi ekstenziju koja nije kompresovana .zip, sledi da korišćenjem ekstenzije narušava prvu i jedinu direktivu? :)



Već je đoka_I vikao na mene, ne samo vikao nego i vrištao jer je velika slova boldovao, tako da ne moraš i ti, a ja lepo čitam, zbog mene ne moraš da pišeš velikim slovima, dakle iz prve direktive, i tvog zaokruženog izlaganja, ne sledi da se može koristiti samo sadržaj kompresovanog fajla, nego ono što piše u njoj, a to je da se može koristiti samo kompresovani fajl.



Što se mene tiče jeste, ne morate djoka i ti da izmišljate drugu, pa još i da je prihvatate.



Ne ja vala. Ako si čitao comp.compress arhive, a u vezi sa ovom tematikom, kodiranje u naziv fajla je zajebavancija, kako su neki hteli da prevare sistem, bez ikakve kompresije bi prebacili veći deo sadržaja fajla u naziv, ime, fajla pa bi tvrdili da je fajl kompresovan jer bi preostali deo sadržaja fajla bio mnogo manji nego originalni, naravno podtaci su i u nazivu zauzimali isto mesta tako da kompresije nije ni bilo realno. Ja ništa slično nisam uradio, uveo sam jednu novu ekstenziju, to da, i ajd moglo bi se reći da sam tako dobio mesta za 1 bit informacija, ali ništa nisam kodirao ni u šta, dokaz je da naziv, skraćenicu za novu ekstenziju može da bira po svom nahođenju, da sam ja tu kodirao bilo šta, ne bi mogao.



E ovo ćeš da izvineš, naziv fajla, ekstenzija i sadržaj fajla, sve to zajedno je fajl, naziv fajla i "sam fajl" nisu dva fajla. Sve bi ti bilo možda lakše ako bi ono što hoćeš da zameriš meni, pokušao da zameriš i postavljaču challeng-a, ako bi naziv fajla i fajl bili dva fajla onda ispada da kad on traži da se kompresuje fajl random.bin u stvari traži da se kompresuju dva fajla, a to ne bi bilo lepo od njega.



Nisam ja ništa koristio, ja sam predložio algoritam, po tom algoritmu ako je originalni fajl veličine 415,241 bajta, kompresovani fajl bi zauzimao manje mesta od toga, pod pretpostavkom da bi i originalna, i ekstenzija dopisana uz kompresovanu varijantu fajla zauzimale isto, uslov bi bio ispunjen.



Ako fala bogu. Ali ne mogu da se ne nasmejem, fajl slučajan, a dužina nije slučajna :)

Taman sam hteo i ovo da izdvojim kao jako čudnu rečenicu ... 415,241 bajtova je dužina fajla random.bin, tj. nije nikakav slučajan broj, i to važi i ako ja imam algoritam, i ako nemam... ali ti možda hoćeš da kažeš da se sasvim slučajno došlo baš do tog broja, do te dužine, a da challenge treba rešavati načelno, da bi algoritam trebalo da radi šta god mu se poturi, tj. bilo koja dužina random fajla ... pa ... i da, i ne ...

Postavljač nije hteo da koristi neki generator random brojeva da bi dobio random fajl, je l, je l da u teoriji, ja bih mogao da imam isti takav generator, a da tvrdim da je kompresor, pa kad on kaže kompresuj ovaj fajl, ja da zamolim generator da izgeneriše onaj isti njegov random fajl, koji je svojevremeno dobio koristeći isti takav generator .. (moja pretpostavka) sve isto važi i za naknadno mućkanje fajla, xor-ovanje, i slično, sve se to (u teoriji) da rekonstruisati i prepoznati šta je korišćeno, već i samim tim što znamo da uz pomoć bilo kakvog generatora random brojeva ne dobijamo random fajl, već pseudo random.

Zbog svega toga uzeo je fajl koji su naučnici šezdesetih radili na papiru, plaćen parama poreskih obveznika, da bi bio siguran da neko neće moći da ga rekonstruiše, zbog toga je fajl dugačak tačno 415,241 i svih preostalih 1000 različitih će biti isto toliko, jer planira samo da izmućka taj originalni... njegova odluka, šta da mu radim, ali tako je saopštio dodatnu informaciju, koliko će fajlovi na kojima proverava kompresor biti dugački, mada za algoritam koji predlažem može i duže i kraće nije bitno uopšte.

"Challenge 2 is more along the lines of troll bait, because it is patently impossible: create a system to compress and then decompress any file of size 415,241 bytes."

E sad, šta sam primetio posle samo 3 godine :) ja sam se skoncentrisao na ono "any" file, tj. trudio se da nađem algoritam koji bi skratio baš sve fajlove te dužine, i zbog toga uveo onu dodatnu ekstenziju, da bih ispoštovao taj uslov, a u stvari nisam primetio šta je napisao kako će proveriti da li kompresor radi:

"This challenge is for the contestant who is sure that he or she has figured out a way to compress the million digit file, but finds that their program takes 100 MB of space. Okay, that’s fine, we shall first see if it can compress the file. It then must be able to correctly compress and decompress a file of the same size. Let’s say, on 1,000 different files.

To keep it simple, the files will be simple permutations of the million digit file – scrambled with an encryption system, or perhaps a random number generator, or whatever. The point is, they should have all the same numeric characteristics as the original file, just organized slightly differently."

Tako da mi ne treba ona dodatna ekstenzija, jer se kao fajl za proverevanje nikad neće pojaviti fajl koji je sastavljen samo od nula, ili samo od jedinica, već jedino: "the files will be simple permutations of the million digit file – scrambled with an encryption system, or perhaps a random number generator, or whatever."

Tako da bih prepravio predlog na ovakav:

Compression

- Cut all leading bits whatever they are 0 or 1 (if in the begining there are only zeroes cut all zeroes, if they are ones cut all ones from the beggining, if there is only one bit that kind cut that one bit) and the rest of the file save as compresed file.

Decompression:

- If the first bit in compressed file is 1, then add as much zeroes to fill up to 415,241 bytes, If the very first bit in compressed file is 0 then add as much ones as you need to beggining of file to made up 415,241 bytes file.

Pošto sad više nema dodatne ekstenzije, više ne može da me optuži da sam hide data u ekstenziju, to što je unapred rekao koliki je fajl njegov problem, mada kao što rekoh ovo će da radi i za kraće, i za duže fajlove, pa može da proverava na čemu god hoće.

Uzeću mu ja tih 100e ne zvao se ja MajorFatal. Je l da šaljem ovako kao predlog, ili će neko časkom da iskodira? :)

Da li je dovoljno da broj bitova koje skidaš bude u rasponu od 1 do 7? Ako sam dobro razumeo uslov je da skineš najmanje 1 bajt.

Mislim da ovo tvoje resenje ima smisla samo ako skratis fajl za 1 do n bitova. Nema uslov da kompresija mora da bude % originalne velicine fajla kao sto to obicno traze?

Jedan bajt je uslov, tako da njegovo rešenje može da radi samo u slučaju da je prvi bajt 0 ili FF.

P.S.
Nisam detaljno proučio pravila, ali čini mi se da je besmisleno je pokušavati. Ako bi bilo moguće kompresovati bilo koji fajl, onda bi bilo moguće kompresovati već kompresovani fajl. Ponavljanjem postupka došli bi do praznog fajla iz kojeg bi inverznim postupkom trebalo da dobijemo originalni fajl.

_{[Ovu poruku je menjao BuzzLightyear dana 25.11.2020. u 13:43 GMT+1]}

E da njegovo resenje moze da se izvede zato sto je duzina poznata. Dakle skines prvo n bitova pa zapamtis u drugi fajl. Ali tako imas n fajlova ;)
U svakom slucaju mozes zapamtiti broj ponavljanja bita gde onda ide naizmenicno 0 i 1 pa to spakovati u fajl. No opet taj broj ponavljanja bita
moze proizvesti veci fajl nego sto je originalni ;)
Uzmi ovo kao pausalno, ali tako jednostavno resenje ne pije vodu...

"Ten years ago I issued a simple challenge to the compression community: reduce the size of roughly half a megabyte of random data - by as little as one byte - and be the first to actually have a legitimate claim to this accomplishment."

Što tražila to i dobila, ne radi link iz prvog posta, evo ga challenge ovde: https://marknelson.us/posts/20...ssion-challenge-turns-ten.html

Vidi stvarno, piše za 1 bajt i u challeng-u, sad moram da smišljam iz početka, šta će mi trebati, opet jedno 3 godine :)

Link iz prvog posta ne radi, evo challenge ovde: https://marknelson.us/posts/20...ssion-challenge-turns-ten.html

Ne, samo "as little as one byte" ali to sam tek sad video, tako da prethodni predlog otpada..

Na ovakve primedbe sam odgovarao već jedno 3 puta, doduše ne u okviru ove teme, ali šta je zgoreg i četvrti put: U najmanju ruku morao bi negde da zapisuješ koliko puta si ponovio postupak, 2 puta, 3 puta, 4 .. i ta cifra raste, kako cifra raste tako zauzima više prostora za zapisivanje, pa postoji ograničenje koliko puta bi mogao da ponoviš postupak tj. nikad ne bi stigao do nule, već do neke donje granice dokle je racionalno ponavljati postupak, otprilike: kompresovani fajl + zapis o broju ponavljanja postupka nije veći od prethodnog kompresovanog fajla.

Nisam razumeo ovo "Ali tako imaš n fajlova"?



To da neki pogrešan postupak može dovesti do povećanja to mi jesno, ali ne i šta si ovde predložio pa zaključio da nije dobro?

Nisam ni mislio da bi stigao do nule, samo sam hteo da pokažem da je nemoguće kompresovati bilo koji fajl. Stari Latini su imali izreku "Entropos maximus zipus nullus".

Oduvek sam želeo da konstruišem entropus maximus fajl, kako to najbrže ili najkraće da uradim? Koje osobine bi imao entropus maximus? Znam šta ćeš da kažeš, sve kodne reči istih frekvencija? :)

https://en.wikipedia.org/wiki/Diehard_tests

Ukratko, da bi testirao da li je neki niz bitova slučajan, nije dovoljan jedan test (tipa broj jedinica prema broju nula), nego baterija testova.
Može i ovako da se kaže - zamisli bilo kakav "razuman" algoritam koji na osnovu prvih k bitova (bajtova, multibajtova) prognozira koji će biti sledeći blok podataka. Ako algoritam za pogađanje ima veći broj pogodaka nego što bi se statistički očekivalo da je niz zaista slučajan, onda se smatra da niz nije slučajan.

Recimo, zamisli da treba da utvrdiš da li je fajl koji ima 100 nula na početku za kojim sledi 100 jedinica slučajan (distribucija nula i jedinica je 50-50).
Algoritam za pogađanje je sledeći: ako je prethodno učitan podatak 0, predvidi da je sledeći 0, inače predvidi da je 1.
Nakon prve učitane nule, algoritam tvrdi da je sledeći bit 0. Pogodiće 99 puta do prve jedinice. Posle prve jedinice pogodiće još 99 puta da je sledeći bit 1.
Dakle, fajl od 200 binarnih brojeva će biti ispravno pogođen 198 puta. Očekivano je da pogodi 50 puta. Dakle, statistički gledano, algoritam koji je generisao takav fajl ne daje dobru sekvencu slučajnih podataka.

Uzgred, radio sam jednu vežbu na kursu iz kriptografije.

Algoritam koji generiše slučajne 28-bitne sekvence, daje rezultat koji zavisi od seed-a i 4 parametra. Algoritam je inače modifikovani linearni kongruentni generator, samo što originalni linearni kongruenti generator radi sa dva parametra i ulaz seed (dakle, 3 parametra). Nažalost, mnoge implementacije rnd algoritma baš koriste linearni kongruentni generator.

Dat je niz slučajnih brojeva koji je izlaz iz generatora. Algoritam je poznat, ali ne i parametri sa kojima radi (svi parametri su 28-bitni). Cilj je pronaći posle kog člana niza moj algoritam može da pogodi sledeći član (sledeći 28-bitni "slučajan" broj).
Brute force metodom, dobije se da je prvih 11 članova niza dovoljno da se pogode svi ostali.

Pa lepo skines sa jednog fajla pa snimis. Skines sa drugog fajla pa snimis i tako sve dok ne ostane u originalnom fajlu samo jedan niz bitova ;)

edit:
a ne moras i duzinu sekvence da pamtis ;)
To sam prevideo.

U svakom slucaju ako je koristen prng mozes da kompresujes ako pogodis formulu i ulazne parametre ;)
Ali u ovom slucaju to nije(valjda).

Ma jsano, samo sam hteo da pokažem Majoru kako problem "slučajnosti" nije baš tako jednostavan. On je na jednoj drugoj temi pretpostavio da je dovoljno da proveri koliko ima jedinica i nula u nekom fajlu, pa ako je blizu 50-50, to mu je signal da je fajl sa slučajno generisanim brojevima.

A i onaj primer koji sam naveo, bio je namerno tako napravljen da bude moguća upotreba brute force metode. RND generator je mogao da se razbije za menje od 1 minuta na običnom PC-u. Da je u postavci bilo da su generisani brojevi 32-bitni ili 64-bitni, već bi bilo teže. Osim toga, od 5 parametara, uopšte ni ne treba da se pogodi svih 5. Posle prve iteracije, seed za novu iteraciju je prethodno generisan slučajni broj, pa sekvenca može da se pogodi i samo pogađanjem 4 parametra, a da se seed za prvu itearciju potpuno ignoriše.

Hvala za link. Da li ima šansi da se malo dogovorimo oko rečnika koji se koristi u ovoj temi? Na primer da ne stavljamo znak jednakosti između random/slučajno i visokog nivoa entropije? Zato što ako neki fajl ima visok nivo entropije on je ujedno i u svakom slučaju random, sa nekom kao slučajnom distribucijom nula i jedinica, plus još neki zahtevi iz statistike. Međutim ako je neki fajl random, slučajan, slučajno dobijen ne mora da ima visok nivo entropije.

Zapravo od random generatora se i traži da ponekad izbace malo uniformniji niz, tj da tretira sve moguće kodne reči od kojih gradi random fajl sa podjednakom verovatnoćom. Kad ne bi izbacivao i takve nizove gospoda što čvakaju veća - manja na poker aparatima bi posle nekog vremena skapirala da nikad ne izlazi 10 puta za redom veća pa bi svoje tipovanje prilagodili tome i napravili bar malo pobedničkiju taktiku.

Još ilustrativnije, recimo da neko ispiše sve moguće fajlove dužine n bita na papiriće i stavi ih u šešir, a onda iz šešira, ne gledajući, izvuče jedan papirić sa kombinacijom. Po postupku dobijanja ovakva kombinacija je apsolutno slučajna/random, a da li će imati i visok nivo entropije zavisi koji je papirić izvukao. Iako mu je mnogo veća verovatnoća da će izvući kombinaciju koja je sa visokim nivoom entropije jer takvih ima mnogo više, ipak postoji mogućnost i da izvuče kombinaciju sa mnogo manjim nivoom entropije. A za takvu kombinaciju koja bi bila apsolutno random/slučajna po nastanku, gornji testovi bi utvrdili da "nije random".

Drugim rečima, testovi koje si naveo proveravaju samo da li je niz bita sa visokim nivoom entropije, koji su doduše i random u tom nekom užem smislu reči, ali ne i da li su random u nekom širem smislu reči.

Ovo pišem jer je i autor challeng-a uradio isto, traži kompresor koji će kompresovati "any" bilo koji fajl dužine 415,241 bajta, ali će proveravati samo na fajlovima koji su permutacije fajla koji već ima, tj. na fajlovima za koje pouzdano zna da će imati visok nivo entropije.



Ok.



Dakle tema je takva da zahteva neki nivo koncentracije, u poslednjoj rečenici nije očekivano da pogodi nasumice 50 puta, nego 100 puta, pola od 200 koliko je dugačak fajl. Takođe bitovi fajla su pogođeni 198 puta od 199, jer si propustio da pogađaš prvu nulu, i pogađao tek od druge .. zašto je tako daješ objašnjenje u sledećem postu gde seed pratiš tek od drugog, kad seed za sledeću 28-bitnu sekvencu postaje prethodno izgenerisana takva sekvenca, bio si pod utiskom posla pa ti se oprašta greška :)



Statistički i bilo kako drugačije gledano, ako bi zahtevao od nekog random generatora da ti s vremena na vreme, ili na zahtev, izbaci random sekvencu dužine 200 bita, bilo bi u redu de jednom u 2^200 (sa verovatnoćom 1/2^200) puta izbaci i baš takvu, i smatrao bi da je super random u odnosu na druge koje je izbacivao. Sa druge strane ako bi to bio algoritam od koga se zahteva da izbacuje nizove bita dužine 200 sa visokim nivoom entropije, onda algoritam koji bi izbacio takav fajl definitivno ne bi bio dobar, tj. ne bi radio ono za šta je zadužen.

Pa eto sve si već i sam rekao, nit je to više za tebe algoritam slučajnih brojeva, nit je broj koji generiše slučajan, niti je generisani broj random i nekomresabilan.. ali hajde kad već skrećem pažnju drugima, da i ja malo vežbam preciznost u izražavanju, jer su ovde stvari svaki čas relativne...

Algoritam je savršeno random, i daje slučajne sekvence bita sve do dužine niza 310 bita napravljenog od sekvenci od po 28 bita, jer takvima ne bi mogao ništa, pa ni da ih kompresuješ.

Počev od dužine niza 340 bita pa naviše, ti bi mogao da kažeš: Vaš algoritam nije dobar random algoritam, i nizovi bita preko 340 bita nisu dovoljno random, i bilo koji takav niz kompresovaću bez problema tako što ću sačuvati prvih 11 članova u kompresovani fajl, a ostatak ću bez problema dekompresovati do pune dužine niza ma koliko to bilo ..



Pa ti si gori od mene, ovo ni ja ne bih izjavio :) Šalim se, povuče te, misliš da neka logika kad se primeni, a bude uspešna, da može više puta da se primeni, a najčešće nije tako.

Mislis PRND ili PRNG? Tj. u ovom slucaju ako ga razbijas za <1min to je vise PRD generator :-)

Da citiram izvesnog von Neumann-a:



:-)

Da te ne maltretiram da tražim da citiraš, znam da ne možeš da citiraš, ne zato što ne bi našao temu, nego zato što nisam to rekao, čak ni ništa slično. Verovatno smo pričali o osobinama random fajla, onog sa visokom entropijom, takav bi morao da zadovolji i taj uslov da ima nula i jedinica 50%/50% približno, jer bi svaka ozbiljnija neravnoteža u tom odnosu dovela do toga da neko može da kompresuje fajl i običnim "statističkim" metodama, jer bi i kodnih reči koji se sastoje od one vrste bita koje ima više u fajlu, takođe bilo više...

Ali ono što bi me zanimalo je na primer šta dalje, ako odlučim da pregledam fajl sa visokim nivoom entropije dalje sa dužim kodnim rečima od jedan, šta bi se dalje dešavalo, i koji fajl bi bio etropius maximus, na primer ako ga pregledam upotrebljavajući kodnu reč dužine dva, tj u potrazi za nizovima 00, 01, 10, 11 njih bi moralo da bude po 25% otprilike, zbog istog gore navedenog, pa onda kodna reč dužine tri, njih bi moralo svake da bude po 1/8 (%), četiri 1/16 (%) itd ...

Ali ni to tako ne može večno, ako u bilo kom trenutku, na dužini neke kodne reči kojom pregledam dođe do ozbiljnije neravnoteže
-> statističke metode, ... takođe postupak ne može da traje dok se kodna reč ne izjednači sa dužinom celog samog fajla koji se pregleda ... pre toga mora da dođe do situacije da na nekoj dužini kodne reči n postoje u fajlu sve kodne reči te dužine, plus da se neke ponavljaju, ali ne sve (osim kad je fajl dužine x * 2^n tad mogu sve da se ponavljaju podjednako), možda mogu saznanje o dužini takve kodne reči zbog neravnoteže koja nastaje - neke se ponavljaju a neke ne - da iskoristim za kompresiju, ili u sledećem pregledanju uz pomoć kodne reči dužine n + 1 tu će se desiti da ne postoje sve kodne reči te dužine u fajlu, a opet sa druge strane neke se ponavljaju ... ? Itd ...



32, 64, 128 nebitno, ako postoji princip, već će se naći brut forsičniji komp da ga primeni ...



Ništa lepše nego kad za seed imaš slučajni broj, a ne tamo da moraš da tražiš neki bezveze :)

Da citiram ja tebe, i poželim dobrodošlicu na temu gospodinu koji je svojevremeno obećao "dve :) gajbe piva" svakome ko random fajl skrati makar i za bit, je l tako bilo? Pa me zaebo da pomislim da je i ovde to uslov, međutim ovde se traži bar za bajt, a ne bit. Oli sam skratio za makar i bit, a u nekim slučajevima i više "any file"? Ako jesam, makar i samo na papiru, ajde da platiš pivo pre nego što maznem 100e sa konkursa, i pre nego što ruiniraš temu svojim čudnim izvorima i rezonovanjima .. Da li treba da citiram?



Ovde na forumu je bio i gospodin koji kad mu zatreba "stvarno" random fajl ili niz, otvači žicu pa skuplja statički elektricitet iz atmosfere, ali ne menja ništa po pitanju random fajla i kompresibilnosti, na nekom dužem random fajlu moguća je kompresija, niz mora da počne da se ponavlja na neki način, ili da bude konstruisan na neki način, u oba slučaja moguća je kompresija, na primer statički elektricitet iz atmosfere ne može dugo da drži ni stanje nula, ni stanje jedan ... a morao bi bar nekad, ako je "stvarno" random ... itd ...

https://jackkrupansky.medium.c...ue-random-numbers-237d89f8a7f2
https://insidehpc.com/2020/09/...antum-random-number-generator/

^ Hvala za tekstove iz novina, zanimljivi su

https://www.elitesecurity.org/t470644-0#3405214
Samo ti mene maltretiraj...

Dobro, pošto nisi mogao da citiraš, linkovao si, na temu gde pitam kako nivo entropije oblikuje teorijski minimum veličine do kog neki fajl može biti kompresovan, nije mi odgovoreno, ali sam dobio nekoliko različitih načina shvatanja, i računanja enropije.

Konkretnije linkovao si na svoju poruku gde ničim izazavan u temu o entropiji, uvodiš veoma nisko entropičnu meteorološku stanicu u pustinji (peščanoj i osunčanoj pretpostavlja se, pošto postoje i kamene, i snežne, i ...) koja neprestano ponavlja da je vreme lepo.

Ilustracija fajla, u mnogo kraćem obliku, sa nulama na početku i jedinicama na kraju stvarno postoji, ali ne da bih ja pogrešno zaključio da ako ima 50/50 nula i jedinica, da je sa slučajno generisanim brojevima.

Nego baš naprotiv, da formula za računanje entropije koja mi je ponuđena, daje isti rezultat za takav prilično nisko entropičan fajl, (a što si i ti pokazao svojim algoritmom za pogađanje, koji u takvom sličnom fajlu pogodi 198 od 199 bita), i drugi koji mnogo više po rasporedu nula i jedinica liči na random fajl, (a gde bi tvoj zamišljeni algoritam za pogađanje omanuo, i dao rezultat oko 100 pogodaka od 200), a u oba slučaja daje rezultat H = 1, kao da su oba sa maksimumom entropije, pa samim tim nekompresabilni.

Ali zašto ja sad prepričavam i objašnjavam nešto što već znaš, e to je tek misterija. I redundansa.

Imas od mene te dve gajbe piva kad me put nanese u BG. Mladji i gluplji "ja" sam lose definisao problem i, naravno, u skladu sa sopstvenom gluposcu to potpuno ignorisao.

Malo vise informisani i mozda malo manje gluplji "ja" bih problem danas definisao na rigorozniji nacin ali to nema nikakve veze sa citatom - tako da moj post-hoc lament ne menja tvoju zaslugu piva.



U bre, sto tako ozbiljno. Nemam nikakav interes u ovoj prici, tako da bez brige, tema nece biti ruinirana sa mojim porukama.

Von Neumann-ov citat je samo zbog nazivanja nekog runtime PRNG-a "RNG-om". Nadam se da taj citat nema nikakav uticaj na tvoju borbu sa kompresovanjem nizova, kakva god da je priroda iste i metod do koga si dosao.

Da te oslobodim obaveze :)



https://www.elitesecurity.org/t151770-0#997617

Nisi rekao "bar za bit", ili nisi u ovoj replici, ili je neko drugi, ili najverovatnije ja pogrešno upamtio, mrzi me sad da tražim.. mada ako smatraš da je proizvoljna "any" bilo koja random sekvenca kompresovna, dođeš mi 20 gajbi piva, kao što lepo piše, i to sam pogrešno upamtio, link je tu za proveru :)



Ma de ozbiljno, zezam se, insistiranje na Šenonovoj Teoriji informacija da je dokaz da je kompresija fajla sa visokim nivoom entropije nemoguća, me beš dosta zakočilo, al to je moj problem, mislim da je Šenon najmanje govorio o ovome, i u ovom smislu, al ajd .. opet comp.compress linkovi su mi pomogli da vidim da ako ne da nisam lud, onda bar da nisam načisto skroz na skroz lud, jer bar ima i drugih lunatika da misle ili pokušavaju da se bave "tematikom". A i moje "ideje" su bile krš, samim tim što ne bi radile, tako da u zbiru sve ok, naravno.

Kakva priroda, i metod, meni ovo "on idle", kad sve druge poslove završim, i ne znam šta bi, onda: A kako bi kompresovali random fajl :)

Vidiš, to što sam linkovao je samo o ilustracija koliko ne shvataš entropiju.
Onako kako je Šenon razmišljao, nije brojanje bitova nego je posmatrao sistem koji se sastoji od predajnika, kanala i prijemnika.
Ono što ga je interesovalo je, koliko se zaista podataka prenosi sa kraja na kraj i kolika je vrednost PORUKE koja je preneta (ne dela poruke nego poruke u celini).

Primer sa wikipedije na engleskom. Zamisli da kroz kanal treba da preneš vest o tome koja je dobitnička srećka na nekoj nagradnoj igri.
Štampano je milion srećki, brojevi 000000 do 999999. Ako želiš da preneseš vest da je izvučen broj 123456 treba ti, otprilike, 20 bitova informacije. Možemo da kažemo da je entropija takvog događaja 20 bitova.
Sa druge strane, vest možeš da preneseš i tako što kažeš: nije izvučen broj 000000, broj 0000001 itd. Da bi preneo takvu vest, treba ti 999999*20 bitova, ali je i dalje vrednost takve vesti 20 bitova. Jedino što je bitno je koji je broj izvučen, a ne koji nije.

Drugi primer: prenos preko serijske linije je nekada bio uobičajeno realizovan kao prenos sedam bitova + paritet (poruku od 8 bitova je uvek morala da ima paran ili neparan broj jedinica, pa bi se na prijemnoj strani moglo PRETPOSTAVITI da je poruka ispravna ako je paritet ispravan).

Dakle, poruka od 8 bitova ima entropiju od 7 bitova.

Upravo na osnovu ovih Šenonovih radova razvijeni su algoritmi za kompresiju. Iz bilo kog razloga, poruka (fajl) koji ima milion bitova u nekim slučajevima ima redundantnost. Može se predstaviti sa manje od milion bitova. Zadatak kompresionog algoritma je da otkrije redundancu i da efikasnije kodira poruku (fajl).

Sa druge strane, fajl (poruka) koji ima slučajan sadržaj, sa vrlo velikom verovatnoćom ima milion bitova entropiju. Jeste, može da se desi da fajl budu sve nule, ali verovatnoća takvog događaja je 2^-1000000
Recimo, da 2⁹⁰⁰⁰⁰⁰ od svih mogućih fajlova NE MOŽEŠ da komprimuješ, a ostale možeš. Ispada, da je verovatnoća da možeš da komprimuješ BILO KOJI fajl od milion bitova 2^-100000.

Sada, gomila ljudi kupuje srećke, sa idejom da će baš oni da ubodu glavnu premiju. Pa, neko hoće ali ogromna većina neće.

Vidim, ali ti nisi rekao da ja "o" ne shvatam entropiju, nego ovo:



A ja to nisam pretpostavio, i to mi nije bio signal za to što kažeš, a zvuči jezivo glupo kad bi bilo ko tako nešto pretpostavljao, pa ako tvrdiš da sam ja to pretpostavljao zvuči kao da tvrdiš da sam tupav, a to nije lepo.

A što se tiče shvatanja entropije, kad već drugi citiraju von Njumena mogu i ja, pardon, Njumena i Šenona:

"I thought of calling it "information", but the word was overly used, so I decided to call it "uncertainty". [...] Von Neumann told me, "You should call it entropy, for two reasons. In the first place your uncertainty function has been used in statistical mechanics under that name, so it already has a name. In the second place, and more important, nobody knows what entropy really is, so in a debate you will always have the advantage."



Upravo, uglavnom o prenosu signala, nešto malo je pričao i o kompresiji.



Pa sad, ja bih rekao da je svašta nešto njega zanimalo, pogotovo što je u kasnijem periodu života uglavnom pravio igračke za decu. Da ga nisu zanimali i delovi poruke ne bi pisao o Joint entropy.



Treba od 1 do 19 bitova informacije, jer je 2^1 + 2^2 + 2^3 + .. + 2^19 = 2^20 - 2 = 1048574 pa uvođenjem različite dužine poruka bez problema saopštavamo koja je dobitna srećka sa manje od 20 bita.



Ne možemo, to bi možda mogli da kažemo ako bi neko i predajnu i prijemnu stranu ograničio na poruke uvek iste dužine, u tom slučaju događaj bi možda mogao da ima entropiju definisanu u Šanon stilu 20 bitova, a poruka najmanje 20 bitova informacija.



A možeš i: nije izvučen broj 000000, broj 1007040, broj 12586473, broj .. i tako bi ti trebalo 999999*20 bitova + beskonačno*x(/=20) bitova i da nikad ne preneseš poruku, pa bi vrednost takvih vesti bila 0. Ti, Šenon i wikipedija vazda zaboravite da kažete šta ste naučili prijemnu i predajnu stranu, i čime ste ih ograničili, pre nego što se odlučite za loše kodovanje da bi ilustrovali .. ne koliko je neko drugo dobro .. nego kolika je entropija poruke. U ovom slučaju rekli ste i prijemnoj i predajnoj strani da mogu da barataju samo izjavama izvučen je/nije izvučen i strogo 20 bita za broj srećke.
Ali bar imaš lep primer kompresovanja podataka koji imaju ceo spektar vrednosti od 000000 do 999999, poruka da nije izvučen nijedan od tih preostalih brojeva, veoma je lepo kompresovana vešću da je izvučena srećka 123456.



Ne nego 7 bita informacija, korisnog sadržaja, i jedan kontrolni bit, a da najčešće nemaju ni 7 bita entropije, ni korisnog sadržaja dokazali su već Lampel i Ziv.



Nisu na osnovu Šenonovih radova, nego Lampel i Ziv uključili mozak i rekli: Ovde ima lufta koliko hoćeš. Zadatak kompresionog algoritma nije da otkrije redundancu, već da kompresuje poruku (fajl), a kako će to raditi zavisi od izvedbe, ti na primer kompresuješ na osnovu prvih 11 sekvenci bez otkrivanja bilo kakve redundance, za efikasnije kodiranje se slažem.



Pa ako za kompresiju proglasiš nešto što fajl može da svuče na 10% od originalne vrednosti verovatno ne možeš ni tih 100000. Nego zašto navodiš taj primer sa fajlom koji ima sve nule? Šta kažeš za fajl koji ima 50% nula, dosta je to redundanse? :)



Skoro pa totalni off topic al ajd, ako te čini srećnim, ili ako tako hoćeš da ilustruješ malu "verovatnoću da komprimuješ bilo koji fajl" :) Ču verovatnoću da komprimujem, il ću da komprimujem il neću.

Zavoravio si bit 0. Treba ti 20 bitova, log(1000000)/log(2) = 19.93

Ma nemoj da cepidlačiš, možeš preko serijske linije da prenosiš komprimpovani fajl. Poruka od 8 bita ima entropiju 7 bita, 1 je redundansa (u opštem slučaju). 7 bita predstavlja "ishod jednog od 128 slučajnih događaja". I to je PORUKA. Nisam ulazio u to da li svaki od 128 slučajnih događaja ima istu verovatnoću pojavljivanja.

Vidiš koliko ti smeta Šenon, nisam ja zaboravio ništa nego ti ne čitaš pažljivo, ako ti prijemnu stranu ugnjaviš i nahraniš sa informacijama tipa: sve poruke su jednako verovatne (je l izvlačiš srećku), pa prema tome za svaku treba 19.93 bita, pa prema tome stićiće poruka dužine 20 bita koja govori koja srećka je izvučena, onda je tako kako ti kažeš, treba najmanje 20 bita da bude dugačka poruka.

2^20 = 1048576, broj srećki = 1000000.

A ako samo malo drugačije nastupiš i kažeš prijemnoj strani: Informaciju o tome koja je srećka izvučena ugradiću osim u raspored bita, i u dužinu same poruke, onda ti treba od 1 do 19 bita da bude dugačka poruka, u svakom slučaju manje od 20.

2^1 + 2^2 + 2^3 + .. + 2^19 = 1048574 - dovoljno za jednoznačno kodovanje svih milion srećki.




Ne cepidlačim, ako ikako temu o kompresiji mogu da povežem sa Šenonom koji se više bavio prenosom informacija, bilo bi da originalni fajl izjednačim sa predajnom stranom tj. izvorom signala, kompresovani fajl sa kanalom, a dekompresor sa prijemnom stranom. Ako pošalješ poruku "run" dužine 3 bajta, svaki bajt ima 7 bita korisne informacije, a ne entropije, i jedan kontrolni bit koji nije redundansa, 7 bita korisnog sadržaja ne predstavlja "ishod jednog od 128 slučajnih događaja" nego namerni događaj ispisivanja reči "run", a kasnije ako hoćeš da cepidlačiš utvrdiš da pošto engleski alfabet ima 26 karaktera, a asci kod 128 kodova, da svaki bajt ima dosta redundanse već u prvih 7 bita, pa ga kompresuješ, tj. ispraviš kodovanje.

Šta je, ne uklapa ti se u računicu? :)

Prosto mi dođe žao da upropastim ovako lep primer sa vikipedije, milion različitih srećki, sa podjednakim verovatnoćama da neka bude izvučena, izvlačenje bilo koje srećke je "nezavistan događaj" od (ne)izvlačenja drugih, i ne samo nezavistan nego i "slučajan" pošto se izvlači iz bubnja, ne gledajući, da bi svi igrači imali podjednake šanse, sve je namikereno da ilustruje da je potrebno 20 bita (najmanje) da bi se poslala poruka o izvučenoj srećki, i na kraju kad treba da pošalješ poruku ispostavi se da može i sa manje :)

Pa jeste to tako TEORIJSKI, ali u praksi malo teže, ipak su potrebni bitovi za kodovanje i sl., a problem je i u prenosu podatka od 3 ili 5 bita, jer praktično sve mora da se spakuje u bajte, tako da bi postojale nule kao prefiksi do punog broja bajta.

Pogledaj način kodovanja karaktera kod UTF-8. Može ASCII da se kodira sa 7 bita umesto da se rasipaju kao kod UTF-16, ali zato imaš zabranjene kombinacije bitova, konkretno ASCII karakteri su jednobajtni, ali prvi bit je uvek "0" tako da kao ne postoji, kod višebajtnih karaktera prvi bajt ima na početku broj jedinica koliko bajta se koristi za kodovanje znaka plus nulu, a svaki sledeći bajt započinje sa "10", tako da kod dvobajtnih karaktera praktično je 5 bitova uvek isto (110xxxxx 10xxxxxx), kod trobajtnih 8 (1110xxxx 10xxxxxx 10xxxxxx), a kod četvorobajtnih čak 11 bita je uvek isto.

Ako bi uvažili da praktično sve mora da se spakuje u bajte, onda ni đoka i vikipedija ne bi mogli da kažu da je za prenos poruke potrebno ni 20, ni 19,93 bita, jer pakovano u bajte onda mora najmanje 3 bajta tj. 24 bita.

Šta su prefiksi i da li su samo nule ne mora da me zanima. Najviše što bi mogli da kažu je da je za prenos poruke potrebno najmanje 20 korisnih bita, plus 4 bita prefiksa koji se preskaču, ne računaju.

Ali to onda mogu i ja, da kažem da se poruka o izvučenoj srećki uspešno prenosi sa 1 do 19 korisnih bita, spakovanih u 1, 2 ili 3 bajta, sa prefiksima koji ne učestvuju u prenosu poruke. Znači i po broju bita, i po broju bajta manje nego što oni tvrde.

Nego mi smešno što je primer sav namikeren da ilustruje baš teoriju informacija, sve različite srećke, sve verovatnoće jednake, jedan nezavisan, i pride još i slučajan događaj ... a računica ne odgovara stvarnosti. :)

Ne znam šta da ti kažem. Ja sam 1988. morao da napišem za vežbu program za komprimovanje Hafmanovim algoritmom, u Fortranu 77.
Ja sam o kompresiji zaboravio više nego što si ti ikada znao.
Sada mi ti prodaješ neke forice, koje su na nivou "napredni amater".
Recimo, iz primera koji sam ti dao, prenos ishoda izvlačenja slučajnog broja od 0 do 999999, U PROSEKU, potrebno je 19 bitova.
Da li znaš da izvedeš računicu za taj podatak?

Da me voliš? :)



Ali ja i jesam na nivou srednje prosečan amater, a ne prodajem nikom nikakve forice, ne moraš da čitaš ako nećeš, ti si u raspravu uveo primer sa vikipedije da bi ilustrovao kako je Šenona zanimalo koliko poruka "vredi". Forica, ne forica, poruka toliko (najmanje) ne mora da vredi, i mislim da sam to pokazao.



Ne, inače bih možda umeo, uz podsećanje na formule, ali ova tematika me ponekad toliko iscrpi da sad ne bih mogao ni da započnem račun, ni za primer koji si ti dao, ni za ovaj koji sam ja, a to me već zanima za ovaj drugi primer, hteo sam i da pitam. Morao bih da sabiram sve od 2^1 do 2^18, pa taj zbir da oduzimam od milion, da bih video koliko tačno poruka je kodovano sa 19 bita, pa ... da računam koliko poruka kojih dužina ima, i da vidim je koliko svaki tip poruka procentualno od milion, i sve to saberem i podelim sa brojem tipova (dužina) poruka da bih dobio prosek?

Evo vala ne znam, zabagovao sam što kažu.

Ja sam vremenom postao malo blazi prema ovome. Evo MajorFatal se setio neke nase epizode od ranije i sad kad pogledam to mogu reci da sam bio previse agresivan i previse brz da sa argumentovane kritike predjem na agresivno spustanje. Imao sam mnogo manje znanja nego sto je mozda izgledalo i svakako manje znanja nego sto sam mislio da imam (kakvo otkrice, nemanje znanja obicno ukljucuje i nemanje ideje da nemas znanje :-).

Danas sam malo stariji i nesto iskusniji pa ne bih tako diskutovao.

Naravno da nista nije promenjeno po pitanju teorije informacija, takodje rec "proizvoljna" (random sekvenca) u mom "zadatku" za 20 gajbi piva je upravo sluzila da se eliminise mogucnost "srece" da se nabode neki niz koji je moguce modelirati.

Ironicno je da kada je Major na ovoj temi pomenuo opkladu da nisam cak ni otisao da citam moju originalnu poruku. Pretpostavio sam da sam dalabu verovatno i preskocio preciziranje - i jos odlucio da podignem ulog sa gajbama piva! :-) Major je posle citirao tu poruku, situacija nije bila toliko crna kako sam mislio da jeste... mada i sa tim "zadatak" i dalje pati od problema nepreciznog izrazavanja, ali svakako nije idiot-case kakav sam pomislio da je bio. Mladost - ludost...

Sto se same materije tice - tu se nista promenilo nije - Shannon i Von Neumann ne moraju da se dizu iz grobova, sve je OK.

Plus, verujem da je i MajorFatal vremenom postao iskusniji i uocio je da >mozda< krsenje vrlo robusne teorije uopste nije ni predmet price.

Ako odustanemo od glupe ideje nekog univerzalnog kompresora proizvoljnih nizova slucajnih brojeva (gde je slucajnost definisana na najjaci nacin) i fokusiramo se na neke probleme sa "slabijim" kriterijumima, i onda ce posao biti tezak ali tu i tamo, za neke nizove naizgled slucajnih brojeva nije iskljuceno da postoji neotkriveni model koji ce mozda jednog dana biti deo neke kompresije, bas kao sto je nekada video signal bio gomila izuzetno tesko predvidljivih podataka, ali kad je pronadjen model koji modelira pravi izvor informacija, i time postize vece stepene kompresije nego npr. aritmeticki koder.

Ovo je svakako "zesce" tesko, pre svega zato sto je ovo tema na kojoj se radi decenijama. Ali, opet, sa novim signalima dolaze nova pitanja efikasnog skladistenja sto, za kao posledicu, ima da je neophodno razumeti sta taj signal sastavlja i da li se to moze modelirati tako da nam pomogne.

E sad prelazim u old-fart mod: cela ta stvar je verovatno dobra samo za gradjenje iskustva i poznavanja materije (jedna od stvari do koje vredi doci je sticanje dovoljno znanja da se, na primer, razume gde se mi na staroj temi nismo razumeli), jako retko se desi da se otkrije neki novi model koji je bolji od stanja tehnike.

Sto naravno nije razlog da se na tome ne radi. Dokle god je zabava, dobrovoljno ili u svoje slobodno vreme... sto da ne, najgore sto moze da se desi je da se nauci nesto novo.

Mada, iskreno, @Majore... ok ako te ovo bas zanima, ali ova tematika je prilicno... kako da kazem, dosadna. Dosadna u smislu da je jako tesko pomeriti granice danas, ima mnogo vise problema gde postoje daleko vece sanse za otkrica. Naravno, ovo je samo moja tacka gledista gde je cilj optimizacije "inovacija", to naravno ne znaci da to ima ikakve veze sa tobom i tvojim razlozima. Ako je to sto volis da radis - godspeed. Ali ako nije, ili ako to radis samo sto ti je dosadno, proveri da nema nesto drugo sto je jos zanimljivije.

Meni nije predmet priče, uglavnom su me sagovornici optuživali da ja tu kao kršim neku teoriju, a meni opet svejedno, gore napisano mogu da opišem kao Šenon i njegova teorija nisu imali pojma pokazano na primeru, a mogu i da kažem ovo baš potvrđuje teoriju informacija jer sam nekom informacijom zajedničkom za sve nizove naučio i kompresor i dekompresor (predajnu i prijemnu stranu) pa taj deo informacije više ne mora da se prenosi kroz kanal (kompresovani fajl). Al uglavnom mi nije zanimljivo ni jedno ni drugo.



E pa izvini, ja zaboravio da povedem Karleušu na druženje, jeste dosadno, ja sam hteo da se prijavim za proučavanje manekenki i brzih automobila, međutim dali mi kompresiju fajlova sa visokim nivoom entropije. Ali jeste dosadnjikavo nastavljati na advocacy ovu priču, pitanje je bilo Jeri sam nasvojio challenge, odgovor je Ne, jer se traži Bar za bajt, što sam ja prevideo. Delimično je kriv i postavljač izazova koji je isto to magao da kaže, ali izglada isto prevideo pa počeo da me optužuje da krijem data i koristim informacije koje je on zadao u izazovu.

I dalje smatram da "There is no data to hide" me oslobađa od optužbe da sam bilo šta sakrio, a da "Make sistem to compress any file of 415,241" znači upravo to, da napravim sistem koji kompresuje/dekompresuje bilo koji fajl te dužine, a ne da me optuži da moj sistem možda radi jer koristim informaciju o dužini fajla, koju je on ne dao, nego zadao. No, nije bitno, toliko o tome na advocacy.