Veröffentlicht
Jede Konfiguration in meiner Backtest-Datenbank protokolliert drei Möglichkeiten, wie ein Trade enden kann: Er erzielt Take-Profit, er erreicht einen Stop oder er läuft die Uhr in einem harten Time-Stop aus, ohne beides zu tun. Ich hatte diese dritte Zahl größtenteils ignoriert, time_stop_rateund behandelte es als Nebenwirkung von allem, was sonst noch vor sich ging. Dann habe ich alle 12.331 Konfigurationen danach sortiert. Die Gewinnrate fällt fast geradlinig, wenn die Time-Stop-Rate steigt. Der Profitfaktor bewegt sich kaum. Zwei Ergebnismetriken, eine Eingangszahl, zwei völlig unterschiedliche Antworten.
Die Gewinnrate sinkt von oben nach unten um fast 30 Punkte
| Zeitstopprate | Konfigurationen | Durchschn. Gewinnrate | Gewinnfaktor | Top-Kandidaten-Flaggen |
|---|---|---|---|---|
| 0-10% | 2.785 | 76,3 % | 2,03 | 47 |
| 10–20 % | 2'078 | 6. | 1.23 | 3 |
| 20–30 % | 1,892 | 67,0% | 1.13 | 0 |
| 30-40% | -2.013 | 64,9% | 1,09 | 0 |
| 40–50 % | 1.710 | 61,2% | 1.04 | 0 |
| 50-60 % | 894 | 57,9% | 1.02. | 0 |
| 60 % – 70 % | 515 | 2. | 0,98 | 0 |
| 70 | 444 | 48,0 Prozent | 1,11 | 0 |
Das sind 76,3% auf 48,0%, ein Rückgang der durchschnittlichen Gewinnrate um 28,3 Punkte von der niedrigsten Time-Stop-Bucket auf die höchste, über acht Buckets, die sich jedes Mal in die gleiche Richtung bewegen. Formal ist es eine -0,41 Pearson-Korrelation zwischen time_stop_rate Und wr across all 12,331 configs -- moderate, not perfect, but far from noise. Net profit correlates even harder, at -0.52. The top-candidate flag makes the same point in a cleaner form: 47 of my 50 flagged configs sit in the 0-10% bucket, the rest in 10-20%. Not one top candidate exists past a 20% time-stop rate. The exact range across all 50 flagged configs is 0.12% to 16.69%, averaging 4.13%. A config where more than one in six trades just times out, waiting for a move that never comes, has never once earned my top-candidate flag.
Profitfaktor ist egal
Folgendes habe ich nicht erwartet. Führen Sie die gleiche Korrelation gegen pf den Familiennamen wr and you get -0.04 -- statistically nothing. Look at the table again: profit factor drifts from 2.03 down to roughly 1.0 across most of the range, but then the 70%+ bucket, the worst win-rate bucket of all, actually ticks back up to 1.11. A config can time out on most of its trades and still hold a perfectly respectable profit factor, as long as the trades that do resolve on their own resolve well. Win rate measures how often you're right. Profit factor measures what you make when you are, against what you lose when you aren't. A high time-stop rate wrecks the first number by definition -- a timeout isn't a win -- but says almost nothing about the second, because it's silent on the size of the trades that didn't time out.
Ich überprüfte, ob dies nur "irgendeine Ausstiegsgrundrate prognostiziert Ergebnisse" war, indem ich den gleichen Bucket-Test auf fi_rate, the rate at which a trade exits on a final invalidation stop. No clean pattern: win rate bounces between 64.0% and 70.0% across its five buckets with no consistent direction, and the top-candidate flags don't concentrate at either end the way they do for time-stop rate. Not every exit-reason column is a hidden predictor. This one specifically is, because a time-stop is really a measurement of how often the entry thesis simply failed to play out in either direction -- a different kind of signal than a stop-loss, which measures how often it played out against you.
Was sich daran ändert, wie ich eine Konfiguration lese
Zur Behandlung von: time_stop_rate als Tiebreaker, etwas, das man sich ansehen sollte, nachdem die Gewinnrate und der Gewinnfaktor bereits die Geschichte erzählt haben. Ich werbe dafür. Wenn ich eine neue Charge von Konfigurationen scanne und einen einzelnen frühen Filter möchte, bevor ich die vollständige GOOD_FOR_DEEP_TEST/is_top_candidate pipeline on all of them, sorting by time-stop rate and cutting anything above 20% would have discarded every single config that never produced a flag anyway -- without needing the rest of the pipeline to tell me so. What it won't do is tell me whether a low-time-stop config is actually profitable; for that I still need profit factor, because the two numbers are measuring different failure modes and one doesn't substitute for the other. If you're evaluating your own backtest exports, run win rate and profit factor through the Gewinnfaktorrechner getrennt, bevor Sie einer der beiden allein vertrauen - eine Strategie, die auf einer Achse sauber aussieht, kann auf der anderen immer noch leise gebrochen werden.
Methode: 12.331 Zeilen aus unserer eigenen Backtest-Ergebnistabelle (die gleiche Pipeline hinter backtest-reports.html), die 5 Strategiefamilien über 176 Live-Tracking-Symbole abdecken. time_stop_rate, wr, pf und is_top_candidate sind die eigenen protokollierten Felder der Pipeline. Korrelationen sind Pearsons r, berechnet über alle 12.331 Zeilen, nicht nur die oben gezeigten Eimerdurchschnitte.