User-Idee eines Volumen-Spike-Alerts. Berechtigte Frage dahinter: das Projekt
kennt nur tick_volume vom CFD - eine Zaehlung von Preisaenderungen bei einem
Market-Maker-Broker, kein gehandeltes Volumen. Echtes NYMEX-Volumen waere die
erste Datenquelle, die NICHT aus dem Preis abgeleitet ist.
Beide Quellen auf DEMSELBEN Fenster gemessen (28.05.-07.08., 13.855 CME- gegen
14.178 CFD-Bars), gleiche Methode, Ueberschuss ueber die Drift, zwei Haelften.
Bewusst nicht gegen den dokumentierten Wert gestellt - genau dieser Vergleich
(kurzes Fenster gegen Langfrist-Mittel) war am 07.08. der Messfehler.
Volumen CME H1/H2 CFD H1/H2
1,5-2,0x +0,116 / -0,203 -0,011 / +0,152
2,0-2,5x -0,221 / -0,282 -0,101 / +0,589
>=2,5x +0,102 / +0,096 -0,267 / -0,881
Trefferquote in ALLEN Zellen 44-53 % - Muenzwurf, in beiden Quellen. Kein
monotoner Zusammenhang, Vorzeichen kippen. Die einzige beidhaelftig konsistente
Zelle (CME >=2,5x) ist mit [-0,234 ... +0,428] bzw. [-0,265 ... +0,461] klar
Rauschen.
EHRLICHE GRENZE: meine CFD-Kontrolle reproduziert den alten Befund
(-0,117/-0,204) NICHT - Populations-Unterschied, kein Widerspruch.
backtest_candles.py mass bedingt auf ein Kerzen-MUSTER, hier laeuft es unbedingt
ueber alle Kerzen. Der alte Befund gilt weiter fuer seine Population.
60 Tage = ein Regime (yfinance-Deckel), also nur ein Ausschluss-Urteil moeglich.
Konsequenz: kein Volumen-Spike-Signal. Die Datenquelle funktioniert, sie traegt
nur keine Richtungsinformation.
Telegram-Kanaele als Eingabe (Bookmap/ATAS) ohne Messung verworfen: sie
transportieren Screenshots. Ein Orderbuch-Zustand ist vorbei, sobald ihn jemand
abfotografiert.
Nebenbefund zum eingereichten Skript: das .iloc[0]-Muster ist KORREKT
(MultiIndex-Spalten), nicht wie von mir zunaechst vermutet ein Fehler. Echte
Maengel: kein Dedup, kein Handelszeit-Gate, voller Tagesabruf im 60-s-Takt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
