Beiträge von Mars

    Ich kann hier nur über meine persönliche Meinung dazu sprechen (mögen andere mich korrigieren).

    Ich halte AdlibRegister für weitestgehend nutzlos. Eine (meiner Meinung nach) bessere Methode sind Funktionen mit Static Timer, da diese an einem Ort ausgeführt werden den "ich" festlege, während AdlibRegister Funktionen "überall" aufgerufen werden können und den Programmablauf damit durcheinanderbringen (außer man hat seine Programmstruktur extra darauf ausgelegt).


    Beispiel:

    Man kann diese Funktionalität auch Wrappen, sodass man z.B. eine Funktion hat die "SetTimer($xFunc, $ms)" hat, usw.


    Wenn du nicht willst, dass der Nutzer davon etwas mitbekommt musst du dafür sorgen, dass die Abfragen einzeln relativ schnell durchlaufen, dann kannst du im Mainloop z.B. immer ein paar Millisekunden zur Verfügung stellen um Abfragen abzuarbeiten. Sind diese Millisekunden aufgebraucht werden die restlichen Abfragen erst im nächsten Schleifendurchlauf angegangen. Sowas lässt sich mittels Queue + Timer regeln (z.B. Alle 5 Sekunden sollen 100 Abfragen gemacht werden, dann werden alle 5 Sekunden die 100 Abfragen in den Queue gesteckt (das geht sehr schnell), und in jedem Schleifendurchlauf werden ?? Millisekunden lang Abfragen bearbeitet bis der Queue leer ist. Da muss man aber aufpassen wenn Abfragen aus welchem Grund auch immer nicht abgearbeitet werden können, dann wird der Queue immer länger und das wollen wir ja nicht).


    lg

    M

    Plottest du das direkt aus AutoIt heraus? Falls ja - wie?

    Da muss ich dich direkt vorwarnen, das folgende ist keine UDF die es in die Öffentlichkeit geschafft hat. Sie ist in keinem guten Zustand und jedes Mal, wenn ich etwas plotten will baue ich genau die funktion die ich gerade brauche ein^^

    Die Funktion gibt es eigentlich nur, weil ich im Stil von _ArrayDisplay "schnell und einfach" eine Funktion haben wollte um Arrays anzusehen. Es gibt (auch hier im Forum) UDFs die Daten plotten können, ich schätze, wenn man es ernsthaft angeht sollte man mit so einer UDF eine Anzeige basteln...


    lg

    M

    Was ich in der SB gepostet hatte: https://imgur.com/a/wrzZjAa


    Die Version hier (nach einigen kleinen Anpassungen) funktioniert schonmal deutlich besser. Peaks in den angeschauten Frequenzen sind sauber, deutlich und ohne übertriebenes Überschwingen.


    Inputdaten (mit dem bloßen Auge erkennt man hier höchstens, dass da "irgendwas schnell schwingt", die 2te Schwingung sieht man selbst mit scharfem Blick nicht):


    amplitude der DFT (angepasst, sodass man über Frequenzbereiche gezielt drüberlaufen kann, wobei "eine Arraylänge" immer 2PI entspricht)

    (die X-Achse ist etwas doof beschriftet, der erste Peak ist NICHT bei 0.85, sondern tatsächlich etwa bei 1.0, also da wo er hingehört)


    Danke nochmal für die Hilfe :thumbup:


    lg

    M

    Achso, ich glaube ich habe den Unterschied zwischen FT und DFT immernoch nicht verstanden.

    Was ich dachte ist folgendes: Die Abtastfrequenz gibt an welche Frequenzen im Array überprüft werden, also dass ich z.B. soetwas wie "alle Frequenzen von 0 bis 5 in 0.1er Schritten" ablaufen kann. Vermutlich ergibt das im Grenzwert wieder eine kontinuierliche FT. Das muss ich wohl nachlesen :/


    Ein Glück, dass ich mit Signalverarbeitung nichts am Hut habe, sonst hätte man mich für so viel Blödheit bestimmt schon verprügelt :part:


    lg

    M

    Vielen Dank, jetzt wo ich die Lösung sehe, sehe ich auch meine Fehler :D

    Mit der Abtastfrequenz kann aber etwas nicht stimmen (glaube ich). Die taucht im Code nur bei "$aRet[$k][$eFrequency] = $k * $nFs / $N" auf, hat aber keinen Einfluss auf die anderen Werte (oder ich habe da etwas missverstanden, was auch gut sein kann).


    lg

    M

    Eine Idee:


    Es gibt ja einige CSS/JS Tricks mit denen man das Erscheinungsbild nahezu jeder Webseite ändern kann (Stylish, Greasemonkey, CSS-Injector, etc. Es gibt hunderte Wege nach Rom). Damit habe ich ausprobiert die Cookiepopups einfach garnicht erst anzeigen zu lassen, das ging nicht so gut wie erwartet... Einige Webseiten führen nach Betätigung des Popups ein Skript aus um die Webseite freizuschalten, wenn man das Popup garnicht erst bekommt bleibt die Seite unbenutzbar.


    Soweit ich weiß ist es laut Gesetz verpflichtend, dass der Nutzer zustimmt BEVOR die Cookies benutzt werden dürfen. Wenn man also eine Möglichkeit findet die Popups zu killen und gleichzeitig die Webseite zu aktivieren, hätte man es geschafft. Vermutlich ist das via CSS + JS (das Popup ist in der Lage die Webseite freizuschalten, mit JS muss das Clientseitig dementsprechend auch gehen) möglich. Vermutlich muss man für jeden Popuptyp/jede Webseite ein eigenes Skript und eigenes CSS basteln (und das auch häufig aktualisieren, die wollen ja deine Daten, also ändern die andauernd irgendwelche Kleinigkeiten).


    Da mein Wissen im Bereich HTML und CSS aber nur ganz knapp über NULL ist, habe ich nach 30 Minuten im Inspektor (Firefoxtool um Webseitencode einzusehen) aufgegeben. Jemand der sich hier auskennt sollte das aber hinbekommen.


    Edit: uBlock Origin hat einen Filter für Cookie-Banner unter Einstellungen -> Filterlisten -> Belästigungen -> "EasyList Cookie". Ob das hilft weiß ich nicht, hab es mal aktiviert und lasse mich überraschen.

    Edit2: Das Addon "idontcareaboutcookies" nimmt scheinbar automatisch alle cookies an. Ich verstehe nicht wieso dieses Addon so populär und gleichzeitig so fehlgeleitet sein kann.


    lg

    M

    Eine "nicht sicherere" Methode um Text zu verschlüsseln habe ich irgendwann auch mal gebastelt. Der Code ist sogar Kommentiert, da hatte ich wohl zu viel Freizeit :rofl:


    Prinzip ist:

    1. Starte einen RNG (hier XORShift) und generiere damit ein "one time pad" (eigentlich ist es ja keins, weil die Zahlen nicht "zufällig" sind)

    2. Modifiziere den RNG andauernd mit einzelnen Buchstaben aus dem PW, sodass jedes PW ein einzigartiges OTP erzeugt.

    2.5. Lasse das OTP (+Modifikationen) noch ein paar mal durch den RNG laufen damit sich einzelne Änderungen (z.B. nur 1 Buchstabe im PW) besser auf das gesamte OTP verteilen.

    3. XOR mit dem OTP


    Vorteile:

    - Extrem einfach.

    - Vorallem in anderen Programmiersprachen unfassbar schnell (es sind hier nur Shift, XOR und Additionen im inner Loop)

    - Da XORShift ziemlich gleichverteilt läuft sind auch die verschlüsselten Strings ziemlich gleichverteilt.

    - Das Verfahren ist zum ver- und entschlüsseln identisch.


    Nachteile:

    - Jeder mit 5 Minuten Ahnung im Bereich Programmierung kann die Verschlüsselung knacken.

    - In AutoIt nicht so schnell, als dass man damit größere Dateien verschlüsseln kann.


    lg

    M

    Aber warum sollte das so einfach sein? :Face:

    Das musst du nicht uns fragen, sondern die Jungs im EN-Forum :D

    [rant] Wenn man die vielen Ideen (um AutoIt zu verbessern) aus dem Forum mal alle sammeln und auflisten würde, hätte man sicherlich locker 3 Seiten "Stichpunkte" (1Idee/Zeile). Mein aktueller Favorit ist ByRef im selben Scope, also z.B. Local $a = Byref $b, wenn ich $a ändere, ändert sich auch $b und umgekehrt. Das geht aktuell nur via ByRef im Funktionsaufruf. Benutzen könnte man das um verschachtelte Arrays effizient zu handhaben, LinkedLists (oder quasi "alle" Datenstrukturen die Pointer verwenden) zu basteln, etc. etc. Mal gucken was nächstes Jahr mein Favorit bei "missing features" ist^^ [/rant]

    M

    4 Hinweise:


    1. AutoIt führt Zeilen beim ersten Mal etwas langsamer aus (außer das wurde inzwischen geändert). Das heißt wenn du eine Funktion das erste Mal aufrufst ist sie langsamer als alle weiteren Male. Was dich eigentlich interessiert ist die durchschnittliche Geschwindigkeit mit der die Funktion läuft, und nicht die Zeit die sie beim ersten Mal braucht.


    2. Je nachdem was dein PC gerade macht (der macht immer irgendetwas, z.B. Windows laufen lassen, Festplatte lesen, etc.) läuft AutoIt manchmal sehr unterschiedlich schnell (es "ruckelt" dann im Interpreter). Einzelne Messergebnisse sind also nicht aussagekräftig.


    3. (klingt komisch, ist aber so): Die Reihenfolge in der Code aufgerufen wird bewirkt einen kleinen Geschwindigkeitsunterschied (manchmal vernachlässigbar klein, manchmal größer, ich habe leider kein Beispiel, das ist nur eine Beobachtung von mir als ich ziemlich viele Funktionen auf Geschwindigkeit überprüft habe).

    4. Seit Windows 10 Update XYZ (ich weiß nicht welches) ist das ausführen von PostMessageA extrem verlangsamt (wird Intern im Interpreter verwendet). Der Interpreter wird langsamer, falls vorher schonmal ein Windows-Fenster erzeugt wurde (z.B. ArrayDisplay, MsgBox, etc). Das wurde zwar in AutoIt "gefixt" (indem nur noch alle X Interpreterschritte PostMessageA aufgerufen wird), hat aber trotzdem eine kleine Auswirkung. Daher: Verwende beim Zeitmessen niemals irgendwelche Fenster als Ausgabe, sondern lieber die Konsole.


    Am Besten ist es, wenn du beide Funktionen in zufälliger Reihenfolge aufrufst und die Messwerte z.B. in ein Array mit N Einträgen einträgst. Der Median davon entspricht in etwa dem durchschnittlichen Messwert. (Median deshalb, damit Ausreißer abgefangen werden, ein einfacher Mittelwert kann durch einen einzigen "ruckler" komplett kaputtgemacht werden).

    PS: Ich habe das Skript nicht getestet, sondern nur kurz angeschaut.


    lg

    M

    Bei einer Verschlüsselung kommt es darauf an, dass der verschlüsselte Text gleichverteiltem Rauschen entspricht (je weniger der Text von Rauschen unterscheidbar ist, desto schwieriger ist es Muster zu erkennen). Außerdem ist wichtig, dass sich das entstehende Rauschen nicht ähnelt, selbst wenn man im Passwort nur ein Bit dreht. Ich bin kein Experte auf dem Gebiet, aber ich glaube eine Verteilung wo die allermeisten Zeichen nur 1x vorkommen ist nicht mehr "gleichverteilt" (in einer Gleichverteilung kommt es ja statistisch zu vielen Abweichungen, Wenn du 6x würfelst bekommst du ziemlich wahrscheinlich nicht 1, 2, 3, 4, 5, 6 heraus, sondern irgendwelche Zahlen doppelt oder sogar dreifach, und das waren jetzt nur 6 Würfe und nicht wie bei ca. 100) und daher vermutlich ungeeignet für "gute" Verschlüsselung.

    Aber ich kenne mich da nicht gut aus, da weiß jemand anderes bestimmt mehr^^

    Andy war wahrscheinlich verhindert, vielleicht kommt von ihm später noch etwas :)

    Der Trick an der Sache war bei mir das Finetuning (was aber eigentlich auch Informationen über den zu Komprimierenden Inhalt braucht, also die eingestellten Parameter funktionieren gut für deutschen Text, aber vermutlich nicht so gut für andere Sachen).

    z.B. Wie stark wird das Histogramm geboostet? (1 Parameter)

    z.B. Wird der boost im Verlauf der Kodierung stärker oder schwäche (1 Parameter)

    z.B. Wie arbeitet der Predictor intern? (2 Parameter (lässt sich zusammenfassen als Verhältnis))

    z.B. Wie stark wird das Histogramm aktualisiert nachdem dein Zeichen dekodiert wurde? (1 Parameter)

    Ich habe insgesamt 4 Magic Numbers die alle für gewisse Einstellungen verantwortlich sind. Die kann man auch so einstellen, dass der Text 5% schlechter Komprimiert wird und genaugenommen müsste ich diese Werte (die man quasi bruteforcen muss) mit in den kodierten String stecken was nochmal ca. 40 Bit braucht. Da ich aber ohnehin schon so knapp an den 50% war wollte ich das einfach nicht machen... Wenn man das berücksichtigt bin ich quasi gleichauf mit AspirinJunkie (nur noch ein paar Bytes besser), wobei sein Skript 50x schneller ist :D

    Ohje, wenn Andy die 50 geknackt hat muss ich wohl nochmal schrauben :rofl:

    Ich hatte einfach keine Lust auf alt bewährtes zurückzugreifen und hab meine Idee (Prediction geboosteter dynamischer Huffman Tree) weiterverfolgt. Leider hat das eine entscheidende Schwäche: Ganze Bits.


    Egal wie gut die Vorhersage ist, im Regelfall kann man 3 Bit/Symbol nicht unterschreiten, da im Huffman-Tree, genauso wie bei Telefonnummern keine vollständigen 01-Ketten existieren dürfen die gleichzeitig der Anfang einer anderen Kette sind. Wenn es also eine 2Bit Kette gibt (z.B. "01"), dann kann es keine einzige weitere Kette geben die mit "01" beginnt. Der Tree wird "optimal" erstellt, und wird den Teufel tun, bei sämtliche anderen Zeichen die Bitketten um 1 zu verlängern, nur weil die Chance für ein "a" als nächstes Zeichen 20% ist (das wäre aber nötig um unter die 3Bit/Symbol zu kommen).


    Der Ansatz ist super, rennt aber bei Huffman komplett gegen die Wand...

    Nächste Idee ist dann: Prediction geboosteter arithmetischer Kodierer. Der sollte mindestens 10%-20% besser klarkommen (damit sollte auch 60% bei Text kein Problem sein).

    Ich hab etwa 2000 Zeilen Spaghetticode fabriziert der zu allem Überfluss auch noch ganz besonders langsam ist und nicht die Kompression erreicht die ich gerne hätte^^

    Werde das irgendwann Morgen abgeben, viel Spaß beim Durchlesen Oscar:rofl:


    PS: Nächstes Mal wird die 50% in Angriff genommen. Das ist zwar noch ein paar Meter, aber das schaffen wir ^^

    Je nachdem wie man das Verfahren nennen möchte. Manchmal heißt es auch Radix-Sort.
    Das ist übrigens in fast allen Fällen die mit großem Abstand schnellste Sortiermethode, sofern man eine gute Repräsentation der "Buckets" findet. (bei Dezimalzahlen z.B. die Ziffern -> 10 Buckets -> Iterativ), bei Buchstaben -> 256 Buckets Iterativ, etc etc. Das Größte Problem der Methode ist es eine gute Methode für die Bucketdefinition zu finden (bei hochdimensionalen Daten wie z.B. einem WString kann nicht einfach 2^16 Buckets nutzen, das ist dann wieder zu Speicherintensiv und zu langsam, bei floats kann man z.B. auch nicht einfach die Ziffern verwenden, da muss man kreativ werden).

    Probleme die ich kenne sind:
    - Bei GDI+ wurden irgendwelche Returnwerte und Konstanten geändert. Ggf. muss man hier einiges Anpassen, wenn man GDI+ verwendet. (UEZ weiß hier mehr).

    - Bei _ArrayDisplay friert das Skript (als "toter" Prozess mit Volllast im Taskmanager sichtbar, man kann ihn dort auch beenden) ein, wenn man WÄHREND _ArrayDisplay aktiv ist das Skript via Tray beendet.

    - Bei Rechnungen mit Exponent & Minus Kombinationen (z.B. 11 - 2^4 = 27) wurde irgendwas umgestellt. Das war teilweise vorher (3.3.14.5) schon "schief" ist jetzt aber noch "schiefer". Klammern verwenden löst das Problem.


    Ggf. musst du das EN-Forum lesen, vllt gibt es noch mehr Probleme die ich nicht kenne (oder probleme die niemand aus dem DE-Forum kennt)


    Empfehlung: Probier es aus. "Wahrscheinlich" geht alles gut (vor allem wenn dich die 3 oben genannten Sachen nicht betreffen).

    Moin,


    der Thread hier ist absichtlich im Offtopic, weil er einfach nur zum Spaß ist :party1:


    Anbei meine Interpretation von "Welche Expression ergibt eigentlich 27" und "Welche Expression ergibt eigentlich -5"


    Motiviert durch Musashi (Zitat: "$x = 11 ------ 2^4 ; -5") ist hierbei ein Skript entstanden :party:


    Beispieloutput:


    M

    Es lässt sich wie ein assoziatives Array verwenden. Du kannst soetwas wie $Map["Klaus"] = "Isst am liebsten Wurst" machen. Früher musste man dafür ein Dict/DllStruct verwenden, oder (wenn man Variablen im "AutoIt-Datentyp" haben will) einen selbstgebauten Hashtable.