Kompresija random-like podataka 2

Da, ali zasto stajes samo na tim kombinacijama, mozes progresivno da gradis maping tabelu i dalje

dakle
0010 -> 0 01
0011 -> 0 10
...


itd
taj space u binarnom streamu ti je mnogo jak izum, ja bi to patentirao

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Pa, hajde, imaš niz 000000. Kako bi ga kodirao? Ili možda kodiraš samo nizove od 3 bita?

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Na mikro sekund pojacas struju na hardu on se malo vise okrene i eto ti razmak ;).

1.) 000 <- 0
2.) 001 <- 1
3.) 010 <- 00
4.) 011 <- 01
5.) 100 <- 10
6.) 101 <- 11
7.) 110 <- 0 1
8.) 111 <- 1 0

Veoma lepo i slikovito opisan proces dekompresije. Samo pratite strelicu pa se nadam da nece biti dilema u sta se dekompresuje 00 ili bilo koji drugi niz od navedenih.



Ne samo da ne stajem nego necu ni da pocinjem to cete vi programeri da odradite. Znam sta je space ali ne znam sta su maping tabela i binarni stream a nisam mogao ni da pronadjem nigde na netu tako da ne mogu da ti odgovorim. Pa patentiraj, ko ti brani?

On samo hoće da ti sugeriše kako i taj razmak moraš da kodiraš nekim nulama i jedinicama, ako predstavljaš podatke u binarnom sistemu i ako ti kodovi nisu fiksne dužine kada bi razmak mogao i da se podrazumeva.

Potpis

http://sr.libreoffice.org — slobodan kancelarijski paket, obrada teksta, tablice,
prezentacije, legalno bez troškova licenciranja

Kako da ne :)

Potpis

Nebojsa Milanovic:
-Trumpa smatram vrhunskim predsednikom i voleo bih da živim u državi na čijem je on čelu
-Rusija ne laže, ne vodi osvajačke ratove
-Trump je svetla tačka u USA blatu
-Elon Musk, možda najpametniji i najtrezveniji Amerikanac

Shadowed, resistance is futile.

Potpis

oligofrenolog

Istina, u vreme komodora meni je pala na pamet genijalna ideja koja je u stvari vrlo slična majorovoj. Kontao sam ovako memorije ima od 0000 do ffff, to je 65536 bajtova, pa sam razmišljao da napišem neki program koji se nebi zaustavljao na slovu "f" nego da imam i "g" i "h" itd (na taj način bi se softverski povećala fizička memorija računara)... Mnogo jaka ideja, doduše tad sam bio klinja, nekih 15 godina. Šta reći, osim da mi je MajorFatal ustvari ukrao ideju, malo izmenio i sad hoće da postane slavan preko mojih leđa lol

Potpis

Nijedan nepušač još nije preživeo.

A šta se dobija time što se ne zaustavi na 0 i 1, nego se uvedu još i 2, 3, 4, 5, 6 i 7 ili čak još 8, 9, A, B, C, D, E i F?

Ništa!

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

To sto si napisao bi bilo tacno kada bi se na levoj strani na spisku fajlova numerisanih od 1 do 8 i u punoj duzini nalazio bar jedan fajl sa razmakom, odnosno 2 fajla sa razmakom izmedju njih pa kad bi neko pomislio od ta 2 fajla da je to 1 fajl sa obe razlicite vrednosti bita iskoriscene i plus sa razmakom, tada bi i razmak (space) bio neki dodatni signal koji bi naravno morao da se koduje odgovarajucom (novom) kombinacijom bita nula i jedinica ili samo nula ili samo jedinica, kako to nije tako i kako podatke zaista predstavljam u binarnom sistemu ali je moj trenutni "engine" papir, nisi u pravu jer: poslednja 2 reda na desnoj strani predstavljaju po 2 fajla u praksi razdvojena svojim hederima i futerima kako bar ja zamisljam vecinu fajl sistema tj. u praksi space ne mora ni da postoji bitno je da dva fajla plus njihovi hederi i futeri zajedno sabrani i smesteni u neku vrstu registra ili memorije budu u zbiru (broj upotrebljenih bita za sve to gore navedeno) kraci od prostora koji zauzimaju originalne kombinacije bita (fajlova) navedene na levoj strani "crteza" sto je slikovito predstavljeno kao 0_1 i 1_0, tako da ako bi se nasao neko ovde da poznaje osobine fat32 ili ext fajl sistema ili neznamtinijakojeg tj. duzine (u bitima) hedera i futera istih mogao bi brzo da nem odgovori gde je donja granica (eventualne) mogucnosti postojanja (izvedbe) u praksi ovakve kompresije.

??? ne razumem, kada bi razmak mogao da se podrazumeva?

Fajlovi su ti ovde nepotrebna komplikacija koja te skreće sa teme.

Zamisli da imaš samo jedan tok - npr. magnetnu traku - na koji upisuješ tvoj kompresovani zapis. Kao separator između dva bloka („dva fajla“ kako ti kažeš) možeš da uzmeš šta god ti je najzgodnije. Razmišljaj u tom smeru. Šta bi ti odabrao kao separator (razmak)?

Potpis

http://sr.libreoffice.org — slobodan kancelarijski paket, obrada teksta, tablice,
prezentacije, legalno bez troškova licenciranja

@Nedeljko

Ako se ovo odnosi na mene, odgovor: naravno da se dobija: Ako bi imao memorijske lokacije od 0000 do gggg onda ne bi imao 64k nego nekih 80k.

Naravno, davno sam shvatio da je ideja glupost, lepo zvuci ali nema nista od toga.

Potpis

Nijedan nepušač još nije preživeo.

Memorija je tolika kolika je - 65536 bajtova. Da li ćeš ti adrese zapisivati sa šesnaest binarnih cifara ili četiri heksadekadne, sasvim je svejedno. Možeš da koristiš i pet dekadnih cifara, ali onda zapisi u opsegu od 65536 do 99999 ne znače ništa, već samo oni u opsegu od 00000 do 65535 predstavljaju adrese.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Ne bih odabrao nikakav separator (razmak):



vec bih recimo u heder kompresovanog fajla ubacio informaciju kolike su po redu duzine binarnih zapisa nejednake duzine, na osnovu te informacije engine koji cita magnetnu traku ne bi imao dilema gde pocinje koji fajl (binarni zapis) a gde se zavrsava, i koliko ih ima.

Izračunaj sad koliki bi heder bio! ;)

I taj header je predstavljen binarnim zapisom. Tebi header predstavlja separator sadržaja „dva fajla“, razmak. Header mora da ima svoje kodiranje koje ga nedvosmisleno razdvaja od okolnog sadržaja.

Jedna varijanta je da header bude fiksne dužine tako da program koji čita zna da uvek čita npr. dva bajta za dužinu, pa toliko bajtova za blok do sledećeg headera.

Sada u svoj račun dužine kompresovanog teksta uračunaj ta dva "izgubljena" bajta. Ili predloži neko drugo rešenje za separator sa kraćim gubicima.

Potpis

http://sr.libreoffice.org — slobodan kancelarijski paket, obrada teksta, tablice,
prezentacije, legalno bez troškova licenciranja

@Nedeljko

upravo tako, ali tad to nisam znao

Potpis

Nijedan nepušač još nije preživeo.

...koji se takodje sastoji od bita, ali to vec uspesno rade operativni sistemi i ostali specijalizovani programi, "prepoznaju" fajlove koji im trebaju na osnovu raznoraznih informacija koje su pothranjene na raznim mestima neke u os-u neke u samom programu...



A druga bi bila da heder ipak ne bude fixne duzine ali da program koji cita zna da cita ono sto treba da cita bilo 2 bilo 1 ili 3 ili vise vec po potrebi bajta za duzinu kao i za sve ostalo sto je vec smesteno u hederu...



Obavljeno, i postavio uslov koji mora da se zadovolji da bi kompresija (i dekompresija) zazivela u praksi. 2 bajta nece da mi zafali kad kompresujem fajl od 4,7 giga? Ali ni za fajl od 4,7 giga tesko da ce header biti duzine 2 bajta vec vise?

Kada na disk snimiš prazan fajl, on obzirom da ima ime i podatke o atributima i drugim stvarima, već zauzima neki prostor na disku. Taj heder je negde uspisan, radio to tvoj program ili OS, sasvim svejedno. Onda moraš i to da uračunaš u ukupan utrošeni prostor.



I gde je proračun ukupnog zauzetog prostora sa hederima?

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

duzina 2 fajla (ta makar bili i "prazni") + odgovarajuci hederi i futeri tj. bilo sta sto garantuje pravilno citanje ta dva sadrzaja ta dva fajla, moze da bude i jedan heder za oba u tom slucaju heder bi morao da sadrzi informaciju gde se zavrsava prvi a pocinje drugi ili gde je futer prvog a heder drugog (jer je sadrzaj oba fajla sasvim sigurno zapisan u bitima), ali ono sto je bitno je da sve te informacije o sadrzaju oba fajla sa pripadajucim bitima koji cine heder i futer ili oba u zbiru moraju da zauzimaju manje ili jednako mesta od najduzeg po broju bita "jednostrukog" fajla (a cija je duzina n-1 da bi kompresija/dekompresija postojala), nego eto zapetljah se, upravo sam skontao da i prethodni "jednostruki" a razliciti fajlovi moraju imati svoje hedere i futere, tako da i dalje nije nemoguce ali ne mogu lepo da objasnim, moja greska, aj zanemarite i zaboravite.