- SkyShowtime
- A pápa egyre jobban tart a romlott AI veszélyeitől
- WLAN, WiFi, vezeték nélküli hálózat
- foobar2000
- Milyen NAS-t vegyek?
- A franciáknak elege van abból, hogy minden gyerek mobilozik
- Az iPadOS-re írt appokra is díjat vet ki az Apple
- Sweet.tv - internetes TV
- Windows 11
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
Aktív témák
-
Lamerjohny
csendes tag
Hi all!
Olyan problémám lenne, hogy nagyon félrenyúltam a szakdogatéma választásánál, merthogy
arra válakoztam, hogy irok valami frankó tömörítőprogit ami XML fájlokra van optimalizálva. Utólag rájöttem, hogy ez nem is olyan egyszerű
Az alapötlet az lenne, hogy az xml szintakszisa alpán kitalálni valami algoritmust amivel a sima xml fájlból kisebbet csinálok (valahogy a tag-ek összevonásával) aztán a végeredményre rányomni valamilyen tömörítő algoritmust. Ha valakinek van ötlete plíííz segítsen!! Előre is köszönöm! -
robisz
senior tag
válasz Lamerjohny #1 üzenetére
Helló!
Szerintem király a téma én első körben szétnéznék a neten, hogy mit alkottak mások...
Pl. olvasd el ezt (pdf):
[link]
Valamint nézd meg az xmill nevű open source projectet ami éppen azt
csinálja amit te szeretnél...
Sok sikert!
[Szerkesztve] -
dark100
aktív tag
válasz Lamerjohny #1 üzenetére
Mindenkepp valami zip-es huffman vagy aritmetikai tomoritest javaslok xml-re, miutan alapvetoen textes file, keves fele karaktert hasznal sok ismetlodessel. Magam is szovegtomoritesbol irtam diplomamunkat (bar az altalnos volt). A gyakori szovegek (tokenek) atalkitasa nekem ugy tunt nem hoz szamottevo elonyt. Bar az xml eseten meg lehet probalni a nyelv tulajdonsagait felhasznalni, sokat segithet, ha minel tobb informaciot ki tud a programod talani, mert azt nem kell tarolni. Amugy minden tomorites lenyege az, hogy minel tobb kitalalhato info legyen, amit nem kell tarolni.
Ingyenes software == A mezeskalacs haziko a Jancsi es Juliskaban. Es != szabad software
-
moonman
titán
ezteth a nagyok már meg is csinálták [link]
-
dark100
aktív tag
válasz Lamerjohny #5 üzenetére
Probald ki. De tenyleg ovatosan a szetszedessel, mint mondtam, nekem nem valt be.
Pl:
20x szetszorva a fileba:
<nev param1=''value1'' param2=''value2''>Content</nev>
Ha te ezt szetszeded, akkor rosszabbul fogod tomoriteni, mintha egybe van. A korotte levo szokozok pl mindig szamottevoen javitanak a tomoitesi hatekonysagon.
Pl:
'' <nev ''
Ha ez eleg gyakran elofordul, akkor, barhogy is szeded szet, szinte biztosan gyengit a tomoritesen.
Az MS amugy jol latja, a zip tenyleg eszetlen jol viszi a text-eket. (Az az Industry Standard Compression duma csak kabitas a hulyeknek). Csak az aritmetikai tomorito vagy a bzip tudja megszorongatni, de az is csak nagyobb file-oknal (asszem tan valahol a megabyte meret kornyeken tudnak beelozni).Ingyenes software == A mezeskalacs haziko a Jancsi es Juliskaban. Es != szabad software
-
robisz
senior tag
válasz Lamerjohny #5 üzenetére
Olvasd el az xmill hogyan szedi szét a tag-eket a tartalomtól...
Ezzel igenis sokat lehet nyerni főleg ha nagy az xml és sok egyforma
tag van benne... -
dark100
aktív tag
Sajnos nem igazan valik be. Erdemes kiprobalni, en is igy inditottam
Csak nem jott be. Azutan gondolkoztam el a vereseg okain. A valasz fajoan egyszeru. Csak a kiszamithato informaciok tomorithetoek hatekonyan! Ha szetszedsz egy file-t, akkor informaciot kell arrol tarolnod, hogy eredetileg mi hol volt benne (ez egy redundans informacio!). Ezen informaciot radasul tarolnod is kell, megha tomoritve is (no a meret). Radasul a szetszedes nem is feltetlenul optimalis! A zip ismetleskereso algoritmusa tapasztalataim szerint jobban teljesit mint az ember altal ugymond okosan keresett ismetlesek.... Keress kiszamithato informaciokat! Pl ha a fileban minden / utan > van, akkor ez kiszamithatova tesz valamit, es maris hatekonyabb lesz a tomorites!Ingyenes software == A mezeskalacs haziko a Jancsi es Juliskaban. Es != szabad software
-
robisz
senior tag
Akkor gondold végig mégegyszer és rájössz, hogy nagyobb méret esetén
nagyon is megéri szétszedni.
(Az xmill-ről is azt írják, hogy 20kb felett kezd jobb lenni a gzip-nél,
de ez alatt nem is nagyon érdemes tömöríteni)
Persze mindig lehet olyan esetet találni amikor rosszabb lesz a sima
zip-nél (pl ha minden xml tag és attribútum neve különböző) de ez
nagyon ritkán fordul elő. -
dark100
aktív tag
Altalaban azon szokott elcsuszni a dolog, hogy az ember elhiszi amit mondanak de nem probalja ki. Es nagyobb szoveges file-okat nyilvan a bzip2-hoz illik hasonlitani. Mindenesetre fel akartam hivni a lehetseges bukkanokra a figyelmet. Amugy ha kesz az egesz akkor erdekel hogy milyen hatekonysagul lesz.
Azert megegyszer a tomoritessel kapcsolatos altalnos tapasztalataim:
1. mindig keruld a redundans informaciokat. Pl hogy valamit kivagsz, es egy mutatot teszel ra.
2. mindig talald meg a fellelheto szabalyokat es irts amit lehet. Ha pl a kocsi mindig attributum nev, es mindig van elotte egy szokoz utana meg egy ='' akkor maris van 3 karaktered amit 100% hatekonysaggal kivegezhetsz a filebol.Ingyenes software == A mezeskalacs haziko a Jancsi es Juliskaban. Es != szabad software
-
robisz
senior tag
Nem értek egyet az 1. pontoddal... pont ez a lényeg... képzeld el hogy van egy
hosszú nevű xml elemed pl.
<nagyonnagyonhosszúelemnév></nagyonnagyonhosszúelemnév>
Ez 54 karakter... most tegyük fel, hogy ez előfordul 1000-szer,
ez 54000 karakter.
Az xmill amikor elmenti a struktúrát, minden elemet lecserél egy integerre
a lezáró elem helyére pedig egy ''/'' jelet tesz.
Tehát a fenti elemből
''1/''
lesz 1000-szer ami 2000 karakter, plusz egy ''jelmagyarázat'' az elejére
''1=nagyonnagyonhosszúelemnév'' ami +27 karakter.
Így lesz az 54000-ből 2027 karakter és még csak ezután fogod zip-elni...
Ezenkívűl lehet úgy is optimalizálni, hogy a különböző típusú adatokat
külön konténerekbe teszed (pl. külön a csak numerikusakat stb)
és speciális tömörítővel külön külön tömöríted őket.
Egyébként nem hiszek el mindent amit olvasok.... de mi lenne ha kipróbálnád???
[Szerkesztve] -
robisz
senior tag
Egyébként ki tudnád fejteni, hogy a fenti módszer hol tartalmaz redundáns
információt? -
dark100
aktív tag
Egyszeru. Az 1 redundans informacio A zip jobban fel fogja a tageket ismerni, es radasul meg a kornyezetuket is felhasznalja. Tehat a tagot mindig attrib1='' koveti, akkor azt is hozzacsapja, ha tag elott mindig 3 tab es < van akkor azt is, de ha a tag mindig ujsorba kezdodik akkor az enter-t is stb, ha az elozo sor vegen mondjuk mindig ''> van akkor azt is, stb. Ezt megcsinalja az xmill?
Egyszeru pelda:
Melyik lesz kisebb tomoritve: Ha byte-okat tarolsz, vagy ha minden byte helyett annak hexadecimalis (0-9 A-F) vagy binaris formajat (csak 0 es 1)? Ugye a naiv ember ravagja, hogy ezek alapvetoen azonos informaciot hordoznak, valoszinu egyforma meretuek lesznek. Hat nem...
Tomoritesben redundansnak hivjuk azt az informaciot ami kiszamithato. Az 1-esnek kiszamithato erteke van, hiszen az a hosszunev beillesztheto a helyere. Kov: a hosszuneves forma jobban lesz tomoritheto. A zipnek egy benasaga van, hogy csak 32 kbyte-ra hajlando visszanezni ismetlesek keresesenel. (torteneti okok) Ezen a ponton lehet megfogni. (valszeg az XMILL is ezert javit, hiszen ha a tagbol sok van, de 32 kbytenal nagyobb tavolsagra szetszorva, akkor a zip megszivja). Probalj ki olyat aminek nincs ilyen korlatja, pl bzip2.Ingyenes software == A mezeskalacs haziko a Jancsi es Juliskaban. Es != szabad software
-
robisz
senior tag
Szerintem te rosszul értelmezed a redundanciát
Abban igazad van, hogy az 1-es kiszámítható abban az értelemben,
hogy tudjuk, hogy a ''hosszúnév''-nek felel meg.
De ennél sokkal fontosabb, hogy az ''1''-esek a hosszúnevek HELYÉT
jelölik...
Redundáns az az információ ami fölösleges, plusz információt nem hordoz...
Te viszont itt az 1-esek nélkül az életben elő nem állítod az eredeti
tartalmat tehát egyáltalán nem redundáns az információ.. csak másképpen,
hatékonyabban van ábrázolva.
Szerintem ha erre engedsz rá egy bzip2-őt akkor az esetek nagy részében jobb
eredményt kell kapnod...
De tudod mit? Most már én fogom kipróbálni... -
robisz
senior tag
Hmmm... kipróbáltam és az eredmények téged igazoltak...
Az xmill-hez adott példa xml-eket becsomagoltam bzip2-vel ami
egy esetet kivéve le is alázta az xmill-t...
Úgyhogy MEA CULPA....
Most már értem miért döglött be a project 2003-ban
De a redundanciára vonatkozó állításomat fenntartom -
shev7
veterán
Abba gondolj bele, hogy a hosszunev az altalaban csak tagkent fordul elo a szovegben, igy egyertelmuen tomoritheto, mig ha raksz a helyere egy 1-est, ami mas kornyezetben is elofordul a szovegben, akkor ez noveli a szotarmeretet, es rontja a tomorites hatasfokat.
Szerk:
Redundanciara visszaterve. Az egyesek redundanasak, mert plussz informaciot nem hordoznak. Nem, az hogy ott vannak az nem plussz informacio. Hiszen a tomoritonek jobb lenne, ha nem lennenek ott, ahogy mar az elobb kifejtettem
[Szerkesztve]''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
robisz
senior tag
Amit irtam az nagyon le volt egyszerűsítve... nyilván egy ''kereskedelmi''
tömörítő 1000-el bonyolutabb, de a fenti példát az is hasonlóan tömörítené
össze...
Nyilván az 1-esek rontják a tömörítés hatásfokát, de ott már egy
20-ad akkora szöveget kell tömöríteni...
(1ébként az xml struktúrát és az adatokat külön tömöríti az xmill, tehát
nem fordul elő más szövegkörnyezetben) -
shev7
veterán
(1ébként az xml struktúrát és az adatokat külön tömöríti az xmill, tehát
nem fordul elő más szövegkörnyezetben)
Azert ez erdekes lenne. Az adatok koze be kell tenni egy markert, hogy melyik adat hova tartozik, akkor viszont a szerkezet mar benne van az adatokban, es ujra elojon a redundancia.''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
robisz
senior tag
Egész pontosan a struktúrába tesz be adatokra mutató ''pointereket''
(azokat is integerekkel helyettesíti)
Továbbra sem látom hol itt a redundancia... melyik az a rész amit
el tudsz hagyni úgy hogy visszaállítsd az eredeti tartalmat???
Egyébként nem hiszem, hogy egy diplomamunka keretében
reális elképzelés egy bzip2-nél hatékonyabb tömörítés kidolgozása -
shev7
veterán
ha egy fileban vannak, akkor nem kellenek a pointerek. Ez egy olyan struktura amiben a pointerek elhagyhatoak, tehat redundanciat hordoznak.
Szrek.: ha jol tudom ezek az eljarasok mar elege kozelitenek a maxmimumhoz hatekonysag teren.
[Szerkesztve]''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
robisz
senior tag
Igaz, csak így az ismétlődő adatokat egyszer teszem bele a fájlba
és a pointerek szerepelnek többször...
A példában amit írtam az 50000 karakterből 2500 lett... a te logikád
alapján mondhatnám én is, hogy az eredeti xml redundáns, mert
tartalmaz 47500 felesleges karaktert
Én elfogadom, hogy a pointer redundancia, de pici redundancia
ami egy nagyon-nagyból lett létrehozva -
Lamerjohny
csendes tag
Van mégegy project a sourceforge-on:
http://sourceforge.net/projects/xmlppm
Kiprobáltam egy próbafájlra és jobb lett mint a bzip2. -
shev7
veterán
A példában amit írtam az 50000 karakterből 2500 lett... a te logikád
alapján mondhatnám én is, hogy az eredeti xml redundáns, mert
tartalmaz 47500 felesleges karaktert.
En arrol beszelek hogy a tomorites soran ugyis az ismetlodesek lesznek kikuszobolve. Attol, hogy lecsokkented a file meretet, az informaciotartalmat nem csokkented le, a tomorites merteke meg nem a file eredeti meretevel van osszefuggesben, hanem az eredeti file informaciotartalmaval...''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
shev7
veterán
Arrol beszelek, hogyha az ismetlodesek lesznek kikuszobolve, akkor mi ertleme csokkenteni egy tag hosszat, ha a tomoritonek mindegy, hogy eredetileg milyen hosszu volt?
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
shev7
veterán
Ha nem csokkented az informaciotartalmat, akkor egy bzip elott felesleges barmit csinalnod a filelal, mivel ez az algoritmus szinte a maxmalis hatekonysagu. Erre akarok kilyukadni.
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
-
shev7
veterán
A tomoritett filban nincs redundancia (idealis esetben) a tomorito pedig nem karakterekkel dolgozik, hanem ismetlodo karaktersorozatokkal.
Szerinem most te nagyon kevered itt a redundanciat es a tomoritest. Az XML nem attol ''redundans'' hogy hosszu egy tag neve, hanem attol, hogy sokszor fordul elo.
Ha te ''pointerekkel'' csokkented a file meretet akkor olyan redundanciat viszel a fileba (redundancia, mert a ponter mondja meg, hogy hol legyen az adat, pedig akar az adatot is irhatnad oda) amivel a tomorito nem igazan tud mit kezdeni.
[Szerkesztve]''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
robisz
senior tag
Csakhogy nekem nem az volt a célom, hogy a GZIP ÁLTAL JÓL FELDOLGOZHATÓ
(GÁJF (c)) karaktersorozatot hozzak létre... hanem én magam akartam tömöríteni...
A fenti példában sikerült is kb a 20-adjára....
Szintén a te gondolatmeneted követve: a winrar ritka szar tömörítő...
olyan redundanciát visz a fájlba, amivel a winzip már nemnagyon tud mit kezdeni... -
dark100
aktív tag
Huha latom hatalmas duma volt
Es igen jol ramentetek a lenyegre. A file-nek van informaciotartalma es van hossza. Szamos modszer van ami meretet valtoztat de informaciot nem.
De amugy egy jo otlet mar elokerult: Az XML alapvetoen egy fa adatszerkzetet tarol, ahol minden nyitotagnak van zarotagja. Ennek a zarotagnak a tartalma kotelezo.
Pl: <tag1> <tag2> </itt muszaly tag2nek lennie> </itt muszaly tag1nek lennie>
Namarmost akkor a zarotagok helye ugyan nem, de tartalmuk egyertelmuen szamithato. Ez AZ a szamithato informacio, amire egy zip tomorito nem johet ra! A zarotagok kiiritasaval a file valoban egyszerusodik a masodrendu tomorito szamara. Ha mondjuk pointerekt raksz informacio helyere, azzal nem egyszerusites, csak atnevezel. Ha pl teged Karcsinak hivnak, majd valaki K-nak nevez at, mert azzal letomoritett, akkor ki fogod rohogni. Hat ez van a tagokkal is........Ingyenes software == A mezeskalacs haziko a Jancsi es Juliskaban. Es != szabad software
-
shev7
veterán
Namost ha tomoriteni akarsz a meret fontos tenyezo. Ha lecsereled a tag-eket (hozzateszem egy xml file nem csak tagekbol all, ott van meg mellette adat is, igy santit a 20adjara tomorites) azzal meg sem kozelitetted az adott file tomorithetosegenek hatarat. Viszont igy a sajat tapasztalataid alapjan is rontottad a gzip hatekonysagat, ami azert kozel van a Shannoni hatarhoz ( ) tehat akkor rossz iranyba indultal el. Csak ennyit akartam mondani.
Szintén a te gondolatmeneted követve: a winrar ritka szar tömörítő...
olyan redundanciát visz a fájlba, amivel a winzip már nemnagyon tud mit kezdeni...
Erre inkabb nem mondok semmit. A winrar (majdnem) hozza a winzip hatekonysagat, a te modszered kozel sem.
[Szerkesztve]''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
-
robisz
senior tag
A winrar (majdnem) hozza a winzip hatekonysagat, a te modszered kozel sem.
Hát az tuti.... de ezt nem is állítottam
Ezt az xmlppm-et viszont érdemes lenne megnézni... kipróbáltam pár fájlon
és eddig még mindig jobb eredményt adott a bzip2-nél...
Csak az xml parse-olással van gondja néha, nem minden fájl tetszik neki
Aktív témák
- AirPods Max - Silver (Hibátlan és tökéletes állapot, tulajdonképpen új, pár napot volt használva)
- LEGJOBB ÁR! GAMER PC - RTX 3070 - Ryzen 5500 - 16GB DDR4 - 500GB Nvme SSD
- ÚJ Playstation 5 CFW képes (feltörhető), lemezes
- ÚJ Dell Vostro 3520 - 15.6" IPS 120Hz / i5-1235U / 8-16Gb DDR4 / 512Gb / HUN backlit / 3 ÉV GAR.
- Nikon D7000, Tamron 18-270mm, Sigma 150-500mm
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest