Le inversioni non si addensano sui livelli tondi, nemmeno a risoluzione tick
The points where price turns do not cluster on round numbers, not even at one tick every four tenths of a second. But getting there meant throwing away two of my own measurements: one said the opposite with p = 1.0000, the other claimed a power the test did not have.
Our own idea, measured and abandoned
This research document is written in Italian. The summary above is in English; the body below — method, tables and verdict — is not translated.
Protocollo pre-registrato — prova principale, scala di δ e soglia dichiarate prima dei numeri.
il documento del 14/07/2026 aveva lasciato aperta sulla linea «level-to-level».
Quel documento chiudeva la linea con tre falsificazioni, ma finiva con una riga precisa:
«Unica porta aperta: è un mid M5, il clustering di ORDINI veri servirebbe tick/book
(non disponibili).»
Da fine luglio i tick ci sono: il nostro archivio, 30 giorni, mediana 0,41 s fra righe — 700 volte più fine di M5. Questa è la stessa prova a quella risoluzione.
36 celle su 4 simboli, 9,1 milioni di tick, p minimo 0,066. Con Bonferroni non resta niente. E dove il campione attraversa abbastanza linee il test vede un'attrazione del 3-5% — mentre su EURUSD a 50 e 100 pip è cieco, e quelle celle sono dichiarate mute invece di essere contate.
Cosa questa prova NON dice
Sono tick di prezzo, non il book. Un'inversione qui resta un fatto di prezzo. La domanda sul flusso degli ordini non è toccata e resta aperta: con questi dati non si può fare. Dirlo prima serve a non rivendere dopo una risposta più grande del dato.
La domanda
I punti in cui il prezzo si gira si addensano sui livelli tondi più di quanto farebbe il caso? Se sì, esiste un'ancora strutturale su cui costruire entrate e uscite.
Prova principale dichiarata prima: griglia dei tondi ogni 10 pip, δ = 10× lo spread tipico, sul simbolo con più tick. Tutto il resto è esplorazione e si legge con Bonferroni.
Lo strumento
verifiche/strumenti/impronta_tick.py, banco chat_bot/prove/prova_impronta_tick.py a 15 controlli su 15. Le sei trappole note erano già chiuse nell'intestazione dello strumento (placebo con la stessa geometria, banda = spread misurato, inversione che non conosce i livelli, δ spazzato e non tarato, molte celle = Bonferroni, spread portato dietro). Il banco ha preso cinque difetti in costruzione, e tre erano di metodo.
I tre difetti di metodo (la parte che conta)
1. Il placebo aveva un pavimento
Il primo disegno confrontava i tondi con la stessa griglia spostata di una fase a caso. Sembra giusto — stessa densità, stessa forma, posto sbagliato — e invece non può funzionare: se l'impronta esiste, le inversioni sono tutte congruenti modulo il passo, e una griglia spostata di φ dista φ da tutte contemporaneamente. O le prende tutte o nessuna. Il nullo diventa bimodale e il p non scende sotto ~2·banda/passo, cioè 0,20 col nostro assetto.
Misurato sul banco: effetto iniettato con rapporto 5,3 → p = 0,13. Con quel disegno un'impronta vera sarebbe stata dichiarata non significativa. È il modo peggiore di sbagliare: chiudere una pista buona credendo di avere una misura.
Sostituito da una statistica circolare: prezzo mod passo letto come angolo, e si chiede se gli angoli sono concentrati (Rayleigh). Niente si sposta, niente bimodalità.
2. L'ipotesi «fasi uniformi» è falsa
Misurando la fase di tutti i tick EURUSD — non solo delle inversioni — esce R = 0,0137 con p ≈ 0 su 923.008 righe. I prezzi in sé non sono uniformi modulo la griglia: in 30 giorni il cambio copre poche centinaia di pip e passa più tempo in certe zone. Con n grande, qualunque cosa è «significativamente non uniforme».
Confrontare le inversioni con l'uniforme misurava quindi dove è stato il prezzo, non dove si è girato. Sono due domande diverse e solo la seconda interessa.
3. Il nullo condizionato al cammino è distorto — e fabbrica un effetto al contrario
Il rimedio ovvio: pescare a caso, dalla stessa serie, tanti prezzi quante sono le inversioni. È il nullo che ha prodotto i primi numeri di questo studio. È sbagliato.
Quel campione è pesato sul tempo: sta dove il prezzo si è fermato. Le inversioni sono estremi, e per costruzione spazzano tutto l'intervallo. Due popolazioni diverse.
Prova di controllo, su un cammino casuale puro dove per costruzione non esiste nessun livello:
| R inversioni | R atteso dal nullo | p | |
|---|---|---|---|
| cammino casuale, 400.000 passi | 0,0657 | 0,1323 | 0,9834 |
Il nullo «vede» uno scarto del 50% dove non c'è niente. Non è innocuo: su GBPJPY dava p = 1,0000 in tutte e quattro le celle della griglia da 100 — un numero che sembra una falsificazione schiacciante ed è solo meccanica. Con il nullo giusto la stessa cella dà 0,12.
⚠ Da questo studio è stata ritirata un'affermazione già scritta: «le inversioni sono meno addensate del caso, p fino a 1,0000». Era un artefatto del nullo. La conclusione non cambia — niente sotto 0,05 — ma la forza con cui si poteva dire sì.
Il nullo definitivo: surrogato a blocchi
Si rimescolano gli incrementi tick-a-tick a blocchi di 500 (i blocchi tengono il raggruppamento di volatilità), si ricostruisce il cammino, e ci si passa lo stesso zigzag. Stessa dinamica, stesso rivelatore, stessa meccanica degli estremi: l'unica cosa distrutta è l'ancoraggio al livello assoluto, che è l'ipotesi in esame.
Controllo che i surrogati siano un paragone e non un altro mercato — escursione media dei surrogati contro quella vera: EURUSD 250/261 pip, CHFJPY 824/871, GBPJPY 770/926, EURJPY 619/811.
⚠ Lo scarto c'è ed è grosso dove il cammino vero è più tendenzioso: su EURJPY i surrogati coprono in media 555 pip contro 811. Il sospetto era che un intervallo più stretto attraversi meno linee e alzi R per caso, rendendo il confronto conservativo. Misurato: falso. La correlazione fra escursione e R dentro i 60 surrogati EURJPY è −0,056, cioè nulla. Il rimescolamento a blocchi accorcia la strada ma non sposta la fase.
La potenza — misurata contro il nullo che si riporta
Un esito negativo senza potenza non vale niente. Si prende il dato vero, si spostano le inversioni verso il tondo di una frazione f, e si rilegge il p contro la stessa distribuzione surrogata.
⚠ Questa sezione è stata rifatta. La prima versione misurava la potenza con il nullo pesato sul tempo — quello che questo stesso documento dichiara distorto due sezioni più su. Dichiarare la potenza di un test diverso da quello che si riporta è lo stesso errore di forma che il documento denuncia, commesso dal documento.
| cella | linee attraversate | inversioni | effetto minimo visto |
|---|---|---|---|
| EURUSD, griglia 10, δ 0,5 pip | 26 | 42.759 | 5% |
| GBPJPY, griglia 100, δ 5,1 pip | 9 | 5.875 | 3% |
| GBPJPY, griglia 50, δ 5,1 pip | 19 | 5.875 | 5% |
| EURUSD, griglia 100, δ 2,7 pip | 3 | 2.706 | niente, nemmeno al 20% |
**La risoluzione non dipende da n, dipende da quante linee di griglia il campione attraversa. EURUSD in 30 giorni copre 261 pip: tre sole linee da 100. Lì il nullo ha una varianza enorme e il test non distingue nemmeno un'attrazione del 20% — non è «nessun effetto», è una cella muta**. Con 2.706 inversioni: n grande e potenza nulla.
Lo strumento lo sapeva già: prova_tondi porta un campo potenza che vale «bassa» sotto le 10 linee distinte, scritto proprio per questo. Passando al nullo surrogato quel campo è stato perso per strada, e le celle mute sono finite in tabella accanto alle altre come se pesassero uguale.
Nota di lettura: con N surrogati il p non può scendere sotto 1/(N+1) — 0,016 con 60, 0,024 con 40. Un p a quel valore significa «nessun surrogato ha fatto altrettanto», non una misura più fine.
I risultati
Nullo surrogato, p a una coda. Nessuna cella sotto 0,05; il minimo assoluto è 0,066.
| simbolo | tick | escursione | griglia | p minimo fra i 4 δ |
|---|---|---|---|---|
| EURUSD | 1.497.649 | 261 pip | 10 · 50 · 100 | 0,066 · 0,213 · 0,902 |
| GBPJPY | 3.248.344 | 926 pip | 50 · 100 | 0,268 · 0,122 |
| CHFJPY | 2.407.981 | 871 pip | 50 · 100 | 0,146 · 0,220 |
| EURJPY | 1.981.731 | 811 pip | 50 · 100 | 0,098 · 0,342 |
⚠ Le due righe di EURUSD su 50 e 100 pip non sono prove di assenza: 5 e 3 linee attraversate, risoluzione insufficiente (vedi sopra). Restano in tabella perché tacere una cella misurata è peggio che mostrarla, ma non contano come evidenza. Le celle informative sono 28 su 36.
I cross sullo yen sono il campione buono: attraversano 8-9 big figure sulla griglia da 100 (216,00 · 216,50) e 16-19 su quella da 50, contro le 3 e 5 di EURUSD. Sono anche i livelli che sarebbero davvero punti di Schelling — ed è lì che il test ha la potenza migliore, 3%.
δ fini su EURUSD, mai guardati prima (la scala partiva da 2,7 pip):
| δ | inversioni | griglia 10 | griglia 50 | griglia 100 |
|---|---|---|---|---|
| 0,5 pip | 41.719 | 0,133 | 1,000 | 1,000 |
| 1,0 pip | 14.722 | 0,256 | 1,000 | 0,638 |
| 2,0 pip | 4.564 | 0,415 | 0,970 | 0,621 |
Il verso dell'effetto: testa o croce
Guardando GBPJPY sembrava che R osservato stesse sopra il surrogato. Contate tutte e 36 le celle: 19 sopra, 17 sotto. È esattamente una monetina. Non c'è nemmeno una tendenza debole — l'impressione veniva dall'aver letto un simbolo solo.
Un difetto nel dato, trovato durante la prova
Il filtro delle righe diceva ask <= bid e scartava come «rotte» 575.142 righe EURUSD su 1.497.539 — il 38%. Non sono rotte: hanno ask == bid, con flags = BID+ASK (entrambi i lati aggiornati in quel tick). Sono quote vere a spread zero, e su quel feed lo zero è il secondo valore più frequente. Il mid lì è definito benissimo.
Peggio: era un filtro selettivo sullo spread, cioè la trappola 6 scritta nell'intestazione dello strumento, commessa dallo strumento stesso.
Corretto (ask < bid) e difeso da un controllo di comportamento — si scrive un db finto con tre righe e si contano quelle che tornano. La prima versione di quel controllo cercava la stringa ask <= bid nel sorgente e falliva sul commento che spiega il difetto: cercare una sottostringa invece di una forma è la trappola che in questo progetto ha già dato cinque falsi allarmi.
Con tutte le righe recuperate la prova principale dà p = 0,21. La conclusione non cambia.
Nota sullo spread del feed
Il bid/ask del il nostro archivio viene dalla storia scaricata da MT5, che su questo conto non porta il markup: dà EURUSD 0,10 pip contro gli 0,90 che si pagano davvero (documentato in tick_polso.py dall'11/08, confermato su 100 riempimenti reali). Per questo studio non cambia nulla: si usa il mid, e uno scarto costante non muove R, che è invariante per rotazione.
Conclusione
A risoluzione tick, con nullo appaiato, i punti di inversione non si addensano sui livelli tondi — e dove il test ha risoluzione misurata avrebbe visto un'attrazione del 3-5%.
Dove vale: EURUSD sulla griglia fine (26 linee, fino a 42.759 inversioni, swing da mezzo pip) e i tre cross sullo yen su 50 e 100 pip (16-19 e 8-9 linee), che sono anche gli unici livelli qui dentro a essere davvero punti di Schelling.
Dove non vale, ed è dichiarato invece che nascosto: EURUSD sulle griglie da 50 e 100 pip. In 30 giorni copre 261 pip — cinque linee e tre. Il test lì non distingue nemmeno un'attrazione del 20%: quelle celle non dicono «non c'è», dicono «non lo so».
Si chiude la porta che il documento del 14/07 lasciava aperta per il prezzo. Resta aperta, e intatta, quella sul flusso degli ordini.
Dove si incastra
Verifiche sorelle, stessa domanda per altre vie:
- «chiave» — la sezione C prova i numeri tondi su barre: non solo assenti, rovesciati. Qui la stessa famiglia di livelli a risoluzione tick: assenti e basta.
- «chiave» — un'altra mappa di supporti/resistenze, falsificata due volte. Anche lì la misura chiave era la stessa: le inversioni cadono nelle zone calde più che a caso? Risposta identica.
Schede del registro che questa verifica tocca: level-to-level-teoria (è la sua riserva che qui si chiude), livelli-forza-falsificato, impronta-livelli-trend, primi-densita-falsificata, regole-di-misura (i tre difetti di metodo vanno lì), registratore-tick (senza il nostro archivio questa prova non esisteva), dati-che-abbiamo.
Riproduzione: python3 verifiche/strumenti/impronta_tick.py --sym EURUSD,GBPJPY,CHFJPY,EURJPY per la parte descrittiva; impronta_surrogato() per il nullo appaiato. Banco: python3 chat_bot/prove/prova_impronta_tick.py (15 controlli, ~4 minuti).