Der zweiachsige Parameterraum: Warum der Großteil Ihres Sweeps nahezu kostenlos sein sollte
Teil der Serie "Backtests ohne Illusionen".
Der Fluch der Dimensionalität wird üblicherweise als Warnung erzählt: Jeder Parameter, den Sie hinzufügen, vervielfacht den Suchraum, sodass eine 18-dimensionale Strategie aussichtslos zu durchsuchen ist. Diese Darstellung setzt stillschweigend voraus, dass jede Dimension gleich viel kostet, um sie auszuwerten. Das tut sie nicht. In unserer Engine mit doppeltem/dreifachem Zeitrahmen sind zwei Drittel der Parameter fast kostenlos zu durchlaufen, und ein Drittel trägt im Wesentlichen die gesamte Rechenrechnung. Sobald Sie diese Aufteilung erkennen, ist "der Suchraum ist zu groß" nicht mehr die richtige Beschwerde. Die richtige Frage lautet: Welche Dimensionen bezahlen Sie eigentlich?
Die Dimension, die keine Neuberechnung brauchte
Unser Parametersuch-Benchmark führt eine Momentum-Strategie über mehrere Zeitrahmen aus: einen Hull-Moving-Average und seine dreifach geglättete Variante (HMA3) auf zwei oder drei Zeitrahmen, mit einem Richtungstrennungs-Gate, das entscheidet, wann ein Crossover "sauber" genug ist, um darauf zu handeln. Der vollständige Suchraum für die Triple-TF-Variante ist achtzehndimensional — je Zeitrahmen Periode und HMA-Länge, plus eine Reihe von Trennungsschwellen für Ein- und Ausstieg auf jedem Zeitrahmen.
Der naive Weg, dies zu durchlaufen, ist eine einzige Schleife: einen Parametervektor wählen, jeden Indikator von Grund auf neu aufbauen, die Simulation laufen lassen, bewerten, wiederholen. Damit haben wir angefangen. Es war langsam, und es war aus einem Grund langsam, der sich als peinlich herausstellte, sobald wir ihn benannt hatten: Bei der überwältigenden Mehrheit benachbarter Versuche berechneten wir Indikatoren neu, die sich nicht geändert hatten.
Verschieben Sie die Einstiegs-Trennungsschwelle von 0,03 auf 0,035 und starten Sie neu. Der Hull-MA über ein Jahr an 1-Minuten-Bars ist bit-für-bit identisch mit dem vorherigen Versuch — die Schwelle taucht nirgends in seiner Definition auf. Und doch baut die naive Schleife ihn trotzdem neu auf, über eine halbe Million Bars hinweg, drei Zeitrahmen tief, jedes einzelne Mal. Wir gaben nahezu unser gesamtes Rechenbudget dafür aus, Größen neu abzuleiten, die gegenüber dem Parameter, den wir tatsächlich variierten, invariant waren.
Diese Beobachtung ist der ganze Artikel. In dem Moment, in dem Sie bemerken, dass einige Parameter die Indikatoren verändern und einige nur die Entscheidungsregel verändern, die auf feste Indikatoren angewendet wird, hört der Parameterraum auf, eine flache Wolke von Dimensionen zu sein, und wird zu zwei verschachtelten Schichten mit wild unterschiedlichen Preisschildern.
Zwei Achsen, nicht eine

Teilen Sie die Parameter danach auf, was ihre Neubewertung Sie zur Neuberechnung zwingt:
-
Die teure Achse — Indikatorparameter. Zeitrahmenperiode und HMA-Länge. Ändern Sie eines von beiden, und Sie müssen den Indikator über die gesamte Preisreihe neu aufbauen: den höheren Zeitrahmen neu abtasten (resample), die Hull-Gewichtung ausführen, die Crossover-Reihe und die Trennung an jedem Crossover neu berechnen. Das ist ein O(n)-Durchlauf pro Bar der Historie, und Sie zahlen ihn voll für jede eindeutige Kombination. In der Triple-TF-Strategie hat diese Achse sechs Parameter:
(period, hma_length)für jeden der hohen, mittleren und niedrigen Zeitrahmen. -
Die billige Achse — Entscheidungsschwellen. Die Richtungstrennungs-Gates, die anhand der bereits berechneten Crossover- und Trennungsreihen entscheiden, ob ein- oder ausgestiegen wird. Ändern Sie eine Schwelle, und kein Indikator bewegt sich. Sie führen lediglich einen einzigen O(n)-Durchlauf über die vorberechneten Signale erneut aus, prüfen die Gates und verbuchen Fills. In der Triple-TF-Strategie hat diese Achse zwölf Parameter (vier Trennungsschwellen — entry-buy, entry-sell, exit-buy, exit-sell — auf jedem der drei Zeitrahmen). Die Dual-TF-Variante hat acht (vier Schwellen auf jedem von zwei Zeitrahmen).
Die tatsächliche Form des Raums ist also: 6 teuer + 12 billig = 18 für Triple-TF und 4 teuer + 8 billig = 12 für Dual-TF. Zwei Drittel der Dimensionalität liegen auf der billigen Achse. Und die beiden Achsen unterscheiden sich nicht nur in der Anzahl — sie unterscheiden sich in den Stückkosten um mehr als drei Größenordnungen, und genau um diese Zahl geht es im Rest dieses Artikels.
Die Struktur ist strikt verschachtelt. Jeder Punkt auf der teuren Achse — ein konkretes (period, hma_length) pro Zeitrahmen — definiert eine Menge fester Signalarrays. Auf diesem festen Fundament sitzt eine ganze Fläche der billigen Achse: Tausende von Schwellenvektoren, jeder ein schneller Durchlauf über dieselben Arrays. Sie zahlen einmal für das Fundament und amortisieren es über die gesamte Fläche.
Warum Indikatoren gegenüber Schwellen invariant sind
Das Caching funktioniert nur wegen einer mathematischen Tatsache, nicht wegen eines glücklichen Implementierungsdetails, und es lohnt sich, das präzise festzuhalten, weil es die tragende Annahme ist. Die Indikatorarrays sind eine Funktion von (period, hma_length) allein. Die Trennungsschwellen tauchen nirgends in ihrer Definition auf.
Konkret berechnet die Engine für jeden Zeitrahmen vier ausgerichtete Arrays über den Basisindex vor: den Hull-MA hma, seine dreifach geglättete Version hma3, die Crossover-Reihe cross (+1 buy / −1 sell / 0) und den separation-Prozentsatz an jedem Crossover. Jedes davon wird aus Preisen und den beiden Indikatorparametern abgeleitet. Die Schwelle — die Zahl, mit der Sie separation vergleichen — wird später angewendet, zum Entscheidungszeitpunkt. Sie berührt die Arrays nie.
Das ist keine trivial sichere Umstellung. Sie ist nur sicher, weil wir sorgfältig darauf geachtet haben, wann Informationen verfügbar werden, was das Anliegen der Arbeit zum Look-ahead-Bias an anderer Stelle in dieser Serie ist. Der Indikator des höheren Zeitrahmens auf Basis-Bar i wird aus geschlossenen Kerzen des höheren TF plus einer sich bildenden Kerze berechnet, deren laufender Schlusskurs dem aktuellen Basis-Schlusskurs close[i] entspricht — ein Wert, der zum Bar i bekannt ist. Nichts aus der Zukunft sickert ein. Das vorberechnete Signal zum Bar i ist also genau das, was ein Live-Bot zum Bar i gesehen hätte, und es bleibt gültig, egal welche Schwelle Sie später dagegen testen. Ein undichtes Signal zu cachen würde nur das Leck cachen; ein kausales Signal zu cachen cacht etwas, das Sie tatsächlich handeln können.
Die Invarianz gibt uns eine Faktorisierung. Schreiben Sie die Auswertung eines vollständigen Parametervektors θ = (indicator_params, threshold_params) als:
signals = build_indicators(indicator_params) # EXPENSIVE, depends only on indicator_params
score = simulate(signals, threshold_params) # CHEAP, reuses signals across all thresholds
build_indicators liest threshold_params nicht. Diese eine Tatsache ist es, die den Cache lizenziert: Halten Sie indicator_params fest, variieren Sie threshold_params frei, und signals ist eine Konstante, die Sie einmal berechnen.
Die Architektur: einmal berechnen, vielfach durchlaufen

Die Engine (scripts/engine_multitf.py, Commit bfc8aaa in unserem Backtester) implementiert die Faktorisierung mit zwei Bausteinen, deren Namen genau sagen, was sie tun.
SignalCache — die teure Achse, memoisiert. Es ist ein Dictionary, indiziert nach (period_bars, hma_length). Fragen Sie es nach den Signalen eines Zeitrahmens, und es gibt die gecachten TFSignals zurück, falls diese Indikatorkombination zuvor aufgebaut wurde, andernfalls baut es sie einmal auf und speichert sie. Da der Schlüssel nur die Indikatorparameter sind, trifft jede Schwellenkonfiguration, die eine Indikatorkombination teilt — und in einem dichten Schwellen-Sweep sind das Tausende davon —, denselben Cache-Eintrag. Besonders die höheren Zeitrahmen belohnen dies: Ein grobes Gitter aus, sagen wir, vier Kandidatenperioden mal einer Handvoll HMA-Längen ist eine kleine Zahl eindeutiger teurer Aufbauten, und jeder wird über die gesamte darauf gestapelte Schwellenfläche wiederverwendet.
sweep_separations — die billige Achse, gebündelt. Es nimmt die gecachten Signalarrays und eine Matrix von Schwellenvektoren (sps, Form [m, 12]) und lässt sie alle durch einen einzigen kompilierten Kernel laufen. Jede Zeile ist ein O(n)-Durchlauf: durch die Bars gehen, die Gates anwenden, leckfreie Fills bei open[i+1] verbuchen, PnL und Zeit-in-Position summieren. In dieser Schleife wird kein Indikator neu aufgebaut — sie liest cross und separation direkt aus dem Cache. Die innere Simulation ist JIT-kompiliert (Numba), sodass nach dem Aufwärmen die Kosten pro Konfiguration vom einzigen linearen Scan über die Bars dominiert werden, nicht vom Python-Overhead.
Die beiden Bausteine setzen sich zur natürlichen verschachtelten Suche zusammen: Die äußere Schleife durchläuft die teure Achse (jede Iteration baut eine Indikatorkombination auf und cacht sie), und die innere Schleife fächert einen breiten Batch über die billige Achse auf diesen gecachten Arrays auf. Im Code hat es genau diese Form — eine kleine teure Schleife, die einen breiten billigen Batch umschließt:
cache = SignalCache(base_close, base_ts) # keyed by (period, hma_length)
for htf_p, htf_h, mtf_p, mtf_h, ltf_p, ltf_h in indicator_grid: # EXPENSIVE axis (coarse)
htf = cache.get(htf_p, htf_h) # built once, then a cache hit forever
mtf = cache.get(mtf_p, mtf_h)
ltf = cache.get(ltf_p, ltf_h)
sps = sample_thresholds(m=4000) # CHEAP axis: [m, 12] threshold vectors
pnl, n_trades, bars_in_pos = sweep_separations( # one compiled batch, no indicator work
base_close, base_open, htf, ltf, sps, mtf=mtf)
Sie berühren den teuren Builder so selten, wie es das Indikatorgitter erlaubt, und Sie lassen den billigen Sweep die Masse erledigen — Tausende von sps-Zeilen gegen Arrays, die sich nie bewegen. Das ist die gesamte Optimierung — keine Approximation, kein Verlust an Genauigkeit, nur die Weigerung, neu zu berechnen, was sich nicht geändert hat.
Was "kostenlos" tatsächlich kostet: die Zahlen

Wir haben die beiden Achsen an der Demo-Arbeitslast gemessen: ein volles Jahr an 1-Minuten-ETHUSDT-Bars (~527k Bars), Triple-TF, Indikatoren aufgewärmt und JIT-kompiliert außerhalb der Zeitmessung.
Auf der billigen Achse hält sweep_separations ~5.600 Schwellenkonfigurationen pro Sekunde aufrecht. Das ist eine vollständige Simulation — Gates, Fills, PnL, Exposure — für jede Konfiguration, über eine halbe Million Bars, bei etwa 180 Mikrosekunden pro Konfiguration. Der Grund, warum es so schnell sein kann, ist, dass es keinerlei Indikatorarbeit leistet: Jede Konfiguration liest dieselben gecachten cross- und separation-Arrays.
Bepreisen Sie nun die Alternative. Den Triple-TF-Indikatorsatz einmal aufzubauen dauert in der Größenordnung von einigen hundert Millisekunden (~0,3 s) — drei Zeitrahmen neu abtasten, Hull-Gewichtung, Crossover- und Trennungsextraktion über das gesamte Jahr. Würden Sie Indikatoren innerhalb der Konfigurationsschleife neu berechnen — das naive Single-Loop-Design —, würde jede dieser 5.600 Konfigurationen pro Sekunde stattdessen den vollständigen Indikatoraufbau bezahlen. Die Kosten pro Konfiguration schnellen von ~180 Mikrosekunden auf ~0,3 Sekunden hoch:
| Kosten pro Konfiguration | Konfigurationen/s | |
|---|---|---|
| Billige Achse (gecachte Signale) | ~180 µs | ~5.600 |
| Indikatoren pro Konfiguration neu berechnen | ~0,3 s | ~3,4 |
Das Verhältnis ist ~1.600x. Die billige Achse auf gecachten Signalen zu durchlaufen ist etwa drei Größenordnungen billiger als das naive Design, das die Indikatoren für jeden Schwellenvektor neu aufbaut. Konkret: Ein Batch von einigen tausend Schwellenkonfigurationen, der auf dem gecachten Pfad in unter einer Sekunde fertig wird, würde den größten Teil einer Stunde dauern, wenn jede Konfiguration ihre Indikatoren neu aufbaute. Gleiche Ergebnisse, gleiche Genauigkeit, keine Abkürzungen in der Mathematik — der einzige Unterschied ist, dass eines von beiden eine Invariante neu berechnet und das andere nicht.
Das ist keine Mikrooptimierung, die Sie am Ende obendrauf streuen. Es verändert, welche Suchen machbar sind. Bei 5.600 cfg/s ist die Schwellenachse dicht genug, um sie ordentlich zu erkunden — Sie können sich pro Indikatorkombination ein feines Gitter oder eine lange Zufalls-/QMC-Stichprobe leisten —, während die teure Achse eine bewusst grobe Handvoll Aufbauten bleibt. Das Rechenbudget fließt dorthin, wo die Parameter tatsächlich etwas kosten.
Der Fluch der Dimensionalität, neu bewertet

Kehren wir zu der Darstellung zurück, mit der dieser Artikel begann. Der Fluch der Dimensionalität besagt, dass der Suchraum exponentiell mit der Anzahl der Parameter wächst, sodass mehr Dimensionen kategorisch schlechter sind. Das stimmt über die Größe des Gitters. Es ist irreführend über die Kosten, es abzudecken, weil es jede Dimension identisch bepreist.
Sobald Sie die Achsen trennen, liest sich die Anzahl anders. Die Triple-TF-Strategie ist 18-dimensional, aber nur 6 dieser Dimensionen sind teuer. Die anderen 12 sind Dimensionen der billigen Achse, die das Gitter vergrößern, ohne die Rechenrechnung in nennenswerter Weise zu vergrößern — Sie können Tausende von Konfigurationen für ein paar Cent darauf werfen. Die Dual-TF-Strategie ist 12-dimensional mit nur 4 teuren Dimensionen und 8 billigen. In beiden Fällen konzentriert sich der Großteil des "Fluchs" auf die Achse, deren Durchlaufen fast nichts kostet.
Der ehrliche Weg, über Suchkosten nachzudenken, lautet also nicht "wie viele Parameter", sondern "wie viele teure Parameter, und wie grob darf ihr Gitter sein". Die teure Achse ist die, wo das Exponentielle tatsächlich wehtut, und sie ist die, wo Sie ein kleines, gut gewähltes Gitter wollen — ein paar Kandidatenperioden, eine bescheidene Spanne von HMA-Längen — möglicherweise grob-zu-fein verfeinert, im Geiste des adaptiven Auflösungs-Drill-downs, den wir an anderer Stelle verwenden. Die billige Achse ist die, wo Sie verschwenderisch sein können, weil jede zusätzliche Schwellenkonfiguration 180 Mikrosekunden kostet.
Diese Neubewertung verallgemeinert sich weit über unsere HMA-Strategie hinaus. Das Muster — einige Parameter verändern die Merkmale, die meisten Parameter verändern die auf feste Merkmale angewendete Regel — kehrt überall im systematischen Handel wieder. Indikatorlängen, Resampling-Frequenzen und Lookback-Fenster sind teuer; Ein-/Ausstiegsschwellen, Stop-Abstände, Positionsgrößen-Multiplikatoren und Bestätigungs-Gates sind billig. Immer wenn ein Parameter nur die Entscheidungsgrenze über bereits berechnete Signale umformt, gehört er auf die billige Achse und sollte dort durchlaufen werden. Verwandte Caching-Gewinne aus derselben Familie zeigen sich im Multi-Timeframe-Parquet-Caching und in der breiteren Geschwindigkeitsleiter der Engine.
Wo das kostenlose Mittagessen eine Rechnung hat
Die billige Achse ist billig in Rechenleistung. Sie ist nicht billig in Statistik, und die beiden zu verwechseln ist der Weg, wie Sie einen Performance-Gewinn in eine Overfitting-Maschine verwandeln.
Jede Schwellenkonfiguration, die Sie auswerten, ist ein Versuch, und wenn Sie Tausende von Versuchen auf einem Datensatz durchführen, sieht der beste von ihnen teilweise durch Glück gut aus. Diese Versuche 1.600-mal billiger zu machen lässt das Glück nicht verschwinden — es macht es leichter, es anzuhäufen. Ein dichter Schwellen-Sweep ist genau die Situation, in der die Multiple-Testing-Inflation am härtesten zubeißt: viele Kandidaten, eine Historie und eine Auswahlregel, die das Maximum meldet. Die schnellste Engine der Welt reicht Ihnen bereitwillig einen Schwellenvektor, der das Rauschen Ihres Testfensters wunderschön fittet und out of sample versagt.
Die Disziplin muss also mit der Geschwindigkeit skalieren. In dem Moment, in dem die Rechenkosten eines Versuchs gegen null gehen, wird die statistische Verrechnung zur bindenden Randbedingung, und Sie müssen sie explizit bezahlen:
- Deflationieren Sie für die Versuchsanzahl. Bewerten Sie den Gewinner gegenüber der Anzahl der Konfigurationen, die Sie ausprobiert haben, nicht gegenüber null. Die Deflated Sharpe Ratio und die Wahrscheinlichkeit von Backtest-Overfitting existieren genau dafür — sie verwandeln "wir haben 4.000 Schwellenvektoren ausprobiert" in einen Abschlag auf die gemeldete Edge.
- Validieren Sie out of sample, pro Fold. Ein billiger Sweep muss trotzdem innerhalb einer ehrlichen Walk-Forward-Aufteilung laufen; eine Schwelle, die nur in-sample gewinnt, ist wertlos, egal wie schnell Sie sie gefunden haben. Unsere Engine hält die Fills leckfrei (
open[i+1]), gerade damit die billige Achse keine Performance durch Vorausschau erkaufen kann. - Bevorzugen Sie Plateaus gegenüber Gipfeln. Weil die Schwellenachse dicht und schnell ist, können Sie ihre Antwortoberfläche kartieren, nicht nur ihr Argmax. Eine breite Region von Schwellen, die alle funktionieren, ist eine echte Edge; ein einzelnes spitzes Maximum ist ein gefittetes Artefakt — die Plateau-vs-Gipfel-Unterscheidung, erschwinglich gemacht durch genau die Geschwindigkeit, die wir beschreiben.
Lesen Sie die zweiachsige Struktur richtig: Sie kauft Ihnen nicht mehr Vertrauen, sie kauft Ihnen mehr Versuche bei gleichbleibenden Vertrauenskosten pro Versuch. Das ist echt wertvoll — die dichte Abdeckung der billigen Achse ist es, die Sie Plateaus finden und die Oberfläche charakterisieren lässt —, aber nur, wenn Sie das statistische Hauptbuch ehrlich halten. Geschwindigkeit nimmt die Rechenausrede dafür weg, nicht gründlich zu suchen; sie nimmt nicht die Verpflichtung weg, das abzuzinsen, was gründliches Suchen findet.
Wie Sie Ihre eigene Suche strukturieren
Um dies auf Ihre eigene Strategie anzuwenden, besteht die Arbeit größtenteils aus Klassifikation — dem Sortieren Ihrer Parameter auf die richtige Achse — gefolgt von einer verschachtelten Schleife:
- Beschriften Sie jeden Parameter danach, was er Sie zur Neuberechnung zwingt. Ändert seine Änderung ein Indikator-/Merkmalsarray, ist er teuer. Ändert er nur einen Vergleich, eine Schwelle oder eine Größenregel, die auf feste Arrays angewendet wird, ist er billig. Im Zweifelsfall fragen Sie: Taucht dieser Parameter irgendwo in der Definition des Indikators auf? Wenn nicht, ist er billig.
- Indizieren Sie einen Cache nur nach der teuren Achse. Memoisieren Sie die Merkmalskonstruktion nach ihren Indikatorparametern (wie
SignalCachees nach(period, hma_length)tut). Benachbarte Versuche, die eine Indikatorkombination teilen, verwenden dann dieselben Arrays kostenlos wieder. - Bündeln Sie die billige Achse über gecachte Merkmale. Führen Sie Schwellenkonfigurationen als eng kompilierte Schleife über die vorberechneten Signale aus, nicht als vollständige Neuauswertungen. Von hier kommt Ihr Durchsatz — und in unserem Fall die ~5.600 cfg/s.
- Verschachteln Sie die Schleifen: teuer außen, billig innen. Halten Sie das teure Gitter klein und bewusst (grob oder grob-zu-fein); lassen Sie den billigen Sweep dicht sein. Geben Sie das Budget dort aus, wo die Parameter etwas kosten.
- Budgetieren Sie Versuche gegen Overfitting, nicht gegen die Uhr. Da die Uhr nun nicht mehr die Grenze ist, lassen Sie die Deflated Sharpe / PBO die Grenze sein. Entscheiden Sie, wie viele Versuche der billigen Achse Sie sich statistisch leisten können, und validieren Sie den Gewinner out of sample.
Der Engineering-Ertrag und das statistische Schutzgeländer sind zwei Seiten einer Idee: Das Trennen der Achsen lässt Sie die billigen Dimensionen erschöpfend durchsuchen, was genau der Grund ist, warum Sie dann abzinsen müssen, wie erschöpfend Sie gesucht haben.
Erkenntnisse
- Nicht alle Dimensionen kosten gleich viel. Die Parameter einer Strategie teilen sich auf in eine teure Achse (Indikatoren — über die gesamte Reihe neu berechnet) und eine billige Achse (Schwellen — ein O(n)-Durchlauf über vorberechnete Signale). In unserer Engine sind das 6 teuer + 12 billig für Triple-TF, 4 + 8 für Dual-TF.
- Indikatoren sind gegenüber Schwellen invariant, und diese Invarianz ist die gesamte Optimierung. Die Merkmalskonstruktion hängt nur von den Indikatorparametern ab, also bauen Sie einmal auf, cachen nach
(period, hma_length)und verwenden über jede Schwellenkonfiguration wieder, die die Kombination teilt. - Die billige Achse läuft ~1.600x billiger. ~5.600 Schwellenkonfigurationen/s (~180 µs je) auf gecachten Signalen, gegenüber ~0,3 s pro Konfiguration, wenn Sie die Indikatoren jedes Mal neu aufbauen. Gleiche Genauigkeit — der einzige Unterschied ist die Weigerung, eine Invariante neu zu berechnen.
- Der Fluch der Dimensionalität ist in Wirklichkeit ein Fluch der teuren Dimensionalität. Der Großteil der Parameteranzahl liegt auf der Achse, deren Durchlaufen nahezu kostenlos ist. Halten Sie das teure Gitter grob; seien Sie verschwenderisch auf dem billigen.
- Geschwindigkeit verschiebt die bindende Randbedingung von der Rechenleistung zur Statistik. Ein dichter, schneller Sweep ist eine Multiple-Testing-Maschine. Deflationieren Sie für die Versuchsanzahl, validieren Sie pro Fold und bevorzugen Sie Plateaus gegenüber Gipfeln — das kostenlose Mittagessen ist echt, aber die statistische Rechnung ist nicht optional.
Die vollständige Engine — SignalCache, sweep_separations, die leckfreie Multi-TF-Simulation und der Paritätstest, der sie an die Semantik der laufenden Live-Kerze bindet — lebt in scripts/engine_multitf.py (Commit bfc8aaa) in unserem Backtester. Wenn Ihnen das nächste Mal jemand sagt, eine 18-Parameter-Strategie sei zu groß zum Durchsuchen, fragen Sie ihn, wie viele dieser Parameter die Indikatoren tatsächlich bewegen. Meistens ist es ein Drittel davon, und der Rest ist nahezu kostenlos.
Authors
Trading-systems engineer
Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.