Beiträge von Andy

Naja, "Koordinaten" aus Binärdateien rauszuholen, sollte nicht das Problem sein. Wenn man weiß, nach was man sucht....

"Früher" hat man die Daten weder komprimiert, noch sonstwie "verkleinert", jedenfalls nicht mit einem Kompressionsalgorithmus. Bissl "bitweise zusammengeschoben" um einige Bytes an dem teuren Disketten/Festplattenplatz zu sparen war "State of the art".

Von daher wäre es jedenfalls sinnvoll, jeweils eine Datei mit den "Steuerungsdaten" (im Klartext, bspw. g-code) zu bekommen, als auch eine der daraus erstellten "Binärdateien".

Ich verweise da mal auf DTX Daten als Bild in GUI anzeigen

So macht man das...

Ich hatte in Ruhe gelesen

Nun zitiere ich dich:

Zitat von AspirinJunkie

dann muss das Ergebnis korrekt auf die darstellbare Genauigkeit hin gerundet sein

Was soll DAS denn? "Korrekt" ist ja wohl mit mehreren verschiedenen Möglichkeiten einer Rundung schlecht machbar, oder nicht?!

Und die Anzahl der Stellen ist dabei belanglos, denn das definiere ich ja in meinen Anforderungen.

Das Problem ist, und das kommt in diesen Beiträgen keineswegs rüber, nicht die Berechnung an sich, sondern die Darstellung der Nachkommazahl.

Und die hat wiederum mit der Genauigkeit der Berechnung nichts zu tun!

Beispielsweise rechnet die "alte" FPU in x86-Prozessoren mit 80 Bit Genauigkeit. Dargestellt werden idR Zahlen (nach IEE 754) mit 64 Bit. Man könnte jetzt meinen, egal nach welchem Verfahren gerundet wird, das Ergebnis ist immer "richtig", da der letzte Teil der Nachkommastellen, die 16 Bit Differenz, sowieso abgeschnitten wird. Für eine einmalige Addition/Multiplikation ist das auch wahr, egal welchen Rundungsmodus ich im Prozessor einstelle.

Also wo liegt das Problem? Das Problem liegt in der Berechnung innerhalb langer Schleifen, in der dieser "Fehler" in jeder Berechnung mitgeschleppt wird. Irgendwann dringt der Fehler in den Bereich der Darstellung vor, wobei die Anzahl der dargestellten Nachkommastellen dabei irrelevant ist.

Zitat von AspirinJunkie

Konkreter: Rechenergebnis mit 10 Stellen wäre: 0,1234567890 - dann muss diese Zahl folgendermaßen auf 5 Stellen abgebildet werden: 0,12346 anstatt einfach nur 0,12345 hinzuschreiben

Soweit richtig. Was dabei aber vergessen wird, ist denn die Berechnung (NICHT die Darstellung!) des Ergebnisses, also in diesem Fall die "Zahl" 0,1234567890 überhaupt "richtig"? Denn je nach Rundungsmodus/Einstellung Prozessor weicht das Ergebnis nach einigen Millionen Iterationen um Faktor X ab. Wenn jetzt nach diesen einigen Millionen Iterationen das Ergebnis bspw. 0,2345678901 lautet, dann ist es völlig unerheblich, ob diese Zahl dann "korrekt" auf 5 Stellen gerundet wurde.

Zitat von AspirinJunkie

und durch entsprechende Standardisierung auch einheitlich.

So muss das auch sein, aber wieso sieht die IEEE dann explizit 3 Rundungsmodi vor? Um doch genau die Freiheit zu geben, diesen "Fehler" (im System) geradezubiegen. Und zwar so, dass das Ergebnis zur Berechnung "passt".

Das eigentliche Problem ist systemimmanent bei Berechnungen im Binärsystem. "Flippe" ich das letzte Bit der Berechnung oder nicht? Halbe Bits gibt es keine....

Die von dir angesprochene "Standardisierung" sagt

Zitat

Statistisch wird dabei in 50 % der Fälle auf-, in den anderen 50 % der Fälle abgerundet,

aber laut der Anwendung dieser Statistik haben ein Millionär und ein armes Schwein jeder eine halbe Million!

Wenn die Raumfähre den Landeplatz auf dem Mars verfehlt, weil Europäer und Amerikaner unterschiedliche Maßsysteme verwenden, dann kann man darüber grinsen, aber wenn das passiert, weil bei der Auswahl des "Rundungsmodus" statt "Richtig" einfach nur "Standard" (in diesem Falle FALSCH, denn das Ziel wurde verfehlt) gesetzt wurde, dann werde ich nachdenklich.

Es kam schon öfter vor, dass ich diverse Algorithmen in ASM umgesetzt hatte und meine Ergebnisse (mit Standard-Einstellung) von denen diverser Compiler/Prozessoren abwichen. Bei der Analyse des Sourcecodes/Compilereinstellungen stellte ich dann fest, dass die Programmierer sehr wohl die unterschiedlichen Möglichkeiten bspw. beim Runden nutzen (in den Prozessoreinstellungen!) , um das Ergebnis an ihre Erwartungen anzupassen.

Bei Crosscompilern ist das auch bitter nötig, und wenn das nicht funktioniert, na dann wird eben ein "Emulator" benutzt, der die Berechnungen aka Ergebnisse "richtig" anpasst.

Um bei der Landefähre zu bleiben: Wird der Landeplatz auf dem Mars erreicht, weil bei der Berechnung alles "richtig" berechnet wurde, dann heißt das noch lange nicht, dass dieses System mit identischen Berechnungen zielgenau auf dem Jupiter (oder einem seiner Monde :o) ) landen würde....

"Standardisiert" ist immer nur so gut wie das damit erreichte Ergebnis.

Zitat von AspirinJunkie

Und der Grund warum diese sich in manchen Fällen scheinbar nicht auswirken liegt nicht in der Art der Speicherung wie sie in IEEE 754 definiert ist begründet sondern in der anschließenden Konvertierung der Zahl in einen String.

....was ja nichts weiter ist (wie von dir oben beschrieben) als ein "abschneiden" der restlichen Nachkommastellen.

Was aber das Rechenproblem mit dieser "Zahl" letztendlich auch nicht löst, weil der "normalo"-Programmierer davon ausgeht, dass die Rechenvorschrift ein "richtiges" Ergebnis liefert. Und da liegt das eigentliche Problem. Solange der Prozessor/Controller aka "Chip" auf der Platine die letzte(n) Stelle(n) (ich sag es jetzt mal provokant) nach "gutdünken" vergibt, wird sich daran auch nichts ändern!

Natürlich macht der Prozessor das, was ihm der Programmierer vorgibt. Aber um das das "richtige" Ergebnis einer Berechnung "vorherzusagen", reicht es eben nicht, freudestrahlend auf F5 zu hauen und davon auszugehen, dass "richtig" gerechnet wurde.

Denn den Prozessor "richtig" Rechnen zu lassen, hängt von den verschiedensten Faktoren ab. Runden (https://de.wikipedia.org/wiki/IEEE_754#Rundungen) oder das gerne verwendete (De)Normalisieren.

Da hat man dann schnell mal zwei Handvoll Möglichkeiten, "richtig" zu rechnen, aka "richtige" Ergebnisse zu erhalten.

Getoppt wird das alles noch, wenn man sich https://de.wikipedia.org/wiki/IEEE_754#…d_Quadratwurzel durchliest.

Zitat von Auszug aus Wikipedia

IEEE 754 verlangt von einer (Hardware- oder Software-)Implementierung exakt gerundete Ergebnisse für die Operationen Addition, Subtraktion, Multiplikation und Division zweier Operanden sowie der Operation Quadratwurzel eines Operanden. Das heißt, das ermittelte Ergebnis muss gleich demjenigen sein, das bei einer exakten Ausführung der entsprechenden Operation mit anschließender Rundung entsteht.

Aha. Wenn sich also alle Beteiligten auf EINE der "richtigen" Möglichkeiten einer Berechnung geeinigt haben, dann ist dieses Ergebnis "richtig"!

DAS muss man verstanden haben, damit der Satz des TE verständlich wird:

Zitat von Lanealine

Merkwürdiger Weise ist das Ergebnis davon anders als erwartet

"ERWARTET" ist nämlich das Stichwort.

Und das ist auch das, um was sich die IEEE 754 gelinde gesagt herumdrückt.

Das Ergebnis einer Rechenvorschrift ist genau DANN "richtig", wenn das (von wem auch immer) erwartete Ergebnis eintritt!

Ergo MUSS man im Vorfeld wissen, was das erwartete Ergebnis sein soll, um die (Prozessor/Software-)Einstellungen so vorzunehmen, dass auch genau dieses Ergebnis nach der Berechnung eintritt.

Was passiert, wenn man das NICHT tut, damit kann man Webseiten füllen....

https://www5.in.tum.de/~huckle/bugs.html

https://www5.in.tum.de/persons/huckle/bugse.html

Lanealine,

Programmieren heißt, den Code so "hinzubiegen", dass das vom Programmierer erwartete Ergebnis eintritt. Und möglichst alle Eventualitäten, die dieses erwartete Ergebnis verfälschen könnten, zu erkennen und programmiertechnisch im Vorfeld (!) zu beseitigen....

Da hilft nur, "wach" zu bleiben und regelmäßig (anderer Leute) "fehlerhaften" Code zu debuggen. Viel Spass dabei! Die "Fehler" (die ja nichts weiter sind, als "andere Erwartungen") so hinzubiegen, dass die "Erwartungen" erfüllt werden, ist die eigentliche Kunst!

Hi,

zunächst, was sind das denn für Textdateien mit welchen Einträgen, die von vielen "gleichzeitig" (24-Kernprozessor?!) gestarteten Prozessen abgearbeitet werden müssen?

Wenn ich sehe, dass du mit FileReadToArray($Textdatei) arbeitest, was ohnehin eine der langsamsten Autoitfunktionen ist, dann frage ich mich ernsthaft, ob es nicht Sinn machen würde, dein PROBLEM zu schildern, statt an einer von dir vermuteten (!) "guten" Lösungsmöglichkeit rumzudoktoren!

Stichwort X-Y-Problem!

Mit mehreren Prozessen eine Datei zu bearbeiten macht nur dann wirklich Sinn, wenn ausreichend Prozessorkerne mit eigenem (großen) Cache bzw. Speicher zur Verfügung stehen.

Wenn obige Scripte auf einem bspw. Vierkernprozessor mit angenommen 12 "Threads" (Programmstarts) abgewickelt werden sollen, dann dauert das idR länger, als nur mit 4 Programmstarts. Windows nimmt dem laufenden Thread sowieso über die Zeitscheiben seine Arbeit weg um die anderen Threads zu bedienen. Wenn man das auf die Spitze treibt und 200 "Threads" startet, dann bleibt der Rechner stehen, weil Windows mehr mit der Verwaltung der Threads zu tun hat, als Zeit für das "Problem" zur Verfügung zu stellen!

Zitat von water

BTW: Ein Tool zum Servermonitoring sollte eine Schnittstelle für Alarmierungen bereits mit anbieten. Wäre sicher der verlässlichere Weg!

"Sollte" ist das Stichwort...

Ich arbeite täglich mit webbasiertem Monitoring für Produktionsmaschinen/Mitarbeiterarbeitsplätzen. Da gibt es NICHTS, was nicht explizit seitens Softwarehersteller vorgesehen ist, alternativ "nachgepflegt/programmiert" worden ist. Manche Dinge sind nicht einmal vorgesehen, da seitens Programmierer dieser Fall/Fälle infolge mangelnder Fachkenntnis (die sind schliesslich Programmierer und keine Anwender! ) nie den Weg in die Software gefunden haben noch finden werden.

Zitat von Wikipedia

AutoIt ist eine Software zum Ausführen von Skripten, mit denen hauptsächlich Abläufe unter Microsoft Windows automatisiert werden können,

...genau DAFÜR ist es da! Um nicht vorhandene Funktionen/Abläufe "nachzubilden", die es sonst nicht gegeben hätte!

Zitat von Xorianator

Nächstes Jahr sollte aber klappen, da können wir - im besten Falle - auch auf den ersten Abschluss ein paar Bierchen zischen

Na dann....hau rein, damit wir auch wirklich was zu feiern haben

*push*

Zitat von alpines

RegEx ist praktisch das Schweizer Taschenmesser für Stringverarbeitung.

Stimmt so schon, aber man MUSS es nicht benutzen, nur weil es da ist. Sämtliche Werkzeuge, die in einem Schweizer Taschenmesser vorhanden sind, gibt es wesentlich komfortabler, einfacher, besser und schneller auch in "Normalform".

Ich kenne niemanden, der in seinem Werkzeugkasten ein Schweizer Taschenmesser liegen hat, um damit zu sägen, bohren, schneiden uswusf.

Das Universaltool nutzt man genau dann, wenn die anderen Werkzeuge gerade nicht zur Hand sind!

Ich postuliere mal, dass >90% aller "Stringaufgaben" (gerade bei Anfängern) mit den einfachen Stringbefehlen hinzubekommen sind.

Der Vorteil ist, dass man diese auch in Fällen wie

Zitat von Lottich

Nachtrag: hoffentlich merke ich mir das auch. So oft brauch ich RegEx nicht...

diesem noch halbwegs verständlich nachvollziehen kann, was gerade passiert.

RegExe (vor allem die anderer Leute) zu debuggen ist hohe Kunst, wirklich "machen" tut das keiner gerne

Ich zumindest nutze RegExe dann, wenn der Aufwand, ein String"problem" abzuwickeln, mit den Standard-Stringfunktionen deutlich aufwendiger abzuwickeln wäre, bzw. es per Regex deutlich einfacher (auch zu debuggen) ist.

Wobei ich persönlich auch keine Skrupel habe, unterschiedlichste RegEx- und Stringfunktionen so zu mischen, dass es passt. Nirgendwo steht geschrieben, dass RegExe Einzeiler sein müssen, obwohl viele "Profis" das so verstehen (wollen). Je komplizierter RegExe aussehen, desto größer ist ja immerhin der WOW-Effekt bei den "Anfängern"

Zitat von Lottich

Wie muss das Pattern aussehen, damit ich auch (optional) mehrere Dateiendungen finde?

Ich nutze (fast immer) https://regex101.com um mir meine RegExe zusammenzustricken. Wenn man mal begriffen hat, wie RegEx funktioniert, dann stöbert man auch mal in den "References" unten rechts, um die eine oder andere Erleuchtung zu bekommen.

Zitat von DDiSoEsT

Ich verstehe nicht genau, wie ich das mit Pixelsearch umsetzen soll, damit muss ich die bilder soch immer öffnen oder wie muss ich das verwenden?

Pixelsearch() als Autoit-Funktion sollst du gar nicht verwenden, ich hatte nur aufgezeigt, wie Pixelsearch "intern" funktioniert und wie man diese Funktionalität nutzen kann....

Natürlich musst du die Bilder öffnen (was allerdings NICHTS mit dem Anzeigen auf dem Bildschirm zu tun hat! ), allerdings besteht ein Geschwindigkeitstechnisch himmelweiter Unterschied, ob du einzelne Pixeldaten per GDI(+)-Funktion in einer AutoItschleife suchst, oder diese Arbeit einer höchstoptimierten "internen" Funktion wie bspw. StringInstr() überlässt.

Weitere Informationen, wie das funktioniert, findet man u.a. HIER

s. auch den gespoilerten Abschnitt "Suche vom Bild im Bild". Übrigens benötigt man die damals von mir verwendete "prospeed.dll" nicht unbedingt, auf heutigen Maschinen ist selbst die 1000x langsamere AutoIt-Version schnell genug^^

Zitat von DDiSoEsT

Im Moment benötige ich ca. 12 Sek pro Block, was beschränkt auf etwa 16 Lukrative Blöcke ein delay delta von maximal ~ 3min ergibt..

Zeig mal, was du bisher hast, damit man mal konkret "Hilfe" leisten kann...

Zitat von DDiSoEsT

Muss irgendwie aus diesen Daten, die ich ausgespuckt bekomme erschließen können ob diese gefundenen Pixel zwei Sitzplätze nebeneinander darstellen.. LG

Aus den bisherigen spärlichen Infos "Stadion" schließe ich, dass die Bilder der "Blöcke", also die Sitzplatzpositionen immer gleich sind?

Die Koordinaten des Pixels passend zum ersten Platz in der obersten Reihe zu finden, sollte klar sein! Der Abstand von Sitzplatz zu Sitzplatz ist auch klar definiert...

Da muss man ehrlich gesagt kein Genie sein, um anhand der Koordinaten eines beliebigen Pixels auf die entsprechende Reihe und Spalte im "Block" zu kommen. Zwei Zahlen miteinander zu multiplizieren bzw. zu dividieren, sollte jeder hinbekommen.

Btw,, wenn es ausschliesslich um benachbarte Plätze geht, dann wäre ein klassisches "Pixelsearch" am allereinfachsten.

Ohne jegliches Gedöns mit GDI(+)! Und auch ohne "Pixelsearch()" übrigens...

Was macht Pixelsearch? Ein "String", in diesem Fall die Bilddaten aka "Pixel" werden in den Speicher geladen. Zugriff erhält man über einen Pointer auf diese Daten, Länge ist bekannt, Bidgröße in Pixel mal vier (Bytes pro Pixel)

Legt man "über" diese Daten eine char-Struct, kann man einfachst den String auslesen und beliebige Sequenzen per StringInstr() in Mikrosekunden finden.

Die Koordinaten der gefundenen Position sind zu ermitteln und anhand derer ggf. per LUT (LookUpTabelle) den Sitzplatznamen.

Bei Verwendung von _GDIPlus_BitmapGetPixel() in "langen" Schleifen, bzw. um komplette Bilder zu durchsuchen wird mir immer ganz schlecht....

Hi,

ich würde, um das Problem schnell zu lösen, zunächst die Breite und Höhe in Pixeln eines (des oberen linken) "Sitzplatzes" bestimmen. Es wird im Bild ein Rechteck gesucht. Dieses ist dadurch bestimmt, dass die obere linke "Ecke" schwarz (oder wenn besetzt blau), und deren beiden Nachbarpixel unten und rechts auch schwarz ist. Das Pixel links und oben ist nicht schwarz.

Jetzt hangelt man sich Pixel für Pixel nach rechts und unten, bis die rechte untere "Ecke" gefunden wurde.

Somit ist das oberste linke Rechteck gefunden, incl. Koordinaten seiner 4 "Ecken".

Von der Ecke unten rechts läuft man nun nach unten und nach rechts, so erhält man den Abstand zum nächsten Rechteck in der Reihe und Spalte.

Und somit den Abstand zum nächsten Sitzplatz waagrecht und senkrecht. Die Sitzplatznummer erhält man "nebenbei" auch noch...

Jetzt sind die Koordinaten des ersten Sitzplatzes und der Abstand zum nächsten Platz rechts und unten bekannt.

Somit reduziert sich die weitere "Suche" auf Ablaufen von einer Handvoll Koordinaten.

Wenn alle Bilder "gleiche" Auflösung bzw. gleichen Reihen- und Spaltenabstand haben, reicht es, die "Suche" genau ein mal durchzuführen und die Koordinaten/Abstände des ersten Sitzplatzes je Bild abzuspeichern.

Dann reduziert sich die Frage nach benachbarten Sitzplätzen auf eine Abfrage von (im Beispielbild) ca. 30x15, also 450 Pixeln.

Das schafft selbst AutoIt per GDI in einigen Millisekunden, bei 127 Bildern also in etwa 2-3 Sekunden.

Ich frage mich nur gerade, wozu man ein Script schreiben will, um in 127 Kinos/Theatern nebeneinander liegende Sitzplätze herauszufinden...

Zitat von UEZ

Soweit ich mich erinnern kann, haben wir bereits 2 Jahre hintereinander ausfallen lassen.

...war mir auch aufgefallen, nachdem ich den Post abgeschickt hatte

Naja, ein Grund mehr, in diesem Jahr hinzufahren.

Hmmm, die in UEZ´s Post verlinkte Funktion läuft auf modernen INTEL-Chips nicht, ich vermute ein Überlauf-Problem, da hatten AMD-Systeme immer recht liberal reagiert^^

Ich werde diese Funktion mal "modernisieren" und ggf nach SSE portieren. Oder jemand schreibt in einer der Compilersprachen eine DLL / Funktion.

Hi zusammen,

die REVISION 2019 steht am Ostersonntag an, wie in jedem Jahr.

Das letzte Jahr hatten UEZ und ich ausfallen lassen, aber in den Jahren davor hatten wir mit einigen hier aus dem Forum einen super Sonntag!

Nachlesethread mit Bildern

Wer hätte Interesse in diesem Jahr, ich könnte auf dem Weg dorthin aus dem Osten ggf. (2) Leute aufsammeln und hätte auch eine bescheidene Übernachtungsmöglichkeit im Rhein-Main-Gebiet, ggf. könnte man aber auch eine Pension/Hotel organisieren.

Zitat von Musashi

Da ich das Ganze aktuell eher als 'Nebenkriegsschauplatz' plane, wird es wohl auf PureBasic hinauslaufen. Die Option 'SpiderBasic' (gleicher Hersteller - Code weitgehend übertragbar) ist auch verlockend, selbst wenn ich sie (noch ?) nicht benötige.

Da bin ich 100%ig bei dir! Wir (beide konkret als Person) sind in der glücklichen Lage, uns zu überlegen, welche 3 Features wir bei dem Kauf unseres nächsten Schweizer Taschenmessers zusätzlich zu den 658 bereits enthaltenen Gadgeds (die wir größtenteils garnicht benutzen :o) ) mitbestellen sollen....

Aktuell bekommt man Software mit geradezu gigantischen Möglichkeiten quasi hinterhergeschmissen.

SpiderBasic hat mich aufgrund der "optischen Eigenschaften" des Codes angelacht....Sieht aus "wie früher"...und ist Crossplatformfähig. Über Webinterface läuft der Code auch auf nahezu jedem Gerät...all das, was JAVA sich mal aufs Butterbrot geschmiert hatte und nicht umsetzen konnte...

Scroll mal bei Rosettacode eine beliebige Seite durch. Bei 90% der Sprachen, Leistungsfähigkeit hin oder her, SIEHT DER CODE SCHON SCHEI*E AUS! Und trotzdem wird damit gearbeitet und die Sprache wurde sogar

Zitat von BugFix

Ich kann dir eine recht junge Sprache anbieten:

NEU entwickelt....

....Purebasic....

Zitat von Musashi

Nebenfrage an Andy : "Siehst Du das immer noch so ?"

Ja.

Zitat von Tuxedo

Ich finde eine sehr gute Sprache fehlt noch in deiner Liste: PowerBasic

Hatte ich mir damals bei Release (muss wohl so Ende 80er gewesen sein) für den IBM-XT geleistet. Als Schüler bin ich ein Jahr lang an jedem Ferientag arbeiten gegangen, um mir diese Kiste zu leisten. Das GW-Basic im ROM konnte nicht mal ansatzweise gegen PowerBasic anstinken. Da auch ein Inline-Assembler drinsteckte, führte kein Weg an einem Kauf vorbei^^

Aber imho hat PB die besten Jahre (weit) hinter sich, die damit programmierbaren "Forms" aus ASCII-Grafikzeichen locken keinen mehr hinter dem Ofen hervor. Logisch kann man die gesamte WinAPI ansprechen, aber das kann ich mit anderen Sprachen auch. Die Frage ist, ob man das überhaupt antun muss...Wir sind von AutoIt ziemlich verwöhnt, was arbeitserleichternde Funktionen betrifft.

btt :o)

Hier als Rundumschlag https://de.wikipedia.org/wiki/Liste_der_BASIC-Dialekte

Dort findet man sehr interessante Sachen wie bspw. webbasierte Basic-Dialekte , SpiderBasic fand ich schick https://www.spiderbasic.com/showcase/onlineviewer/

Und Basic für u.a. Android hat doch auch was^^

Zitat von Musashi

Erfreulich zu sehen, dass das Gedächtnis bei jüngeren Leuten noch so gut funktioniert

Hehe :o), werd du erst mal so alt, wie ich aussehe

Zitat von Musashi

Für eine eigene XOR Funktion solltest Du kürzere Binärstrings linksseitig mit Nullen auffüllen (auf die Länge des 'längsten' Binärstrings). Ob Du die Verknüpfung dann blockweise machst oder Bit für Bit, ist Dir überlassen.

Da das hier ja ein Programmier(er)forum ist, sollte der geneigte "User" eine Funktion erstellen und diese dann hier posten, so dass man sie in die BigNum.UDF übernehmen kann.

Wie gesagt, eine "kleinere" Programmierübung. Das sollte auch ein Anfänger schaffen.

Naja,

das ist für einen Programmieranfänger doch nur eine Fleißaufgabe.

Eine beliebig große Anzahl "Ziffern" ins entsprechende Binärformat bzw Hex umwandeln, und "blockweise" 64Bit wie gehabt XORen. Imho hatten wir das unlängst sogar hier im Forum.

Suche (schnelle) Funktion zum Umrechnen ins Dual- oder Hexadezimalsystem

hups...."unlängst"....5 Jahre her, aber trotz meines biblischen Alters habe ich mich noch dran erinnert^^

Link zum Post mit einem letztendlich schnellen Script: Suche (schnelle) Funktion zum Umrechnen ins Dual- oder Hexadezimalsystem

Hi Alina,

Zitat von Alina

Habe ich da etwas den Sinn verpasst oder den Durchblick nicht gefunden?

im dänischen Wiki wird das Thema SEHR kurz behandelt^^ https://da.wikipedia.org/wiki/Huffman-kodning

Das deutsche und englische Wiki behandeln das Thema sehr ausführlich. (Link im Startpost)

Zitat von Alina

Also statt , 0, 0, 0, 0, hab ich , 29, 2, 19, 50, genommen und es wurde einwandfrei codiert und decodiert.

was auch nicht wundert, diese Zeichen werden im Text nämlich gar nicht verwendet...

In einer Huffman-Tabelle befinden sich 255 Werte aus "binären Bäumen" , jeder entspricht einem ASCII-Zeichen. Im "richtigen" ASCII-Zeichensatz wird jedes Zeichen mit jeweils 8 Bit "kodiert", die ASCII-Codetabelle findest du überall, die hat jeder Programmierer unter dem Kopfkissen liegen^^ (auch in der AutoIt-Hilfe im Appendix)

Der Sinn der Huffman-Kodierung ist, die am häufigsten vorkommenden Zeichen mit viel weniger als 8 Bit darzustellen. Stell dir einen binären Baum vor (ansonsten schau ins Wiki, da ist einer abgebildet), Die "Blätter" des Baums werden jetzt durch 1- und 0 "Zweige" beschrieben. Nach links gehts bei jedem Abzweig zur 1, nach rechts ist eine 0. Am "Ende" jeden Zweigs hast du dann eine Bitfolge, "oben" im Baum wenige Bits, unten viele Bits. Wenn du jetzt an jedes "Ende" eines Zweigs einen Buchstaben schreibst, dann entspricht dieser Buchstabe der Bitfolge bis da hin. Soweit klar?

Im Beispiel im Wiki entspricht der Buchstabe "a" dem Bitcode 1, "b" entspricht 01, "c" 001, "d" 000

"abcd" würde also entsprechen 101001000, also insgesamt 9 Bit. In ASCII- "Kodierung" wäre "abcd" aber 4*8Bit=32Bit lang!

Mit der Huffman-Kodierung hättest du somit 23 Bit gespart! Oder nur 28% an Daten!

Diese Komprimierung wird unter anderem auch bei JPEG, also Komprimierung von "Farben" in Bildern verwendet.

Wenn du also die "Wege" im Baum zum Buchstaben veränderst ohne zu wissen was du da tust, veränderst du die KODIERUNG, was an sich kein Problem darstellt...

Da dieser "Baum" aber auch zur DEKODIERUNG benutzt wird, hast du ggf. mit deinen " zufälligen" Werten die Wege zu Buchstaben beschrieben, die aber im Baum eventuell (sicher) gar nicht an dieser Stelle, oder genauso schlimm, doppelt existieren!

Im Script von Mars entspricht das Array $__AHE_aHistDefault[$i] aber nicht einer Huffman-Tabelle, sondern einer Wahrscheinlichkeitsverteilung (ähnlich einem Histogramm in einem Bildbearbeitungsprogramm).

Ändere die beiden 25 in der Tabelle auf bspw. 2555(willkürlich sehr hoch gewählt) . Dann ändert sich die Anzahl der Bits pro Char von 5,14 auf 5,10. Also eine Verbesserung. Aber nur für DIESEN Beispiel-Text!

Die Frage ist ja, mit welcher Tabelle deckt man "am wahrscheinlichsten" möglichst viele Texte ab.

Dann müsste man den Huffman-Baum nicht jedes Mal neu aufbauen (Anhand der Häufigkeit der Buchstaben) , sondern könnte eine "Universaltabelle" benutzen....

Aber da der Sinn einer "optimalen" Komprimierung darin besteht, IMMER den kleinst mögliche Größe zu erhalten, egal welche Daten vorliegen, MUSS für eine "optimale" Komprimierung die Tabelle immer neu aufgebaut werden.

Zitat von Mars

Mit dem Internet stimmt wirklich etwas nicht. Ich wollte mir letztens einen Stream auf YT ansehen, der hat furchtbar gehackt ist andauernd stehengeblieben und konnte nur via F5 wieder für ein paar Sekunden am laufen gehalten werden. Dieses Totalversagen schiebe ich aber auf die Software. Meine Leitung hat einen Ping von ca. 25ms und kann ca. 5MB/s (wenn sie gute Laune hat), ich erwarte dass ein Stream damit flüssig läuft

"Normales" Internet?! Schnell?! Träumt alle mal weiter...

Die Deutsche Börse (und auch andere Börsen weltweit) hat gerade erst ein "Tempolimit" für den Aktienhandel eingeführt, welches den Händlern eine Zeitbeschränkung von mindestens einer TAUSENSTEL Sekunde ermöglicht, innerhalb dessen sie kaufen/verkaufen können, ohne das das Handelsobjekt von sog. Hochfrequenzhändlern "weggeschnappt" wird.

Da geht es um Mikrosekunden für die komplette Transaktion über zigtausend Kilometer, und du bist happy mit einem PING (*rofl*) von 25 ms. Bin mal gespannt auf deine Methode, diesen "Ping" zu MESSEN. Ja MESSEN. Anzeigen lassen kann man sich nämlich viel....

Das "Internet" ist imho nur die sichtbare Spitze des Eisbergs. Da wird ein bissl rumgepickelt um den Anwendern mit YT/Facebook/Twitter/Streaming uswusf einige Brocken vorzuwerfen, die dankbar angenommen werden. Die "real" verfügbare Technik bleibt anderen vorbehalten, wer will das den Providern auch verdenken? Wenn DU mit Technik richtig viel Geld verdienen kannst, wieso sollst du dich um Leute kümmern, die 99% ihrer "Online"-Zeit mit hochgradig geistigem Dünnschiss verplempern? Und diese "Leistung" dann auch noch möglichst "umsonst" haben wollen?

Da wird nach "Leistung" gequiekt und "schnellem" Internet. Mal angenommen, in Deutschland bestünden 80 Millionen Internetanschlüsse, und jeder würde im Monat 100€ Kosten. Das sind zusammen gerade mal 8 Milliarden. Im Vergleich zu den BILLIONEN, die "nur" allein die Deutsche Börse mit "schnellem" Handel in diesem Zeitraum umsetzt, ist das NICHTS!

Überzeuge doch einfach deine 80 Millionen Mitinternetbenutzer, im Monat 1000€ für eine "schnelle" Leitung zu bezahlen, und das Geschwindigkeitsproblem ist sofort gelöst.

Oder sollte nach diesem Vorschlag etwa rauskommen, dass die Nutzer für den Müll, den sie über die Leitung jagen, eigentlich gar kein "schnelles" und schon gar nicht kein "kostenloses" Internet brauchen/wollen?!

Oder ist es etwa so, dass es dieses "schnelle" Internet bereits gibt, aber es kaum nachgefragt wird, weil es Geld kostet?

Btw. hatte ich schon mal erwähnt, dass ich in keinem der sog. "Social-Media"-Dienste angemeldet bin? Und mir daher eine "langsame" aber stabile Internetleitung für meine Anwendungen (ja, auch Onlinezocken incl. TS ab und zu) völlig ausreicht?! Und ich trotzdem noch zufrieden lebe?