Das Konsistenzproblem.
Ein numerisches Lernwerkzeug kann überzeugend wirken, obwohl zwei Implementierungen bei Intervallzahl, vorzeichenbehafteter Fläche oder ungültigen Funktionen unbemerkt voneinander abweichen. IntegraDraw hatte eine Java-Desktop-Vergangenheit und brauchte eine moderne Browserausgabe, ohne zu zwei getrennten Rechnern zu werden.
Der Neuaufbau macht den mathematischen Vertrag sichtbar: genau die verlangte Intervallzahl, vorzeichenbehaftete Ergebnisse, sichtbarer Näherungsfehler und klare Ablehnung nicht endlicher Eingaben.
Worin beide Laufzeiten übereinstimmen müssen.
Die Oberfläche ist nur nützlich, wenn die numerischen Regeln stabil bleiben:
- Mittelpunkt- und Trapezmethode verwenden genau die vom Benutzer eingegebene Segmentzahl.
- Negative Fläche bleibt negativ und wird nicht stillschweigend in geometrische Fläche umgewandelt.
- Der Vergleichswert heißt Simpson-Referenz, niemals exaktes symbolisches Ergebnis.
- Der Ausdrucksparser im Browser darf weder eval noch Function verwenden.
Ein Vertrag oberhalb der Implementierung.
Gemeinsamer Quellcode für Java und TypeScript würde eine unhandliche Laufzeitbrücke schaffen, ohne viel zu beweisen. Erwartetes Verhalten zu teilen ist die sinnvollere Grenze.
Ich habe einen versionierten Golden-Korpus eingeführt, den JUnit und Vitest verwenden. Laufzeitspezifische Toleranzen und Grenzen bleiben sichtbar, damit Abweichungen nicht hinter einem großzügigen Gleichheits-Helper verschwinden.
Zwei Oberflächen, ein numerischer Datensatz.
Die Java-Anwendung verpackt eine Swing-Oberfläche und den numerischen Kern als ausführbares JAR. Die Webanwendung verwendet einen abhängigkeitfreien Ausdrucksparser, TypeScript-Integrationsroutinen und einen responsiven Canvas-Plot. Beide prüfen sich gegen den gemeinsamen Korpus.
Entscheidungen für mathematische Klarheit.
Die Umgebung bezeichnet Näherung als Näherung.
Eine begrenzte Ausdruckssprache nutzen
Der Browser akzeptiert x, Konstanten, Arithmetik, Klammern und eine dokumentierte Funktionsmenge über einen eigenen Parser.
Das ist sicherer und verständlicher als beliebiges JavaScript, aber bewusst weniger ausdrucksstark.
Die Referenz korrekt benennen
Der Webvergleich verwendet die zusammengesetzte Simpson-Regel mit 8.192 Teilintervallen und nennt sie Referenz statt exaktes Ergebnis.
Einige unstetige oder nicht endliche Funktionen werden abgelehnt; das Projekt ist kein symbolisches Beweissystem.
Beobachtbares Verhalten gegenprüfen
Java- und TypeScript-Tests verwenden dieselben versionierten Fälle und halten ihre numerischen Toleranzen sichtbar.
Der Korpus muss bewusst weiterentwickelt werden, wenn sich der unterstützte mathematische Vertrag ändert.
Beide Anwendungen paketieren.
CI kompiliert Java 17, führt JUnit aus, paketiert und prüft das ausführbare JAR per Smoke-Test und typprüft, testet und baut anschließend die TypeScript-Anwendung. Release-Kandidaten enthalten außerdem Web-Bundle und SBOMs beider Laufzeiten.
Vor einem sichtbaren stabilen Release vergleicht die Veröffentlichung unabhängige Builds, validiert Abhängigkeitsinventare und prüft SHA-256-Manifeste sowie GitHub-Attestierungen.
Was die Umgebung sichtbar macht.
Benutzer können Funktion, Intervall und Segmentzahl ändern und sehen, wie Mittelpunkt- und Trapezschätzungen zur gezeichneten Kurve und Simpson-Referenz stehen.
Desktop- und Webanwendung bleiben unabhängig nützlich; der gemeinsame Korpus gibt Maintainern einen zentralen Ort für die Prüfung des versprochenen numerischen Verhaltens.
Evidenzprotokoll.
Der numerische Vertrag ist klein genug, um ihn vollständig aufzuzählen:
- Golden-Korpus
- Sechs Integralfälle, drei Fälle ungültiger Ausdrücke und sieben Validierungsfälle unter Schemaversion 1.
- Verifikation
- 22 JUnit- und 80 TypeScript-Testdeklarationen im auditierten Release.
- Referenz
- Der zusammengesetzte Simpson-Vergleich im Browser verwendet 8.192 Teilintervalle.
- Grenze
- Die Referenz ist nicht exakt; Unstetigkeiten und nicht endliche Ausdrücke können abgelehnt werden, und Laufzeitgrenzen unterscheiden sich absichtlich.