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:

  1. Mittelpunkt- und Trapezmethode verwenden genau die vom Benutzer eingegebene Segmentzahl.
  2. Negative Fläche bleibt negativ und wird nicht stillschweigend in geometrische Fläche umgewandelt.
  3. Der Vergleichswert heißt Simpson-Referenz, niemals exaktes symbolisches Ergebnis.
  4. 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.

Zwei Oberflächen, ein numerischer Datensatz. Die Implementierungen bleiben getrennt; ihr beobachtbarer numerischer Vertrag ist gemeinsam.SYSTEMANSICHT / INTEGRADRAWBENUTZERFUNKTIONSICHERER PARSERNUMERISCHERKERNGOLDEN-KORPUSJAVA +CANVAS UIVERSIONIERTER AUSLIEFERUNGSPFAD
Die Implementierungen bleiben getrennt; ihr beobachtbarer numerischer Vertrag ist gemeinsam.

Warum diese Technologien.

Die Entscheidungen halten beide Anwendungen eigenständig und teilen nur, was wirklich übereinstimmen muss.

T01 Die Entscheidung

Getrennte Implementierungen in Java und TypeScript.

Warum
Jede Oberfläche nutzt ihre natürliche Laufzeit, während ein externer Vertrag dasselbe numerische Verhalten vergleicht.
Was ich ausgeschlossen habe
Eine Sprachbrücke oder künstlich geteilter Quellcode würden Kopplung schaffen, ohne beobachtbare Parität zu belegen.
Der Preis dafür
Wir nehmen die Pflege zweier Implementierungen der Algorithmen in Kauf.
T02 Die Entscheidung

Ein begrenzter Mathematikparser.

Warum
Er bietet die benötigten Ausdrücke und hält Grammatik, Funktionen und Fehler kontrollierbar.
Was ich ausgeschlossen habe
eval oder Function würden beliebiges JavaScript ausführen und die Sicherheitsgrenze unprüfbar machen.
Der Preis dafür
Wir nehmen eine kleinere Sprache, aufgezählte Funktionen und ausdrückliche Fehler für nicht unterstützte Eingaben in Kauf.
T03 Die Entscheidung

Canvas für den Webplot.

Warum
Es ermöglicht eine responsive, leichte Darstellung ohne Abhängigkeiten und mit direkter Kontrolle über Maßstab und Pixel.
Was ich ausgeschlossen habe
Eine Diagrammbibliothek oder ein großer SVG-Baum würden Abhängigkeiten und unnötige DOM-Komplexität für eine einzelne Kurve einführen.
Der Preis dafür
Wir nehmen die eigene Umsetzung von Achsen, Skalierung, Neuzeichnen und Accessibility-Unterstützung rund um Canvas in Kauf.
T04 Die Entscheidung

Ein gemeinsamer Golden-Korpus.

Warum
Versionierte Fälle und Toleranzen vergleichen die tatsächlichen Ausgaben zweier unabhängiger Laufzeiten.
Was ich ausgeschlossen habe
Gemeinsamer Code wäre zwischen Java und TypeScript unnatürlich und könnte denselben Fehler in beide Oberflächen tragen.
Der Preis dafür
Wir nehmen die Pflege von Fällen, Toleranzen und Versionen in Kauf; der Korpus bleibt ein Test, kein formaler Beweis.

Entscheidungen für mathematische Klarheit.

Die Umgebung bezeichnet Näherung als Näherung.

D01

Das Vorzeichen des Integrals erhalten

Mittelpunkt- und Trapezmethode liefern orientierte Fläche: Umgekehrte Grenzen oder eine negative Funktion bleiben negativ, statt in geometrische Fläche umgedeutet zu werden.

Der ZielkonfliktDas Ergebnis kann überraschen, wenn stets positive Fläche erwartet wird, entspricht aber der mathematischen Bedeutung des bestimmten Integrals.

D02

Die Referenz korrekt benennen

Der Webvergleich verwendet die zusammengesetzte Simpson-Regel mit 8.192 Teilintervallen und nennt sie Referenz statt exaktes Ergebnis.

Der ZielkonfliktEinige unstetige oder nicht endliche Funktionen werden abgelehnt; das Projekt ist kein symbolisches Beweissystem.

D03

Die angeforderte Partition exakt einhalten

Numerischer Wert und Plot verwenden die vom Benutzer eingegebene Segmentzahl. Keine Laufzeit erhöht, senkt oder passt die Diskretisierung stillschweigend an.

Der ZielkonfliktEine sehr grobe Wahl erzeugt eine sichtbar grobe Näherung; das Produkt zeigt sie, statt sie im Hintergrund zu korrigieren.

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.

Geprüftes Release v1.1.2 Geprüft am

Was dieser Fall belegt

IntegraDraw ist ein exploratives Lernwerkzeug. Es bietet weder symbolische Integration noch Beweise, garantierte Behandlung von Unstetigkeiten oder ein exaktes Ergebnis für beliebige Funktionen.

Funktionierendes Projekt ansehen