docs: remove the whitepaper folder
Drops docs/whitepaper/ (Bevy ECS visualizer concept). The evaluation against the design ledger found it re-litigates the settled web-from-disk visual-face fork (#101/#192/#209) on incorrect premises; the salvageable ideas (on-demand trace slices, sweep-surface heatmaps, param-binding-path highlighting) belong in the tracker, not a side doc.
This commit is contained in:
@@ -1,66 +0,0 @@
|
||||
# Whitepaper: Next-Generation Visualisierung für Aura mit Bevy und ECS
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
Aura ist als "Game Engine für Trader" konzipiert und generiert bei umfangreichen Backtests (Sweeps, Monte-Carlo-Simulationen, Walk-Forward-Analysen) massive Datenmengen. Klassische Visualisierungsmethoden – wie statische 2D-Graphen via Python oder standardisierte Web-Charting-Bibliotheken (D3.js, Plotly) – stoßen bei diesen Datenvolumina schnell an ihre Leistungsgrenzen und limitieren den Erkenntnisgewinn auf vordefinierte, aggregierte Ansichten.
|
||||
|
||||
Dieses Whitepaper skizziert ein Konzept für einen dedizierten, hochperformanten **Aura Execution Viewer & Trace Explorer**, basierend auf der Rust-Game-Engine **Bevy**. Durch die konsequente Nutzung eines Entity-Component-Systems (ECS) und der Hardwarebeschleunigung via GPU (WebGPU/WebGL2) wird ein Paradigmenwechsel angestrebt: Vom passiven Betrachten statischer Berichte hin zur interaktiven, räumlichen Erkundung (3D/2D) multidimensionaler Strategie-Landschaften – vollständig auslieferbar als Web-Applikation im Browser.
|
||||
|
||||
## 2. Motivation und Problemstellung
|
||||
|
||||
Die Kernfunktionalität von Aura (deterministische Dataflow-Graphen, Structure-of-Arrays-Layouts) erlaubt es, Millionen von Ticks und Tausende von Parameterkombinationen in kürzester Zeit zu berechnen.
|
||||
|
||||
Das Problem der nachgelagerten Analyse ist zweischneidig:
|
||||
1. **Makro-Analyse (Das Wald-Problem):** Ein Parameter-Sweep über 4 Dimensionen produziert zehntausende Ergebnisse (Runs). Die Identifikation von stabilen Parameter-Plateaus (Robustheit) im Gegensatz zu isolierten Peaks (Overfitting) ist in tabellarischer oder klassischer Heatmap-Form (die auf 2D beschränkt ist) visuell kaum fassbar.
|
||||
2. **Mikro-Analyse (Das Bäume-Problem):** Das Analysieren eines einzelnen Runs erfordert oft den sofortigen "Drill-Down" in hochaufgelöste Zeitreihendaten (`taps`: Equity-Kurve, Trades, Bias, rohe Tick-Daten). Das Laden von Gigabytes an Rohdaten überlastet herkömmliche Web-DOMs sofort.
|
||||
|
||||
Es wird ein Visualisierungssystem benötigt, das architektonisch in der Lage ist, riesige Datensätze verlustfrei zu handhaben und dabei visuelles Feedback in Echtzeit (60+ FPS) zu liefern.
|
||||
|
||||
## 3. Die Lösung: Bevy und das Entity-Component-System (ECS)
|
||||
|
||||
Game Engines, insbesondere solche mit ECS-Architektur wie Bevy, sind prädestiniert für diese Aufgabe. In einem ECS existieren keine tiefen, schwerfälligen Vererbungshierarchien (OOP), sondern flache Listen von Entitäten, die aus Daten-Komponenten bestehen und von Systemen parallelisiert verarbeitet werden.
|
||||
|
||||
Da Aura intern bereits auf einem datenorientierten Layout (SoA) aufbaut, lässt sich das Aura-Datenmodell (`CampaignRunRecord`, `RunMetrics`, Time-Series `taps`) nahezu ohne Reibungsverluste in die ECS-Welt überführen.
|
||||
|
||||
### 3.1 Konzept 1: Die "Sweep Galaxy" (Makro-Ebene 3D)
|
||||
Anstatt durch dutzende 2D-Heatmaps zu blättern, wird ein Sweep als interaktive 3D-Punktewolke gerendert (Particle System).
|
||||
* **Entity:** Ein einzelner Backtest-Run.
|
||||
* **Mapping:**
|
||||
* X/Y/Z-Achsen = Strategie-Parameter (z.B. SMA-Länge, Risk, Stop-Loss).
|
||||
* Farbe/Licht (Shader) = Profitabilität (`expectancy_r`, Netto R).
|
||||
* Größe = Signifikanz (`sqn`).
|
||||
* Transparenz/Pulsieren = Risiko des Overfittings (`overfit_probability`).
|
||||
* **Analytischer Wert:** Der Analyst "fliegt" durch die Parameterlandschaft und sucht nach dichten, leuchtenden Sternenclustern (robuste Parameter-Plateaus) anstatt nach isolierten Pixeln (Glückstreffer). Dank *Instanced Rendering* zeichnet Bevy Millionen solcher Punkte mühelos.
|
||||
|
||||
### 3.2 Konzept 2: Der interaktive "Walk-Forward Tunnel"
|
||||
Um die Stabilität einer Strategie über verschiedene Zeitepochen (Regimes) zu bewerten, wird die Zeit als Tiefe dargestellt.
|
||||
* **Darstellung:** Ein 3D-Tunnel, in dem jeder Z-Abschnitt ein "Rolling Window" (z.B. ein Jahr) darstellt. Die X/Y-Flächen auf jedem Abschnitt zeigen die Performance-Landschaft dieses Fensters.
|
||||
* **Interaktion:** Ein leuchtender Spline verbindet den besten Parametersatz durch alle Zeitfenster. Bleibt der Pfad gerade, ist die Strategie stabil. Springt er wild umher ("Regime-Hopping"), ist die Strategie für den Live-Handel untauglich.
|
||||
|
||||
### 3.3 Konzept 3: Das "Trace-Mikroskop" mit stufenlosem LoD
|
||||
Für den Drill-Down in einen spezifischen Run wird ein Google-Earth-artiger Zoom implementiert, gesteuert durch strenges ECS-Culling.
|
||||
* **Level of Detail (LoD):** Aus der Vogelperspektive ist nur eine aggregierte Linie (die makroskopische Equity-Kurve) sichtbar.
|
||||
* **Culling:** Sobald der Nutzer in einen Drawdown zoomt, feuern ECS-Systeme. Sie berechnen Frustum Culling und aktivieren die `Visibility`-Komponente von Kerzen (Candlesticks) und Entry/Exit-Markern nur für exakt den sichtbaren Viewport.
|
||||
* Dadurch bleiben UI und Rendering trotz Milliarden potenzieller Datenpunkte in der Szene flüssig.
|
||||
|
||||
## 4. Architektur und Browser-Bereitstellung (WASM)
|
||||
|
||||
Ein entscheidender Vorteil von Bevy und Rust ist die Portabilität. Der Visualizer muss keine lokale, schwergewichtige Desktop-Installation sein. Er kann als Web-Applikation bereitgestellt werden.
|
||||
|
||||
### 4.1 Der Tech-Stack
|
||||
* **Frontend (WASM-Client):** Die Bevy-Anwendung, kompiliert nach `wasm32-unknown-unknown`. Die Grafik wird über `wgpu` (WebGL2 oder zukünftig WebGPU) direkt auf das HTML-Canvas gerendert.
|
||||
* **UI:** Die Steuerung (Slider, Tabellen, Filter) wird über `bevy_egui` im Immediate Mode direkt in den Render-Loop der Game-Engine integriert, was die Interaktion mit dem HTML-DOM umgeht und maximale Performance garantiert.
|
||||
* **Backend (API-Server):** Ein leichtgewichtiger Rust-Server (z.B. via Axum), der auf dem Dateisystem von Aura (`/runs`) operiert.
|
||||
|
||||
### 4.2 Daten-Streaming-Strategie
|
||||
Da Browser durch Speicher- und Netzwerklimits beschränkt sind, erfolgt das Laden asynchron:
|
||||
1. **Makro-Daten (Thin-First):** Beim Starten einer Analyse überträgt der Server lediglich die aggregierten Metadaten (`RunMetrics`, `FamilySelection`) aller Runs. Dies sind wenige Megabytes, die der WASM-Client im RAM hält, um das flüssige 3D-Filtern im ECS zu ermöglichen.
|
||||
2. **Mikro-Daten (On-Demand):** Zoomt der Nutzer in das "Trace-Mikroskop", fordert der Client via API punktgenau Daten-Slices (`taps`) für das spezifische Zeitfenster an. Der Server liest extrem schnell aus Auras Ringpuffern und sendet nur die benötigen Payload-Größen.
|
||||
|
||||
## 5. Conclusion
|
||||
|
||||
Die Integration der Game-Engine Bevy als Visualisierungsschicht für Aura stellt eine konsequente Fortführung der Projektphilosophie ("Game Engine für Trader") dar.
|
||||
|
||||
Die architektonische Nähe beider Systeme (Rust, datenorientiertes Design) erlaubt eine reibungslose Symbiose. Durch den Wechsel von traditionellen 2D-Charts hin zu GPU-beschleunigten, dreidimensionalen ECS-Szenen wird es möglich, Datenmengen kognitiv zu erfassen, die bisher im Rauschen untergingen.
|
||||
|
||||
Gleichzeitig wird durch die Bereitstellung als WASM/WebGPU-Applikation die Zugänglichkeit gewahrt, da Analysen und interaktive "Playgrounds" unkompliziert über den Webbrowser geteilt und konsumiert werden können. Dies positioniert das Aura-Ökosystem an der Spitze moderner, quantitativer Analysetools.
|
||||
Reference in New Issue
Block a user