Ich glaub ich muss Dich ent�uschen... So einfach,wie Du Dir das vorstellst ist das ganze nicht... 1. ist es sehr unwahrscheinlich, dass sich lange stellen im bin�rcode eines bildes wiederholen, auch wenn das bild sehr �hnlich ist. 2. gibt es sehr viel leistungsf�higere Pack-Algorithmen, als diesen, denn Du benutzen m�chtest... Im Moment w�rde, auch wenn Dein Algorithmus genauso funktionieren w�rde, wie Du es Dir vorstellst, gute Packer wie RAR oder bzip2 viel besser packen, auch wenn diese nicht auf vorinformation bauen k�nnen... RAR hat z.B. optimierte Methoden f�r Medien, also z.B. Bilder und Sounds etc. Auch passen diese Algorithmen optimal das was Du Blockgr�sse nennst an - auch w�hrend des Packvorganges, d.h. sie fangen z.B. mit kleinen Bl�cken an und setzen dann gr�ssere Bl�cke aus kleineren zusammen etc..
In diesem Bereich ist es nicht einfach weitere Verbesserungen zu erreichen... Rein theoretisch ist es zwar wirklich so, dass man umso besser packen kann, je mehr vorinformation hat, jedoch muss man daf�r bestehende Algorithmen anpassen, denn diese fangen immer mit null Information an... Solche Algorithmen kann man auch gut an bestimmte Arten von zu packende Daten anpassen, hierzu muss man aber nicht nur mit gesunden Menschenverstand arbeiten, sondern auch viel mit Tests... Du solltest es Dir wirklich schwer �berlegen, ob Du selbst weiter in diese Richtung forschen willst... Denn das k�nnte l�nger dauern... Falls es Dich trotzdem interessiert, informier Dich �ber folgende Themen: Informationstheorie, Informationsgehalt/menge, Entropie, Redundanz, Kodierungstheoreme, Quantisierung/Vektorquantisierung, Kompressionsalgorithmen, Huffman, Lempel-Ziv Hierzu findest Du bestimmt einige gute B�cher, ansonsten kannst Du mit google starten... Wenn Du weiter machen willst, w�rde ich die Spielereien mit Texten lassen und gleich auf bin�re Daten verallgemeinern. Gruss, Claudius > > hi claudius, > > > >Du hast noch zu wenige Informationen gegeben... > > hmm, wenn du meinst ;) > > >Was willst Du eigentlich zum Schluss haben? Alle Positionen aller > >gemeinsamen String oder Anzahl und L�ngen derselben oder die > Anzahl der > >Zeichen, die die gleichen Bl�cke ausmachen oder was? > > > was ich zum schlu� haben will.. nunja, wo fang ich an. > eigentlich ist es etwas, was es schon lange und in vielen formen gibt. > eine art patch-programm, welches (beliebige) dateien > vergleicht und daraus > eine neue datei erstellt, die dann runtergeladen werden kann > und mittels > einem weiteren programm die neue datei generiert. > > die anwendungsm�glichkeiten sind sehr umfangfreich(zb update f�r > irgendwelche programme). sowas gibts nat. zuhauf. ich wei� > dass, und viele > andere wohl auch. selbst von ms gibts ein kl. tool, welches > patch-dateien > erstellt und mittels windows-installer die entsprechenden > dateien dann auch > patcht. > > mein prim�res anwendungsgebiet liegt aber in einem (�hnlich > gelagerten) > anderem punkt. ich will, dass sich verschiedene fachh�ndler bilder > downloaden k�nnen. diese bilder sind zum gr��ten teil recht gro� > geworden(cmyk, 300dpi, plakatgr��e), so dass die entweder > tage brauchen bis > die dateien letztendlich da sind, oder jahre, weil die > telekom noch kein dsl > bereitgestellt hat(von den kosten der gruppe f�r den server mal ganz > abgesehen). > > nun hab ich mir gedacht, dass man eine "alte" datei zum > download freigibt, > die recht gro�e aber/und immer wiederkehrende bl�cke aus den > anderen dateien > beinh�llt. selbst wenn die dateien sehr gro� wird, hat der > verband gemeint > dass sie gerne, wenns denn sein muss, jedem eine cd > schicken.. hauptsache > sie m�ssen nicht w�chentlich so eine aktion starten. > aus diesem grund kann ich auch diff (und auch das tool von ms) nicht > wirklich verwenden. sp�testens bei der untersuchung aus > mehreren dateien und > das feststellen der gr��ten und der am "�ftesten" > auftretenden gemeinsamen > bl�cke wird damit unm�glich. ganz abgesehen von weiteren > optimierungsm�glichkeiten, die mir da so einfallen. > > naja. damit hab ich mal vorgestellt, was ich �berhaupt will. in meiner > jetztigen testphase bin ich erst noch bei textdateien.. das ganze > umzustellen auf bin�rdaten sollte kein problem darstellen. > > > >Suchst Du nur 10er-Bl�cke oder sollten die Bl�cke m�glichst > maximale L�nge > haben? > > die 10 war nur ein beispiel. es sollten m�glichst lange > bl�cke gefunden > werden. die mindestblockgr��e wird als option einstellbar > sein(von 10 bis > 1000 oder so, je nachdem, was sinnvoll erscheint) oder, wenns wirklich > schnell wird, je nach datei automatisch selbst gesetzt. > > aber das "finden" gleicher bl�cke ist leider gar kein problem. dies > funktioniert und ist sogar schnell (und da wei� ich sogar, > wie ichs noch > mehr optimieren kann*g*) > mein problem ist das finden der unterschiede, die mein user sp�ter > downloaden muss(nicht die offsets der alten datei). > die routine, die ich hier gepostet hab springt an, sobald ich einen > gr��tm�glichen block habe, und ein unterschied aufgetreten > ist. es sucht mir > das n�chste auftreten eines blockes, der mindestens der > mindestblockgr��e(10) entspricht. alles was davor(!) kam muss > als�"klartext" > (bzw. bin�rdaten) sp�ter mitgegeben werden. > > bsp.: > text1 = "Hallo Welt, das ist ein langer Text" > text2 = "Hallo Welt, das war ein langer Text" > > ergebnis w�re bei diesem beispiel: 0-16,war,19-16 > im klartext: offset 0, l�nge 16 aus bestehender datei, "war" einf�gen, > offset 10, l�nge 16 aus alter datei. (hab jetzt nicht genau > nachgez�hlt, > sollte aber stimmen) > hier w�re es das finden des offsets 19. ich muss ab "w" byte > f�r byte (hier > sinds nur 3) durchgehen, bis ich wieder etwas finde. und > dieser vorgang ist > mir zu langsam. > > nat�rlich sieht das dateiformat letztendlich etwas anders aus ;). > > auch hier fallen mir etliche gr�nde ein, um diff nicht zu > verwenden. ich > will nicht nur die unterschiede, sondern sp�ter auch immer > wiederkehrende > bl�cke als zahl/offset mitgeben. das kann diff nicht(und > wollte es auch nie > k�nnen, ist ja was "ganz" anderes *g*) > > > > >Gibt es irgendwelche Bedingungen, die man ausnutzen kann? Ist es z.B. > >so, dass gleiche Teile immer in der gleichen Reihenfolge > vorkommen, das > >w�rde z.B. heisen, dass man z.B. wenn man in beiden Texten > ungef�hr in > >der Mitte eine gleiche Textpassage hat und man sucht jetzt > weiter, dann > >kann man den ersten Teil der beiden Texte ignorieren.. > > > nein. leider nicht. geh mal davon aus, dass du als "alte" datei > beispielsweise die "shell32.dll" vor dir hast, und deine neue > datei ein bild > von dir ist ;) > zu einschr�nkungen komm ich erst sp�ter noch (version der alten datei, > version der neuen, berechtigungen usw. soll alles in den dateien > stattfinden... aber wie gesagt. eins nach dem anderen). > > > >Ansonsten kannst Du ja mal schauen was VB bringt... Das d�rfte keine > >grosse Umstellung darstellen.. > > > >Ich weiss auch nicht welchen Algorithmus VB(S) f�r Instr verwendet. > >Unter Umst�nden lohnt sich eine eigene Implementierung. Siehe > >Boyer-Moore: > >http://www.google.de/search?q=boyer+moore&hl=de&meta= > > > das ganz ist bis jetzt in vb gehalten. asp war nur die > "ausrede" f�r dieses > forum ;) > boyer-moore hat leider nichts gebracht. habe es gestern erst > als vb-klasse > entdeckt(und ehrlich gesagt noch nie zuvor davon geh�rt). > naja. ich habs > eingebaut und es hat nichts gebracht(rein subjektiv wars > sogar langsamer. > gemessen wars ca. gleich schnell). ich hab mich dann wenigstens etwas > eingelesen und kam dann zu einer passage, in der es hie�, > dass boyer-moore > umso schneller wird, je mehr zeichen f�r den vergleich > herhalten m�ssen. > diese zeichenanzahl liegt bei mir zwischen 10 und 1000(siehe > oben). hohe > dynamik ist da nicht zu erwarten. leider. > > was vb da benutzt, wei� ich auch nicht. aber boyer-moore > d�rfte es nicht > sein sonst w�re der gestrige tag zur h�lfte vollkomen umsonst > verbraten... > und das will doch hoffentlich niemand ;) > > > mal sehn, obs diesmal reicht .. wolfgang > http://www.vbwelt.de/ > > > | [aspdecoffeehouse] als [EMAIL PROTECTED] subscribed > | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv > | Sie k�nnen sich unter folgender URL an- und abmelden: > | > http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffee house.asp | [aspdecoffeehouse] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
