Beiträge von AspirinJunkie

Yeehah!
Und das obwohl mir erst während des Finalspiels einfiel, dass ich doch hätte tippen müssen.

Na dieses mal war ich es halt der Glück gehabt hat.
Dankeschön für die Organisation.
Auch wenn die Teilnehmerrunde parallel zum Forum immer schmaler wird.

Danke für den Tipp für meinen Tipp!

Und wirklich entschieden ist alles erst wenn der Videoschiedsrichter sein OK gegeben hat.

Ich hatte es ja auf github bereits angesprochen, dass ich mir natürlich au3mythos angesehen habe.
Wie bereits erwähnt, geht mein persönlicher Blick hierbei zuerst auf False-Positives, da mich diese schon bei Au3Check ziemlich stören.
Wobei: Eigentlich weniger die Meldungen selbst, als eher die Leute die dann meinen ich müsste meinen Code doch entsprechend dem vermeintlichen "Fehler" anpassen.

Ich habe daher einige Testfälle gebaut, welche auch entsprechend anschlagen. Das ist im ersten Aufschlag auch schlicht normal, dass noch einige Dinge aufploppen. Hier mal mein Testscript dazu:

; Fall A: bedingtes "declare-once"-Global wird nicht als Deklaration erkannt
If Not IsDeclared("myGlobal") Then Global $myGlobal = 42

Func FallA()
	Return $myGlobal + 1   ; <-- au3Mythos: "Undeclared Variable"
EndFunc


; Fall B: case-insensitive case ;-)
Func FallB($cChar)
	Switch $cChar
		Case "j", "J"   ; <-- au3Mythos: "Duplicate Case Value" (Gross-/Kleinschreibung)
			Return "Buchstabe J"
	EndSwitch
	Return "anderes Zeichen"
EndFunc
; Hinweis: unnoetig gross/klein zu schreiben, da Switch case-insensitive prueft, aber falsch ist es dennoch nicht.
; Achtung: triggert nur in Funktionen - in Top-Level-Switches meldet der Check gar nichts (sollte ebenso untersucht werden).


; Fall C: StringRegExp ohne 3. Parameter liefert 0/1, kein Array
Func FallC($sName)
	Local $bIsTest = StringRegExp($sName, "(?i)Test")
	If $bIsTest Then   ; <-- au3Mythos: "Array Used as Boolean" (falsch, $bIsTest ist 0/1)
		Return "Test enthalten"
	EndIf
	Return "kein Test"
EndFunc


; Fall D: Lesezugriff in ElseIf-Bedingung wird uebersehen
Func FallD($fWert)
	Local $fSchwelleHoch = 0.8
	Local $fSchwelleNiedrig = 0.3   ; <-- au3Mythos: "Dead Store" + "declared, but not used" (2x), obwohl unten gelesen

	If $fWert > $fSchwelleHoch Then
		Return "hoch"
	ElseIf $fWert > $fSchwelleNiedrig Then   ; Lesezugriff hier wird uebersehen
		Return "mittel"
	Else
		Return "niedrig"
	EndIf
EndFunc


; Fall E: Lesezugriff in Case-Klausel wird uebersehen
Func FallE($iEvent)
	Local Const $EVENT_CLOSE = -3   ; <-- au3Mythos: "Unused Variable" + "Dead Store" (2x), obwohl unten gelesen

	Switch $iEvent
		Case $EVENT_CLOSE   ; Lesezugriff hier wird uebersehen
			Return "Schliessen"
		Case Else
			Return "Unbekannt"
	EndSwitch
EndFunc


; Fall F: Dim auf bereits deklarierte Variable (hier: ByRef-Parameter) ist nur Redimensionierung
Func FallF(ByRef $iVariable)
	Dim $iVariable[3] = [1, 2, 3]   ; <-- au3Mythos: "Deprecated Dim Use" (falsch, keine Neudeklaration)

	Return $iVariable[0]
EndFunc
; Erklaerung: Dim auf eine bereits deklarierte Variable ist reine Redimensionierung, keine Deklaration.
; Das wird teilweise gebraucht, um Variablen, die vorher nicht sicher ein Array sind, als solches zu dimensionieren.


; Fall G: Zuweisung an ByRef-Parameter ist nie "dead" - der Wert geht an den Aufrufer
Func FallG(ByRef $iErgebnis)
	$iErgebnis = 42   ; <-- au3Mythos: "Dead Store" (falsch, ByRef fliesst an den Aufrufer zurueck)
EndFunc


; Fall H: einzeiliges "If ... Then Local" wird nicht als Deklaration erkannt
Func FallH($bAktiv)
	If $bAktiv Then Local $sWert = "gesetzt"   ; <-- au3Mythos: "Undeclared Variable" - sogar auf der Deklarationszeile selbst
	If Not $bAktiv Then Return ""
	Return $sWert   ; <-- au3Mythos: "Undeclared Variable" (2. Meldung)
EndFunc
; Gleiche Wurzel wie Fall A, nur mit Local statt Global; mehrzeilige If-Bloecke loesen stattdessen Fall G aus.


; Fall I: Lesezugriff in Until-Bedingung wird uebersehen
Func FallI()
	Local $iMax = 3   ; <-- au3Mythos: "Dead Store" + "declared, but not used" (2x), obwohl in Until gelesen
	Local $iCount = 0

	Do
		$iCount += 1
	Until $iCount >= $iMax   ; Lesezugriff hier wird uebersehen
	Return $iCount
EndFunc
; Kurios: Lesezugriffe in While-, For- und Ternary-Ausdruecken werden korrekt erfasst - nur Until nicht.


; Fall J: Lesezugriff in einem Case-Bereich (To) wird uebersehen
Func FallJ($iWert)
	Local Const $BEREICH_MAX = 10   ; <-- au3Mythos: "Unused Variable" + "Dead Store" (2x), obwohl unten gelesen

	Switch $iWert
		Case 1 To $BEREICH_MAX   ; Lesezugriff im Bereichsausdruck wird uebersehen (wie Fall E)
			Return "im Bereich"
		Case Else
			Return "ausserhalb"
	EndSwitch
EndFunc

Wenn man die kompletten Checks (also -d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7 --enable-experimental-checks) fährt, dann werden die im Code erwähnten False Positives gefunden.
Au3Check meldet hierbei übrigens das (korrekterweise) alles clean ist. Wenn man mit den Standardoptionen checkt, bleiben die Fälle A und H erhalten.

Darüber hinaus gibt es noch Probleme die sich aus dem jeweiligen Encoding der Datei ergeben. Dazu habe ich mal ein separates Skript in den Anhang gelegt.

So: Wie nun damit umgehen? Was ist der Zweck von statischen Code-Analyzern? Sie sollen frühzeitig, noch vor der Ausführung, auf mögliche(!) Problemstellen hinweisen. Diese schaut man sich dann an und kann entscheiden, wie man damit umgehen möchte. Egal wie ausgefuchst diese designt werden - sie werden niemals das komplette Laufzeitverhalten sauber vorhersagen können.

Ich plädiere daher einmal mehr dafür, die Ergebnisse von derartigen Tools eben nur als das zu betrachten was sie wirklich sind: lediglich Hinweise.
Auf keinen Fall sollten sie als Checkliste betrachtet werden, die bescheinigen, dass ein Skript erst dann sauber und korrekt ist, wenn diese nichts mehr finden.
Sprich: Auch wenn Au3Check und Verwandte meckern, sagt das noch nichts darüber aus ob ein Code sauber ist oder eben nicht.

Wenn man dies im Hinterkopf behält, ist gleichzeitig der Druck raus, die oben gefundenen False Positives noch mit in au3mythos zu beseitigen. Es wird darüber hinaus einfach noch weitere Fälle geben die dennoch fälschlich anschlagen. Ist halt prinzipbedingt so und irgendwann wird es dann auch mal zu komplex. Von daher wäre das pragmatischste auf den Hinweischarakter und die Prüfungspflicht des Anwenders zu verweisen. Dann ist das durchaus ein hilfeiches Tool (bekommst du es evtl. noch etwas fixer hin?) um Dinge aufzudecken, welche sonst untergehen würden.

Du hast nur die reinen Kommentarzeilen entfernt. Der folgende Kommentar ist weiterhin Teil des JSON-Strings:

/* if you change it all old passwords are not readable anymore, so delete the Users.DB file */

Edit: Hier mal als vollständiges Skript:

#include "JSON.au3"

; Datei als String in Variable lesen
Global $sFileRaw = FileRead("sample5.json")

; Kommentare entfernen
Global $sJSON = StringRegExpReplace($sFileRaw, '(?m)"([^"\\]*+(?>\\.[^"\\]*+)*)"(*SKIP)(?!)|\/\*.+?\*\/|^\h*\/\/.+\R', '')

; JSON-String in AutoIt-Struktur parsen:
Global $oJSON = _JSON_Parse($sJSON)
If @error Then Exit MsgBox(0, "Fehler", "Fehler bei _JSON_Parse" & @CRLF & "@error = " & @error & @CRLF & "@extended = " & @extended)

; Werte auslesen
Global $sHTTP             = _JSON_Get($oJSON, 'Kestrel.Endpoints.Http.Url')
Global $sHttpsDefaultCert = _JSON_Get($oJSON, 'Kestrel.Endpoints.HttpsDefaultCert.Url')

; Werte ausgeben:
MsgBox(0,"Http", $sHTTP)
MsgBox(0,"HttpsDefaultCert", $sHttpsDefaultCert)

Kommentare (die //-Zeilenanfänge sowie die /*/*/-Kombinationen) sind in keinem maßgeblichen JSON-Standard (RFC 8259 / ECMA-404 / STD 90) - und damit auch in der UDF - erlaubt.
Der JSON-String ist ergo kein gültiger JSON-String.

Vor dem Prozessieren musst du also die Kommentare z.b. per RegEx entfernen.

Zitat von BugFix

Vielen Dank für die detaillierte und aufschlussreiche Erklärung. 👍

Bei mir brauchst du dich nicht zu bedanken. Die Antwort ist ja nicht von mir. Ich hab nur nen Prompt gefüttert.
Hab Claude auch deine Erkenntnisse zu U1/U2 gesendet und folgendes als Antwort erhalten:

PM2014D — IC identifiziert

Datenblatt ist auffindbar: PM2014D von Power-Micro Semiconductor (DS_PM2014D_CN_V1.1, nur chinesisch). Es ist ein linearer Konstantstrom-LED-Treiber mit integriertem 650-V-MOSFET — kein diskreter MOSFET, sondern ein IC mit Referenz, Regelverstärker, Schutzlogik und Übertemperaturkompensation.

Eckdaten / Pinbelegung (TO252-3)

• Pin 1 — GND
• Pin 2 — DRN, Drain des internen HV-MOSFET
• Pin 3 — CS, Strommesseingang

Interner MOSFET: 650 V Sperrspannung, 1,5 A Spitzenstrom, RDSON 9,5 Ω. θJA des TO252-3: 45 K/W. Damit ist klar: dein Test „0,5 V über die Diode, sperrt rückwärts" hat nur die Body-Diode des internen MOSFET (DRN→GND) geprüft. Das beweist nur, dass der MOSFET nicht durchlegiert ist — Regelverstärker, Referenz, Schutzlogik und OTC können trotzdem defekt sein. Keine Funktionsprüfung des IC.

Stromeinstellung — mit Einschränkung
Der IC regelt die CS-Spannung auf typisch 500 mV. Daraus: I_LED = 0,5 V / R_CS.
Wichtige Einschränkung: Das Datenblatt spezifiziert diese 500 mV nur für 1 mA ≤ Iout ≤ 60 mA. Ein 6,8-Ω-Sense ergäbe 0,5 / 6,8 ≈ 74 mA — das läge oberhalb des spezifizierten Regelbereichs. Entweder ist der reale CS-Widerstand größer, oder die Platine fährt den IC grenzwertig. Beispiel: zwei parallele 18-Ω-Widerstände ergeben 9 Ω → 0,5 / 9 ≈ 56 mA, das läge im Spec-Bereich. Auf dem Foto sind bei U2 offenbar zwei 18-Ω-Typen vorhanden.
Konsequenz: Den effektiven CS-Widerstand je IC durch Leiterbahnverfolgung von Pin 3 nach GND bestimmen. Nicht annehmen, dass beide IC denselben Wert haben — die Ströme können sich unterscheiden.

Die Schlüsselmessung: CS-Spannung
Im Betrieb U_CS = Pin 3 gegen Pin 1, je IC:

• ~0,50 V → voller Regelstrom
• ~0,20 V → deutlich gedrosselt
• ~0,05 V → nur Glimmen plausibel
• 0 V → IC aus / Schutz aktiv / CS-Pfad defekt / Strompfad offen

Strom dann I ≈ U_CS / R_CS mit dem zuvor bestimmten R_CS. Diese Messung ist deutlich aussagekräftiger als die 312 V Zwischenkreisspannung.
Sicherheit: Bei kaskadierten IC liegt Pin 1 nicht auf ungefährlichem Bezugspotential — keine Schutzkleinspannungs-Masse. Keine Messung mit geerdetem Oszilloskop-Masseclip, nur potentialfrei/differentiell und mit geeigneten Messmitteln.

Übertemperaturkompensation (OTC) — Bedingung beachten
PM2014D regelt den Strom oberhalb einer Chiptemperatur aktiv herunter: Schwelle 110 °C (L-Version) bzw. 130 °C (M-Version), Steigung −100 %/40 °C bzw. −100 %/20 °C. Welche Version, steht in der Bauteilbeschriftung.
OTC kann gleichmäßiges Glimmen erzeugen — aber nur bedingt:

• Leuchte startet kalt kurz heller und dunkelt dann über Sekunden ab → OTC plausibel.
• Leuchte glimmt aus kaltem Zustand sofort und konstant → OTC ist nicht die Ursache; dann eher IC-Schaden, CS-Pfad, Lötstelle, Bahnriss oder Kettenfehler.

Also zuerst den Kaltstart beobachten, bevor man auf Wärme tippt. OTC ist eine mögliche, nicht die automatisch wahrscheinlichste Ursache.

Verlustleistung — nur Plausibilitätsrechnung
Der IC verheizt (U_Bus − U_LED-Kette)·I_LED. Bei ~60 V Differenz und ~70 mA wären das ~4,4 W; auf zwei IC verteilt ~2,2 W je IC. 2,2 W · 45 K/W ≈ 99 K über Umgebung, also rechnerisch ~124 °C Chiptemperatur — im Bereich der Stromreduktion. Aber: θJA hängt stark von Kupferfläche, Lötqualität, Platinenmaterial und Luftstrom ab. Das ist eine Plausibilitätsrechnung, keine Diagnose.

Topologie der zwei IC — nicht aus dem Foto bewiesen
Das Datenblatt nennt den Betrieb mehrerer IC in Reihe für hohen PF. Zwei PM2014D plus ~252 V Kettenspannung machen einen kaskadierten Linearbetrieb plausibel. Vom Foto allein ist die exakte Verschaltung aber nicht sicher: möglich sind kaskadierte Reglerstufen in einem Strompfad, gestufte Segmentführung, eine Hoch-PF-Schaltung oder zwei getrennte Teilstrings. Für die Diagnose relevant, weil CS-Widerstände und Ströme dann nicht identisch sein müssen.

CS-Leerlaufschutz
PM2014D hat Output-Open- und CS-Open-Schutz. Eine gebrochene Lötstelle am CS-Widerstand oder an Pin 3 kann den Schutz auslösen. CS-Widerstands- und Pin-3-Lötstellen separat prüfen. Auch die TO252-Tab-Lötstelle nachlöten — sie ist gleichzeitig Kühlpfad und elektrischer Drain-Anschluss; ein Haarriss verschlechtert die Wärmeabfuhr und addiert Widerstand im DRN-Pfad.

Mindestspannung
Zum Regeln von 60 mA bei Tj 100 °C braucht der IC laut Datenblatt mindestens 9 V zwischen DRN und GND. Bei 312 V Bus und ~252 V Kette ist genug Reserve — solange nicht ein IC der Kaskade ausfällt und die Spannungsaufteilung kippt.

Ersatz
PM2014D ist über AliExpress beschaffbar (TO252-3). Bei Surge-Verdacht beide IC zusammen tauschen. Alternativtypen nicht blind einsetzen — entscheidend ist die CS-Regelspannung: ein Typ mit 250 mV statt 500 mV liefert bei gleichem Sense-Widerstand nur den halben Strom. Ebenso prüfen: Strombereich, Drain-Spannungsfestigkeit, OTC-Verhalten, Gehäusewärmewiderstand, Schutzfunktionen, Reihenschaltungsbetrieb.

Reihenfolge

1. Kaltstart beobachten: sofort dunkel, oder erst hell und dann abdunkelnd.
2. CS-Widerstand je IC durch Leiterbahnverfolgung Pin 3 → GND bestimmen.
3. U_CS = Pin 3 gegen Pin 1 je IC im Betrieb messen, Strom berechnen.
4. U_CS nahe 0 V → CS-Pfad / Lötstellen / IC-Schaden / Schutzbetrieb prüfen.
5. U_CS nahe 0,5 V, aber LED nur Glimmen → LED-Kette / Topologie / Spannungsaufteilung weiter prüfen.
6. Tab- und CS-Lötstellen beider IC nachlöten.
7. Bringt das nichts: beide PM2014D tauschen.

Bis sich ein richtiger Experte meldet, bringt dich vielleicht erstmal die Antwort von Claude dazu ein wenig weiter:

Kernfehler in deiner Annahme

Die 3-V-Rechnung ist falsch. Der Aufdruck „18V×10PCS+9V×8PCS" ist die Spezifikation der LED selbst: keine Einzelchip-3-V-LED, sondern Mehrchip-Hochvolt-Packages — 10 Stück mit 18 V, 8 Stück mit 9 V Flussspannung. Summe der Bestückung: 10×18 + 8×9 = 252 V. Es gibt keine versteckten Vorwiderstände an den LED. Die fehlenden ~60 V (312 − 252) fallen über dem Linearregler ab. Das Suchen nach LED-Widerständen ist eine Sackgasse.

Was U1/U2 wirklich sind

Keine MOSFET im klassischen Sinn, sondern lineare Konstantstrom-LED-Treiber-IC (Stromsenke). Sie sitzen am Fußpunkt der Kette und ziehen einen definierten Strom, eingestellt über einen kleinen Sense-Widerstand (die 6R8-/Sub-Ohm-Typen direkt neben den IC). Dein Test

Zitat

0,5 V über die Junction, sperrt rückwärts

prüft nur eine Diodenstrecke. Über die Regelfunktion sagt er nichts. Ein solcher IC besteht den Junction-Test und regelt trotzdem keinen brauchbaren Strom.

Warum das gleichmäßige Glimmen aussagekräftig ist

In einer Reihenschaltung ist der Strom überall identisch. Sinkt er, werden alle LED exakt gleich dunkler — genau dein Symptom. Ein einzelner LED-Defekt scheidet damit praktisch aus (defekte LED in Reihe → Kette stromlos, nicht „alle gleich schwach"). Ursache ist eine gemeinsame Strombegrenzung: Regler-IC oder Sense-Pfad. Das schwache Glimmen ist dann nur Reststrom über Leckpfade (Bleeder, IC-Leckage), während der eigentliche Regelpfad zu ist. Die zwei IC und die separaten Anschlusspunkte (U+, V+ …) deuten auf zwei Kanäle/Strings. Dass beide gleich dunkel sind, zeigt auf eine gemeinsame Ursache.

Messungen, nach Priorität

1. Spannungsabfall über dem Sense-Widerstand unter Last — pro Kanal getrennt. Gibt direkt den Strom. Beispiel: Sense 6,8 Ω, Soll-Vsense ~0,3 V → 44 mA Sollstrom. Misst du dort nur ~20 mV, fließen ~3 mA → Regler praktisch zu. Das ist die entscheidende Messung. Spannung über dem IC (Eingangspin gegen Massepin) im Betrieb. Klein (wenige V) → IC arbeitet, Fehler liegt woanders. Groß (>200 V) → IC drosselt den Strom = IC-Defekt.
2. Beide Elkos messen, nicht nur einen. 18 µF über 12 µF Nennwert ist kein Defekt — gealterte Elkos verlieren Kapazität, sie gewinnen keine; der Wert ist die reale Bestückungstoleranz. ESR 0,62 Ω bei 12 µF/400 V ist akzeptabel. Aber: das Multimeter misst den Mittelwert. Ein zweiter, offener Elko kann trotzdem 312 V Mittelwert zeigen, bei massiver Welligkeit.

Die 312-V-Messung präzisieren

Entscheidend ist, ob mit angeschlossener, glimmender Platine gemessen wurde oder im Leerlauf. Leerlauf → nur Busspannung, keine Aussage über den Betrieb. Mit Platine, über der LED-Kette → liegen dort 312 V an, während sie glimmt, nimmt die Kette fast keine Spannung auf → fast kein Strom → Regler offen oder Kette hochohmig.

Saubere Eingrenzung — beide Hälften trennen

• LED-Platine allein an regelbarem Labornetzteil mit Strombegrenzung (~50 mA), Spannung langsam hochfahren. Voll hell bei ~250–260 V → Panel intakt, Fehler im Treiber. Braucht deutlich mehr oder wird nie hell → LED degradiert. Treiber allein: LED-Platine durch bekannte Last ersetzen (Widerstandskette passender Größe). Liefert er Sollstrom → Treiber ok. Nur Reststrom → Treiber-IC defekt.

Diese zwei Tests trennen „Panel oder Treiber" eindeutig. Ohne sie wird weiter geraten.

Thermische Rückfaltung als Diskriminator

Helligkeitsverlauf nach dem Einschalten beobachten. Sofort und konstant dunkel → IC tot / Sense-Pfad / Kettenfehler. Startet heller, fällt nach Sekunden ab → thermische Rückfaltung des Reglers.

Lötstellen

Es wurde gelötet, und das auslösende Ereignis hat die Schaltung gestresst. Ein Haarriss im Sense-Pfad addiert Widerstand: Der IC sieht bei kleinem Iststrom schon genug Sense-Spannung und regelt herunter. Statische Widerstandsmessung zeigt das nicht. Lötstellen um U1/U2, Sense-Widerstände und Übergabepunkte nachlöten.

Wahrscheinlichste Ursache

Das Ereignis, das die Gleichrichterdiode zerstört hat (Netz-Surge oder Überstrom), hat mit hoher Wahrscheinlichkeit auch einen oder beide Treiber-IC beschädigt. Ein Surge trifft Gleichrichter und nachgelagerte IC gleichermaßen — deshalb bleibt der Fehler nach dem reinen Diodentausch. Die Junction-Prüfung übersieht genau diesen Schaden.

Pragmatischer Weg

Zeigt die Trennung Panel intakt, Treiber defekt: Linearregler nicht aufwendig reparieren. IC neu bestücken nur, falls Typ lesbar — sonst Treiberplatine verwerfen und Panel direkt mit handelsüblichem Konstantstromtreiber betreiben, dessen Ausgangsspannungsbereich 252 V abdeckt und dessen Strom zum Panel passt. Sollstrom vorab über die Sense-Messung schätzen oder grob aus 18 W / 252 V ≈ 71 mA.

Adjustment UDF v26.4 — Release Notes

Dieses Release bringt ein vollständiges interaktives Regressions-Tool als Beispiel, eine deutlich schnellere robuste Schätzung sowie mehrere neue Diagnose- und Statistik-Funktionen. Daneben wurden eine Reihe numerischer und code-technischer Bugs behoben.

Download: Release v26.4 auf GitHub

────────────────────────────────────────
Highlight: Interactive Regression
────────────────────────────────────────

Das neue Beispiel 'examples/InteractiveRegression.au3' ist ein vollständiges GUI-Tool für Curve-Fitting per Least-Squares. Es kombiniert alle Kernfähigkeiten der UDF in einer kompakten, interaktiv bedienbaren Oberfläche — und ist gleichzeitig als Lernwerkzeug konzipiert: Beim Spielen mit den Modi und Daten lassen sich die Auswirkungen von Fehlerannahmen, Gewichtung und Modellwahl direkt im Plot beobachten.

Funktionsumfang:

• Vier Regressionsmodi: Normal (OLS/WLS), Orthogonal (TLS), Deming, York
• Symbolische Formeleingabe mit automatischer Parameter- und Beobachtungserkennung (z.B. 'A * #X + B')
• Editierbare Tabellen für Daten und Parameter, mit Tab-/Enter-/Pfeiltasten-Navigation und Excel-kompatiblem Mehrzellen-Paste
• Live-Plot mit Datenpunkten, gefitteter Kurve, Residuen-Linien und optionalem 1σ/2σ-Konfidenzband (GDI+)
• Robuste Schätzung mit allen sechs M-Schätzern der UDF
• CSV-Import (Auto-Erkennung Trennzeichen und Dezimaltrenner) sowie CSV-Export mit Formel-Metadaten (Round-Trip)
• Vorhersage mit korrekter σ-Propagation
• Ausreißer-Highlighting basierend auf normierten Verbesserungen
• "σ · s₀"-Knopf für globale Varianzfaktor-Skalierung der σ-Eingaben

────────────────────────────────────────
Performance: Schnellere robuste Schätzung
────────────────────────────────────────

Iterative Reweighted Least Squares (IRLS) ist bei großen Problemen oder vielen Iterationen der Hauptkostenfaktor. Mehrere Optimierungen reduzieren die Laufzeit deutlich, ohne Genauigkeit zu verlieren:

• Warm-Start des Gauß-Newton-Innen-Loops zwischen IRLS-Iterationen
• Begrenzung der inneren GN/LM-Iterationen während Re-Solves
• Überspringen des State-Resets vor VKS im Single-Pass-Modus
• Default-Konvergenzgrenze für IRLS gelockert (1e-3 → 1e-2)
• Cascade-Init (Huber → redescending) als Default deaktiviert, bleibt aber per 'cascadeInit' zuschaltbar

────────────────────────────────────────
Neue Features
────────────────────────────────────────

Statistik

• Parameter-Korrelationsmatrix abrufbar (compute-on-demand)
• Konditionszahl der Normalgleichungs-Matrix routinemäßig verfügbar (vorher nur im SVD-Fallback)
• Sanity-Check 'tr(R) = f' deckt unsichtbar gebrochene Redundanzanteile auf

Diagnostik

• Iteratives Data Snooping mit weichem Downweighting (statt harter Ausreißer-Eliminierung)
• Äußere Zuverlässigkeit (Opt-in): Mindestaufdeckbarkeit 'δ₀ᵢ' und Parameter-Effekt '∇xᵢ' jedes nicht erkannten Ausreißers

Konvergenz

• Gradienten-Test '‖g(x)‖ < tol' zusätzlich aktiv, wenn Restriktionen vorhanden sind
• Parameter-Korrektur-Toleranz skaliert mit der Parameter-Größenordnung (vermeidet falsche Konvergenz bei sehr kleinen Parametern)

Solver / Robust

• Cascade-Init Huber → redescending (MM-Estimator) als optionaler Modus
• Anfänglicher Marquardt-Dämpfungsfaktor 'lmTau' konfigurierbar

────────────────────────────────────────
Bugfixes
────────────────────────────────────────

VKS / Robust

• Statistiken werden nach VKS-Konvergenz mit den finalen Gewichten aktualisiert
• σ̂²-Clipping am 'MIN_SIGMA2'-Floor statt Reset auf 1.0
• Aktiver VKS erzwingt den gewichteten Lösungsweg; geclipptes σ̂² signalisiert den Aufrufer korrekt als Nicht-Konvergenz
• MAD-Skala nutzt die a-priori 1/σᵢ statt des Whitening-Vektors der laufenden Iteration
• 'robustParams' werden automatisch auf Defaults gefüllt, wenn der Aufrufer sie auf Null lässt
• '__adj_initWeights' initialisierte für σ=1 + Multi-VKS-Gruppe keine Gewichte → korrigiert

Statistik / Diagnostik

• 'diag(Qvv)' und 'diag(Qŷ)' werden vor 'sqrt' auf 0 gefloort (vermied bisher NaN bei numerischen Negativwerten in Maschinenpräzision)
• Pope-Statistik nutzt nun korrekt die τ-Verteilung statt Student-t
• Baarda-/Pope-p-Werte berechnen sich numerisch stabil (keine katastrophale Auslöschung bei großen w/τ)

Solver

• LM-Konvergenztest im GLM/CLS-Pfad ist nun residual-basiert ('r2sum') statt parameter-basiert
• Schrittweiten-Skalierung im numerischen Differentiations-Modus smooth-blendet zwischen den Regimen, statt hart umzuschalten

API

• '_adj_setInitialValue' legt fehlende Parameter an, statt zu erroren
• '_adj_removeObs' setzt '_prepareRunCount' korrekt zurück; vermeidet Crash beim nächsten 'solve'-Aufruf

Code-Qualität

• Mehrere undeklarierte Locals in AdjustmentStats / AdjustmentDiagnostics, die in ByRef-Caller leakten, beseitigt
• Au3Check-Cleanup über alle UDF- und Beispiel-Dateien

────────────────────────────────────────
Kompatibilität
────────────────────────────────────────

Voll abwärtskompatibel zu v26.3.x. Keine API-Änderungen außer Erweiterungen. Default-Verhalten ist identisch — die Performance-relevanten Default-Anpassungen betreffen nur die robuste Schätzung und liegen weiterhin im konservativen Bereich (siehe '_adj_robustDefaults').

────────────────────────────────────────
Download
────────────────────────────────────────

>>> Release v26.4 von GitHub herunterladen <<<

Quellcode und Issue-Tracker: https://github.com/Sylvan86/autoit-adjustment-udf

Zitat von UEZ

Ausgeführt als Standard x86. Wenn als x64 ausgeführt, dann kein Crash!

Da war ein Bug beim Memory kopieren in 32 Bit drin. Ist gefixt und sollte nun funktionieren (neues Release ist oben).

Zitat von Andy

Leider befasse ich mich weniger mit höherer Mathematik,

Das ist im Grunde der Sinn dieser UDF: Höhere Mathematik nutzen ohne sich mit dieser auseinander setzen zu müssen.

Hast du die OpenBLAS-DLLs im richtigen Ordner?
Ich habe gerade nochmal das Release heruntergeladen (siehe >>hier<<). Da ist alles fix und fertig drin was man da braucht und es läuft bei mir ohne diesen Fehler.
Müssten wir mal schauen wie wir das reproduzieren können: 32/64 Bit? Welches BS?

Von Ingenieuren für Ingenieure 😉

Ok für die Fraktion, für die das (zu Recht) noch etwas zu abstrakt ist, habe ich mal ein weiteres Beispiel dem Example-Ordner hinzugefügt: InteractiveCircleFit.au3 (und das sogar auf deutsch!...)

Mit dem Skript klickt der User beliebige Punkte auf der Zeichenfläche und das Skript gleicht über diese Punkte einen bestanpassenden Kreis aus.
Das Beispiel eignet sich meiner Meinung nach sehr gut da man hiermit schnell viele Dinge der Ausgleichungsrechnung visualisieren kann:

- was sind Beobachtungen, was sind Parameter?
- was sind diese "Residuen"?
- was bedeuten die Standardabweichungen?
- was genau wird da eigentlich "ausgeglichen"?
- was bedeutet "robuste Ausgleichung"?

Einfach mal herumspielen damit (neues Release liegt auf Github).

Hinweis zur Urheberschaft: Da ich nicht so der visuelle Typ bin und von Grafik in AutoIt null Ahnung habe, habe ich mich für dieses Beispielskript intensiv Claude bedient.
Ich bin vom Ergebnis sehr angetan und freue mich, dass auch Claude die Verwendung meiner UDF komplett verstanden hat.

Zitat von Schnuffel

Ich brauche immer praktische Beispiele, die mir die Nutzung veranschaulichen.

Dafür habe ich das Tutorial gestaltet sowie einen extra example-Ordner mit weiteren Beispielen gemacht. Angesehen?

Zitat von SOLVE-SMART

Mit anderen Worten: willst du wirklich hier eine WTFPL license Lizenz geltend machen?

Ja - ist ein Hobby - mehr nicht.

Nun ist es soweit: 11 Jahre Arbeit an dieser UDF und nun habe ich ein vorzeigbares Ergebnis.

Es handelt sich hier nicht um etwas beliebiges was nun auch mal in AutoIt umgesetzt wurde.
Tatsächlich ist mir kein Projekt wie dieses auch in anderen Sprachen bekannt.
Die Fähigkeit Usern selbst komplexeste Ausgleichungsrechnung dermaßen simpel zugänglich zu machen ist meines Wissens nach einzigartig.

Ausgleichungsrechnung war eher eine Nische für Geodäten und Mathematiker. Tatsächlich ist es aber ein derart nützliches Werkzeug bei allen Arten von fehlerbehafteten Daten - sprich: Messungen.
Was bisher einer weiten Verbreitung entgegenstand war die doch komplexe Mathematik dahinter.
Genau hier setzt die UDF an in dem sie diesen Aspekt dem User abnimmt. Er muss nur noch sein Problem beschreiben - den Rest macht die UDF.

Ich empfehle unbedingt das Tutorial mal durchzulesen um einen Eindruck zu bekommen um was es geht.
Gleichzeitig hoffe ich auf intensive Diskussionen zu euren konkreten Problemen die sich mit dieser UDF lösen lassen.

Bin ich etwas emotional? Definitiv! Diese UDF ist schon so etwas wie mein Lebenswerk.
Vom Umfang und fachlicher Tiefe geht es weit über alles hinaus was ich bisher gemacht habe.

Adjustment UDF — Ausgleichungsrechnung für AutoIt

Die Ausgleichungsrechnung nach der Methode der kleinsten Quadrate bestimmt aus überbestimmten, widersprüchlichen Beobachtungen die optimalen Werte — und sagt dir dabei genau, wie zuverlässig die Ergebnisse sind. Sie ist die mathematische Grundlage hinter Positionierung, Navigation, Kalibrierung, Fitting, Regression, Signalverarbeitung und praktisch jedem Bereich, in dem Messungen auf die Realität treffen.

Diese UDF bringt diese Fähigkeit mit einer radikal einfachen Schnittstelle nach AutoIt: Beschreibe dein Modell als String-Formeln, füge Messungen mit ihren Unsicherheiten hinzu und rufe _adj_solve() auf. Keine Matrizenrechnung, keine numerischen Kopfstände, keine externen Tools — nur dein Problem und deine Daten.

Unter der Haube steckt eine vollständige Ausgleichungsengine auf Basis von OpenBLAS mit nichtlinearen iterativen Lösern, Varianzkomponentenschätzung, robusten Schätzern und vollständiger statistischer Diagnostik — die Art von Werkzeug, die normalerweise MATLAB oder spezialisierter wissenschaftlicher Software vorbehalten ist.

Download: Aktuelles Release auf GitHub
GitHub: https://github.com/Sylvan86/autoit-adjustment-udf

Schnellstart

#include "Adjustment.au3"

; 5 Messungen einer Strecke — finde den besten Schätzwert
Local $mSystem = _adj_createSystem()
_adj_addObsFunction($mSystem, "M1", "X", 10.02, 1.0)
_adj_addObsFunction($mSystem, "M2", "X",  9.98, 1.0)
_adj_addObsFunction($mSystem, "M3", "X", 10.01, 1.0)
_adj_addObsFunction($mSystem, "M4", "X", 10.03, 1.0)
_adj_addObsFunction($mSystem, "M5", "X",  9.99, 1.0)
_adj_setInitialValue($mSystem, "X", 10.0)

_adj_solve($mSystem)
ConsoleWrite(_adj_displayResults($mSystem))

; Ergebnis: X = 10.006 ± 0.009

Das ist nur der einfachste Fall — ein Mittelwert. Die eigentliche Stärke liegt im gleichzeitigen Ausgleichen verschiedener Messungen mit unterschiedlichen Formeln. Zum Beispiel: Die Position eines Punktes aus Strecken- und Richtungsmessungen bestimmen, oder eine Kurve an Daten anpassen und dabei Nebenbedingungen erzwingen.

Funktionsübersicht

Für Experten — der volle Umfang der UDF:

Modelltypen

• OLS / WLS / GLS — Überbestimmtes System (gewichtet, generalisiert mit voller Kovarianzmatrix)
• LSE / WLSE / GLSE — Mit Parameterrestriktionen
• CLS / WCLS / GCLS — Bedingungsausgleichung
• GLM / WGLM / GGLM — Gauß-Helmert-Modell (allgemeinste Form)

Die Modelltyperkennung erfolgt automatisch anhand der Eingabestruktur.

Löser und Iterationsverfahren

• Iterationsverfahren: Gauß-Newton, Levenberg-Marquardt (Nielsen-Dämpfung)
• Linearer Löser: QR-Zerlegung (DGELSY), Singulärwertzerlegung (DGELSD)
• Jacobi-Matrizen: Numerisch (Zentral, Vorwärts, Rückwärts, Ridder, Higham) oder analytisch
• Skalierung: Jacobi-Äquilibrierung (automatische Spaltenbalancierung)

Statistik und Diagnostik

• Grundstatistiken: A-posteriori-Varianzfaktor s0², Freiheitsgrade, vTPv
• Genauigkeit: Kofaktormatrix Qxx, Standardabweichungen (Parameter, Beobachtungen)
• Kontrollierbarkeit: Redundanzanteile r_i, Kofaktormatrizen Qvv und Qy
• Modellvalidierung: Globaltest (Chi²)
• Ausreißerdiagnostik: Baarda-Test (w-Statistik), Pope-Test (tau-Statistik), p-Werte, MDB

Varianzkomponentenschätzung (VKS)

Helmert-Methode: Separate Varianzfaktoren für verschiedene Beobachtungsgruppen (z.B. Strecken vs. Richtungen). Iterativ bis zur Konvergenz.

Robuste Schätzung (IRLS)

• L1 (Median) — Bruchpunkt: 50%
• Huber (c = 1.345) — Bruchpunkt: ~5%
• Hampel (a = 1.7, b = 3.4, c = 8.5) — Bruchpunkt: ~25%
• Biweight (Tukey) (c = 4.685) — Bruchpunkt: 50%
• BIBER (Schweppe) (c = 3.5) — Bruchpunkt: hebelwertabhängig
• Modified-M (Koch) (c = 1.5) — Bruchpunkt: hebelwertabhängig

Skalenparameter: MAD, s0, a priori, benutzerdefiniert.

Weitere Features

• Symbolische Formeleingabe als Strings — Parameter und Beobachtungen werden automatisch erkannt
• Compute-on-Demand — Statistiken werden erst bei Abruf berechnet
• Konfigurierbare Ergebnisanzeige mit wählbaren Spalten und Abschnitten
• Ausreißererkennung und -entfernung (_adj_getOutliers, _adj_removeObs)

Installation

Voraussetzungen:

• AutoIt v3.3.16+ (x64)
• OpenBLAS DLL (libopenblas_x64.dll)

Einrichtung:

1. Download: Aktuelles Release von GitHub Releases herunterladen
2. Entpacken: Dateien in ein Verzeichnis entpacken
3. OpenBLAS: Die libopenblas_x64.dll wird beim ersten Start automatisch heruntergeladen oder kann manuell ins UDF-Verzeichnis gelegt werden
4. Einbinden:

$__g_hBLAS_DLL = DllOpen("libopenblas_x64.dll")
#include "Adjustment.au3"

Dokumentation

Die vollständige Dokumentation ist auf GitHub verfügbar:

• Tutorial — Schritt-für-Schritt-Anleitung, 9 Kapitel (Einsteiger)
• Funktionsübersicht — Alle Fähigkeiten auf einen Blick (Alle)
• API-Referenz — Alle 17 öffentlichen Funktionen (Entwickler)
• Konfiguration — Löser-, Anzeige- und Robust-Konfiguration (Fortgeschrittene)
• Ergebnisstruktur — Alle Schlüssel der Ergebnis-Map (Fortgeschrittene)
• Modelltypen — OLS bis GGLM mit Mathematik (Experten)
• Löser — GN, LM, QR, SVD im Detail (Experten)
• Statistik — s0, Qxx, Globaltest, Baarda/Pope (Experten)
• Robuste Schätzung — IRLS, 6 Schätzer, Gewichtsfunktionen (Experten)
• Fehlercodes — Alle $ADJ_ERR_* mit Lösungen (Alle)

Tutorial-Kapitel

1. Erste Schritte — Was ist Ausgleichungsrechnung?
2. Erstes Netz — Trilateration
3. Gewichtung — Messgenauigkeit berücksichtigen
4. Gemischte Beobachtungen — Strecken und Richtungen kombinieren
5. Nebenbedingungen — Restriktionen und feste Parameter
6. Regression — OLS, orthogonal, Deming, York
7. Kovarianzmatrix — Korrelierte Messungen
8. Ergebnisse verstehen — Ausgabe konfigurieren und interpretieren
9. Robuste Schätzung — Umgang mit Ausreißern

Download

>>> Aktuelles Release von GitHub herunterladen <<<

Quellcode und Issue-Tracker: https://github.com/Sylvan86/autoit-adjustment-udf

Aus meiner Sicht ist das durchaus ein Bug. Jedoch nicht von AutoIt sondern vom Tool Au3Check, welches oftmals vor AutoIt selbst aufgerufen wird.

Kann man ganz gut daran erkennen wenn man es deaktiviert indem man am Anfang des Skriptes folgende Zeile setzt: #AutoIt3Wrapper_Run_AU3Check=N - dann läuft das Skript problemlos.

Ich selbst bin kein Fan von dem meiner Meinung nach ziemlich verbuggten Tool. Das Ding erkennt viel zu viele False-Positives.

Zitat von argumentum

Ich möchte, dass dieser Code (oder ein funktionierender Code) „sha3_256” hasht.

Na gut ich habe mal eine Variante gefunden die damit funktionieren könnte (C-Code im Anhang).
Bei der Umsetzung sind mir aber ein paar Erweiterungen für die JIT.au3 aufgefallen, die hierfür benötigt werden.
Es ist also mindestens die neue Version v0.2.1 (siehe Link im ersten Post) zu verwenden.

Dann kann man sich damit eine sha3_256-Funktion in AutoIt folgendermaßen bauen:

#include "JIT.au3"

; hash a string
Global $sString = "Hallo Welt"
Global $bHash = _sha3_256($sString)

ConsoleWrite('sha3_256("' & $sString & '") = ' & StringTrimLeft($bHash, 2) & @CRLF)


; hash a file
Global $hFile = FileOpen(@ScriptDir & "\sqlite-preprocessed-3520000.zip", 16)
Global $bFile = FileRead($hFile)
FileClose($hFile)
Global $bHash = _sha3_256($bFile)

ConsoleWrite('sha3_256("sqlite-preprocessed-3520000.zip") = ' & StringTrimLeft($bHash, 2) & @CRLF)

Func _sha3_256($sString)
	;~ Local Static $mCode = _JIT_Compile(FileRead('sha3_256_portable.c'))
	Local Static $mCode = _JIT_LoadBinary(@AutoItX64 _
		? '{"b":"QVdJifhBuc3MzMxMjRWuBQAAQVZNjbigAAAATY2YwAAAAEFVSY2A6AAAAEFUVUiNbyBTSIHs4AAAAEiNfCQIkEiNTCSoTInGTIn68w9vQojzD28aSIPCEEiDwRDzD2+SUP////MPb0rI8w9vYqBmD+/CZg/vw2YP78xmD+/BDylB8Ew52nXESYtQSEkzUCBMjWwk2DHJSTNQcEkzkJgAAABNiexJifZJM5DAAAAASIlUJMiNcQRJg8QISInySQ+v8UjB7iKNNLYp8o1xAUiJ8UkPr/FIY9JIwe4ijRy2ic4p3khj9kiLdPSoSNHGSDN01KhJiXQk+IP5BXW3TIn2TInBZkEPb00AMdLzD28EEWYP78EPEQQRSIPCKEiB+sgAAAB15kiDwRBJg8UQSDnNddFIicNIi0wk+EiJ6kgp64PjCHQcSI1VKEgxTQBIOcJ0H2ZmLg8fhAAAAAAADx9AAEgxCkgxSihIg8JQSDnCdfBIiXQkkEyNLcQDAABNicQx20yJVCSYSIlEJKBMifhMiWQkiI00G02J702J4jHSifFNizJJg8cUSYPCKEkPr8lIwekiRI0kiYnxg8YDRCnhRI0kiUGLT+xBAdSDwgFNY+RJ08ZOiXTkCIP6BXXBTItkJIiDwwFJg8UESYPECIP7BXWcSYnHSIt0JJBIi0QkoEiJ+0yLdCSYRTHkQY1MJAFBjVQkAkmJzEkPr8lIwekiRI0UiUSJ4UQp0UhjyUyNLM+J0UkPr8lIwekijQyJKcoxyUhj0kyNFNdJi1QNAEj30kkjFApIMxQLSIkUDkiDwShIgfnIAAAAdd9Ig8MISIPGCEGD/AV1k02NVghIjR3+AwAASYsWSTEQSTnaD4Wv/f//SIHE4AAAAFtdQVxBXUFeQV/DZmYuDx+EAAAAAABmkEFVMcBNicVBVEmJ1FVXVlNIicu5GQAAAEiB7AgCAABIjawkkAAAAA8ptCRgAQAASInvDym8JHABAABEDymEJIABAABEDymMJJABAABEDymUJKABAABEDymcJLABAABEDymkJMABAABEDymsJNABAABEDym0JOABAABEDym8JPABAADzSKtJgfiHAAAAdmpJiepFMclmZi4PH4QAAAAAAJBLjRQMMclFMcAPH4AAAAAAD7YCSIPCAUjT4IPBCEkJwIP5QHXrSYPBCE0xAkmDwghJgfmIAAAAdcdIie9Jge2IAAAASYHEiAAAAOhh/P//SYH9hwAAAHeWuREAAAAxwEiJ50mJ4vNIq02F7XQ1RInqSInnTInmQYP9CHIJRInpwekD80ilMcD2wgQPhUoBAAD2wgIPhSoBAACD4gEPhRUBAABCxgQsBkmJ6UUx24CMJIcAAACAZmYuDx+EAAAAAABMidIxyUUxwA8fhAAAAAAAD7YCSIPCAUjT4IPBCEkJwIP5QHXrSYPDCE0xAUmDwghJg8EISYH7iAAAAHXDSInv6Kv7//9FMclOi0QNAEqNBAsxyWZmLg8fhAAAAAAAZmYuDx+EAAAAAAAPH4AAAAAATInCSIPAAUjT6oPBCIhQ/4P5QHXrSYPBCEmD+SB1uQ8otCRgAQAADyi8JHABAABEDyiEJIABAABEDyiMJJABAABEDyiUJKABAABEDyicJLABAABEDyikJMABAABEDyisJNABAABEDyi0JOABAABEDyi8JPABAABIgcQIAgAAW15fXUFcQV3DD7YUBogUB+nf/v//D7cMBmaJDAdIg8ACg+IBD4TK/v//692LBokHuAQAAAD2wgIPhK3+///r1czMAAAAAAEAAAA+AAAAHAAAABsAAAAkAAAALAAAAAYAAAA3AAAAFAAAAAMAAAAKAAAAKwAAABkAAAAnAAAAKQAAAC0AAAAPAAAAFQAAAAgAAAASAAAAAgAAAD0AAAA4AAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAIKAAAAAAAAAioAAAAAAAIAAgACAAAAAgIuAAAAAAAAAAQAAgAAAAACBgACAAAAAgAmAAAAAAACAigAAAAAAAACIAAAAAAAAAAmAAIAAAAAACgAAgAAAAACLgACAAAAAAIsAAAAAAACAiYAAAAAAAIADgAAAAAAAgAKAAAAAAACAgAAAAAAAAIAKgAAAAAAAAAoAAIAAAACAgYAAgAAAAICAgAAAAAAAgAEAAIAAAAAACIAAgAAAAIA","f":{"keccak_f1600":0,"sha3_256":688}}' _
		: '{"b":"VYnlV1aNcCBTg+TwgexQAQAAiTQkjbDoAAAAx0QkCAAAAACJdCQMLo20JgAAAACQMdLzD28EEPMPb2QQKPMPb6wQoAAAAPMPb0wQUPMPb3QQeGYP78RmD+/FZg/vzmYP78EPKUQUMIPCEIP6IHXD8w9vVCQ4i0ggiUQkBItYJDNISGYPb8JmD2/aM1hMM0hwZg9z8wEzWHQziJgAAAAzmJwAAABmD3PQPzOIwAAAAIt0JDBmD+vDi3wkNIlMJFAzmMQAAACJTCQoicGJXCRU8w9vTCRIifIPpP4BiVwkLA+k1wEzdCRIjVwkYPMPflwkKA8WXCQwZg/vwzN8JEwPKUQkYGYPb8FmD3PxAWYPc9A/ibQkgAAAAGYP68GJvCSEAAAAZg/vwg8pRCRwZg9vCzHS8w9vBBFmD+/BDxEEEYPCKIH6yAAAAHXog8MQjZQkgAAAAIPBEDnTddGLHCSLTCQMKdmJ2oPhCHQRixwkMTONUygxewQ7VCQMdBaLTCQMMTIxegQxcigxeiyDwlA5ynXuiUQkEL64BQAAMcmLRCQQx0QkKAAAAACNHAmJdCQYjQTIiUwkFIlEJCSJdCQguM3MzMyLfCQk9+OJ0IPi/MHoAgHCidgp0ItXBI00gItEJCiNDAaLdCQgiweJ14lMJByLDonGD6X30+b2wSB0BIn3Mfb32Q+t0NPq9sEgdASJ0DHSi0wkHAnwg0QkKAEJ+oNEJCQog8MDiYTMiAAAAItEJCiDRCQgFImUzIwAAACD+AUPhXf///+LTCQUi3QkGIPBAYPGBIP5BQ+FPv///4tEJBDHRCQgAAAAAI28JIgAAACLdCQEiUQkHItMJCC4zczMzI1ZAoPBAffhiUwkIInQg+L8wegCAcKJyCnQjYzEiAAAALjNzMzM9+OJTCQkidCD4vzB6AIBwinTjYTciAAAADHbiUQkKItEJCSLTCQoi1QYBIsEGPfS99AjVBkEIwQZM1QfBDMEH4kEHolUHgSDwyiB+8gAAAB1zYPHCIPGCIN8JCAFD4Vu////i3QkCItEJByLDPU4BgAAixz1PAYAAIPGATEIMVgEiXQkCIP+GA+F+fz//41l9FteX13DkFW5MgAAADHAieVXVlOD5PCB7GABAACLXRCLdQyNvCSYAAAA86uB+4cAAAAPhsMAAACJdCQMjYaIAAAAiV0QiUQkBDHALo20JgAAAACNdCYAiUQkCDH2Mf8x2+skLo20JgAAAAAujbQmAAAAAC6NtCYAAAAALo20JgAAAACNdCYAi0QkDI0M3QAAAAAx0g+2BBgPpcLT4PbBIHQEicIxwIPDAQnGCdeD+wh11YtEJAiDRCQMCDG0BJgAAACLdCQEMbwEnAAAAIPACDl0JAx1gYtdEI2EJJgAAADo4vv//4t0JAyB64gAAACB+4cAAAAPhz3///+NVCQQuSIAAAAxwInX86uF23QiideD+wRyB4nZwekC86UxyfbDAg+FPAEAAPbDAQ+FJwEAAMZEHBAGMcCAjCSXAAAAgIlUJAyNdCYAiUQkCDH2Mf8x2+s0Lo20JgAAAAAujbQmAAAAAC6NtCYAAAAALo20JgAAAAAujbQmAAAAAC6NtCYAAAAAjXQmAItEJAyNDN0AAAAAMdIPtgQYD6XC0+D2wSB0BInCMcCDwwEJxgnXg/sIddWLRCQIg0QkDAgxtASYAAAAjbQkmAAAADG8BJwAAACDwAg7dCQMD4Vq////ifAx2+jh+v//i0UIiUQkCMdEJAwAAAAAi7QcmAAAAIlcJASLvBycAAAAi0QkDIn6jRzFAAAAAInwidnT6g+t+PbDIItcJAwPRcKJwotEJAiIFBiNQwGJRCQMg/gIdcuLXCQEg0QkCAiDwwiD+yB1oI1l9FteX13CDAAPtgQOiAQP6c3+//8Ptwa5AgAAAGaJB/bDAQ+Euf7//+vezMzMzMzMAAAAAAEAAAA+AAAAHAAAABsAAAAkAAAALAAAAAYAAAA3AAAAFAAAAAMAAAAKAAAAKwAAABkAAAAnAAAAKQAAAC0AAAAPAAAAFQAAAAgAAAASAAAAAgAAAD0AAAA4AAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAIKAAAAAAAAAioAAAAAAAIAAgACAAAAAgIuAAAAAAAAAAQAAgAAAAACBgACAAAAAgAmAAAAAAACAigAAAAAAAACIAAAAAAAAAAmAAIAAAAAACgAAgAAAAACLgACAAAAAAIsAAAAAAACAiYAAAAAAAIADgAAAAAAAgAKAAAAAAACAgAAAAAAAAIAKgAAAAAAAAAoAAIAAAACAgYAAgAAAAICAgAAAAAAAgAEAAIAAAAAACIAAgAAAAIA","f":{"keccak_f1600":0,"sha3_256":832},"r":[407,791,798]}' _
	)

	Local $tHash = DllStructCreate("byte[32]")

	If IsBinary($sString) Then
		Local $tBinary = DllStructCreate("byte[" & BinaryLen($sString) & "]")
		DllStructSetData($tBinary, 1, $sString)
	
		DllCallAddress("NONE",    $mCode.FuncPtr["sha3_256"], _
		               "STRUCT*", $tHash, _
		               "STRUCT*", $tBinary, _
		               "ULONG",   BinaryLen($sString))
	Else 
		DllCallAddress("NONE",    $mCode.FuncPtr["sha3_256"], _
		               "STRUCT*", $tHash, _
		               "STR",     $sString, _
		               "ULONG",   StringLen($sString))
	EndIf
	If @error Then Return SetError(1, @error, Null)

	Return DllStructGetData($tHash, 1)
EndFunc

Zitat von UEZ

Apropos testen:

Grandios! Die Lösung um eben doch sin/cos etc. im C-Code zu verwenden ist ja mal clever!
Damit erweitert sich die Einsatzmöglichkeit des ganzen enorm! Danke für diesen Ansatz.

Zitat von argumentum

Ich möchte, dass dieser Code (oder ein funktionierender Code) „sha3_256” hasht.
Ich brauche ihn, um die Datei „SQLite.zip” von ihrer Website zu hashen.
Kann das jemand von Ihnen erledigen? 👼

Das geht zumindest nicht mit dem gezeigten Code-Schnipsel. Siehe Abschnitt "Limitations" der Readme zur JIT.au3:

Zitat

Limitations

This UDF is designed for small, self-contained code snippets - not for full C projects.

• No #include support - the C standard library is not available. There is no linker; the code must be fully self-contained.
• No math.h functions - sin(), cos(), pow() etc. require libm which is not linked. Some GCC __builtin_* functions work as inline alternatives (see examples/example_builtins.au3).
• Internet required for compilation - use _JIT_LoadBinary to work offline after the first compile.
• Single translation unit - all code must be in one string, no multi-file compilation.

Es braucht also einen Code der keine #includes nutzt und spezielle Funktionen evtl. ebenso sparsam einsetzt (wie man das umgehen kann hat UEZ soeben gezeigt).

Zitat von Andy

Die "neuere" ist nur auf github, nicht in der Download-Datei

Tatsache! Bin noch neu in dem Metier - hab Releases bisher nicht genutzt. Muss halt dran denken das immer mit zu aktualisieren.
Sollte nun oben sein.

Kleine Abfrage: Aktuell ist in $mReturn.ptr der Pointer zum Code-Anfang. In $mReturn.Funcs stehen dann die einzelnen Offsets der Funktionen. Das hat zur Folge, dass man bei DllCallAdress beides für den Pointer braucht. Also z.B. sowas: DllCallAddress("double", $mCode.ptr + $mCode.Funcs["doubleIt"], "DOUBLE", 21.0)

Wenn man in .Funcs jedoch stattdessen die absoluten Pointer auf die Funktionen stehen hätte, dann könnte man sich das addieren sparen.
Ich denke daran, statt .Funcs zwei Maps zu verwenden: .FuncOffsets und .FuncPtr . Dann wäre der DllCallAddress-Aufruf schlanker und weniger fehleranfällig.
Was meint ihr dazu?

Ok ich habe soeben eine Änderung ins Repository gepusht: Die Binary-Strings im ReusableString sind ab sofort Base64-kodiert statt Hex-kodiert. Das macht sie kürzer was vor allem beim Einfügen in den Quellcode besser ist.
Wie gesagt: Dazu muss man aber die neueste Version verwenden.