Ciao Silvix, ho chiesto alla AI:
Hai ragione, ed è un comportamento atteso, non un bug: la classificazione per z-score è molto più severa di quella percentile per come è costruita la distribuzione dei ritardi.
Perché succede
I gap del Lotto non sono affatto gaussiani: sono una distribuzione fortemente asimmetrica a destra (tipo geometrica/esponenziale), con tanti ritardi piccoli e una coda lunga di ritardi molto alti. Questo ha un effetto preciso sulla deviazione standard: i pochi ritardi enormi presenti nello storico (magari 150, 200, 250 estrazioni) fanno esplodere la varianza, quindi lo stddev calcolato per ogni numero è già "gonfio" di suo.
Risultato: perché un numero raggiunga z ≥ 2.5 (soglia per ROSSO), il suo ritardo attuale deve essere
enormemente superiore alla media — molto più di quanto servirebbe in una distribuzione normale, dove z=2.5 corrisponde al 99.4° percentile circa. Qui, con una coda pesante, uno z=2.5 può corrispondere anche solo al 90-92° percentile reale, e capita raramente che un numero specifico lo raggiunga proprio nel momento dell'analisi.
È esattamente il motivo per cui nel codice hai già aggiunto la classificazione a percentile in parallelo, con il commento:
cpp
<span>// Classificazione basata su percentile del ritardo attuale</span><br><span>// (piu' robusta dello z-score per distribuzioni non gaussiane come i gap)</span>
Il percentile infatti è per costruzione sempre popolato (per definizione il 10% più ritardato finisce in ROSSO, sempre), mentre lo z-score può restare a 0 per intere ruote e periodi, come vedi nei tuoi screenshot.
Opzioni, se vuoi bilanciare meglio lo z-score
- Lasciarlo com'è: è corretto matematicamente, semplicemente lo z-score risponde a una domanda diversa ("quanto è statisticamente anomalo") rispetto al percentile ("quanto è messo peggio rispetto agli altri 89").
- Abbassare le soglie z (es. ROSSO ≥ 1.8, ARANCIO ≥ 1.2, GIALLO ≥ 0.8) per renderlo più reattivo — ma perderesti il significato statistico rigoroso.
- Calcolare lo stddev sui log dei gap invece che sui gap grezzi, che riduce l'effetto della coda pesante e rende lo z-score più "utilizzabile" nella pratica.
- Usare il percentile come classificazione principale (com'è già in pratica) e tenere lo z-score solo come indicatore secondario nel pannello di dettaglio, senza doppia sezione riepilogativa in alto.
Fammi sapere se vuoi che modifichi qualcosa nel codice o se la cosa ti va bene così com'è.
Tu sai che ho "rubato", partendo dalle immagini da loro pubblicate, il programma (Dall'ottimissimo lotto_tom75).
Comunque ho guardato quello "Originale di lotto_tom75" (ricorda di ringraziare lui se il programma ti piace)
Vedi l'allegato 2318280
Mi sembra che siano simili (puoi chiamarmi Arsenico Lupini

)
Quindi da quel nulla che capisco mi sembra che non sia un bug del programma.
Ciao