Please enable JavaScript.
Coggle requires JavaScript to display documents.
1 - JIRA, GIT, WEKA, EVALUATIONS, METRICS, 3 - PERFORMANCE METRICS, 5 -…
1 - JIRA, GIT, WEKA, EVALUATIONS, METRICS
INTRODUZIONE
- Dagli schemi precedenti abbiamo preso che è necessario usare solo la prima metà delle release + tutti i bug noti.
- GitHub contiene numerosi dati legati a JIRA, ma le analisi possono essere scorrette.
- Un progetto è dato dalla repository base + tutte le fork. Infatti se lavoro su fork di un progetto non appare nella repo principale.
- E' consigliato lo studio di progetti Apache, poichè sono progetti software con alto numero di commit.
- Un commit ha un ID univoco, una data (che uso per capire in che release è stato prodotto) ed un commento (a noi interessa che ci sia un riferimento a JIRA).
- Il comando 'diff' riceve in input gli id di due commit e ritorna le linee di codice modificate.
- Il comando 'blame' mi dice, dato un file, quando e da chi è stato modificato.
METRICHE & DATASET
- Per poter dire se una classe è buggy, occorrono dati raccolti in un file.
L'input deve essere un .csv e l'ultima colonna indica la buggyness (si/no).
- Nelle prime colonne abbiamo progetto, versione (numero versione crescente) e filename.
FEATURE/METRICS
Sono le metriche per fare una previsione, tra cui spiccano:
- Size = LOC = lines of code, grandezza.
- LOC_touched = somma di linee aggiunte, tolte, modificate (normalmente associate per ogni revisione).
- Age = età della classe (in weeks)
- Smells = numero smells
Ce ne sono molte altre, ma hanno sempre una di queste alla 'base'
(es: Churn = linee aggiunte - linee tolte, MaxChurn, AvgChurn;
ChgSet, MaxSet, AvgSet, legati a quanti files committo insieme;
Numero revisioni, numero fix, numero autori etc...).Le metriche posso essere associate ad ogni release, oppure ad inizio progetto.Per ogni release:
:check: dati più precisi
:red_cross: più dati da elaborareInizio progetto:
:check: gestisco un carico minore
:red_cross: dati meno precisi, magari ho una classe che ho toccato molte volte, ma viene 'rilassata' se considero le classi restante.
APPROFONDIMENTO (Paper lez.23)
- Esistono anche metriche puramente "Object Oriented", che considerano:
- numero di classi referenti ad una classe
- numero di classi che una classe referenzia
- numero di attributi pubblici, privati, metodi pubblici, ereditati etc...
OSSERVAZIONE
Nel modello di regressione lineare vengono interpretati solo "Numeri"; ovvero il classificatore non sa cosa è un LOC o un NR, l'importante è che abbiano una correlazione, appresa nel training.
E' inutile fornire feature altamente correlate (es: loc max e loc avg insieme a loc), ma è anche vero che tutte le feature hanno sempre almeno un pò di correlazione tra loro ( se ho loc alto mi aspetto NR proporzionale!)
WEKA
- E' un tool per ML scritto in java.
- Prende in input un file .ARFF = ordine label + nome dataset + definizione di ogni colonna + dati file .csv (esclusa la prima riga, cioè nome file, infatti Weka usa nome dataset precedentemente definito).
- Parlo di classificatori per variabili Nominali (sesso : M/F ad esempio)
- Parlo di predittori per variabili numeriche.
file .ARFF
- Si ottiene mettendo il file.csv su excel, rimuovendo i dati doppi e passando manualmente al formato .arff
OSSERVAZIONI
- E' sempre meglio preservare l'ordine, potrei erroneamente usare i dati del 2020 per stimare quelli del 2019!
- La domanda a cui noi vogliamo rispondere è:
Il sistema è accurato se lo implemento oggi? Non mi interessa sapere che due anni sarebbe stato buono. Ma se ci pensiamo, non è che se una cosa andava bene due anni fa ora va bene uguale (es: pre-covid non potevo pensare che nel 2020 molti hotel estivi avrebbero chiuso!)
random vs time
- time:
:check: è una modalità più safe, il contesto è realistico, predico usando dati che posso realmente avere.
:check: Non 'baro', ovvero evito di stimare il 2019 sapendo il 2020.
:red_cross: faccio meno test, perchè devo usare i dati in un modo prefissato.
:red_cross: non è detto che un qualcosa che andava bene ieri vada bene anche oggi!
- random:
:check: test illimitati
:red_cross: se c'è un cambiamento dettato dal tempo (es: cambio modalità di esame, cambio prof etc) perde di veridicità!
FEATURE SELECTION
Abbiamo definito la feature come un attributo di rilievo utile per le nostre analisi.
- E' possibile, nella fase di pre-processamento, selezionare le feature 'migliori', eseguendo la feature selection, cosi facendo si eliminano feature che non contribuiscono alla predizione.
:red_cross: Weka capisce le feature utili testandole, non fa una predizione (è come se per sapere se conviene portare l'ombrello, aspettassi la fine della giornata e tornassi all'inizio di questa sapendo se ha piovuto o meno).
:red_cross: Feature Selection ok solo per indicazioni personali, perchè come detto sa il testing set, e io non posso usare dati testing prima del testing
:red_cross: se il dataset piccolo, la feature selection può peggiorare l'accuratezza, perchè toglie qualcosa che effettivamente serviva!
:check: noti gli attributi utili, posso in futuro preoccuparmi solo di quelli, raccogliendo meno dati.
:check: riduco over-fitting (attributi ridondanti), inoltre se un attributo non è utile per la predizione, probabilmente la sua presenza può peggiorare il predittore stesso.Vogliamo feature correlate con l'obiettivo ma il più scorrelate dalle altre feature.
3 - PERFORMANCE METRICS
RECALL
- Ci dice quanti positivi siamo stati in grado di trovare.
- TP/(TP + FN)
- Da sola è inutile, perchè basterebbe dire che tutte le classi sono buggy (quindi FN = 0) e sarebbe massima. In questo caso equivale a classificatore dummy, cioè inutile.
- High recall se ho 99% dati positivi, allora il classificatore dirà sempre positivo.
PRECISION
- Ci dice quante volte ho correttamente identificato una cosa come vera, e lo era.
- TP/(TP+FP)
- Da sola è inutile, perchè se faccio solo una volta l'identificazione, allora ho precisione massima.
(è come dire che un calciatore che ha segnato un rigore su uno sia un cecchino infallibile).
ACCURACY
- Rapporto tra tutti i positivi/tutti i negativi
- Metrica peggiore, dipende da threshold e non mi dice nulla (se dataset era facile, ho accuracy 100%, e quindi?)
Kappa
- Quante volte sono stato più accurato di un dummy classifier.
(Accuracy Classifier - Accuracy Dummy)/(1 - Accuracy Dummy)
- se >0 meglio del dummy,
- = 0 come dummy
- < 0 = peggio del dummy
- E' una metrica molto importante, che va sempre detta per prima.
ESEMPI
- Se recall = 0.9 e kappa = 0.1 vuol dire che la stima era facile ed il mio classificatore è simile a dummy.
- Se recall = 0.1 e kappa = 0.9 vuol dire che la stima era era difficile (recall bassa) ma il mio classificatore si è comportato bene.
ROC & AUC
- Il classificatore non dice 'buggy' 'not buggy', mi dà un valore, che viene associato a 'buggy' 'not buggy' secondo una soglia di threshold.
- Quindi tutte le metriche appena viste possono cambiare se cambio la thresold.
- L' AUC è la curva sottesa nel rapporto positivi/negativi. Questa non usa threshold, ma in realtà le usa tutte e fa una media, assumendo tutte le threshold importanti.
:red_cross: il valore ritornato non ha un valore ben specificato, non so interpretarlo, non è realistico.
5 - SAMPLING
- Abbiamo visto più volte che sia training che testing set devono 'rispecchiare' lo stato del sistema testato. Questo vuol dire che se l'1% dei dati è 'particolare' esso deve essere campionato sia nel training che nel testing. Cioè si bilancia.
- Questo perchè il classificatore è influenzato da ciò che vede!
SIMPLE RANDOM SAMPLING
- come suggerisce il nome, si basa sul random. Il random però è basato su un ordinamento, come può essere il cognome. (ovvero: prima ordino poi campiono). L'importante è che l'ordine non influisca sull'obiettivo (es: cognome non influisce sul voto).
STRATIFIED RANDOM SAMPLE
- Si effettua la divisione della popolazione in gruppi. Poi pesco da ciascun gruppo un tot di elementi.
:check: ogni gruppo è rappresentato.
:red_cross: dipende come definisco i gruppi (se gruppi = classi delle superiore, e prendo per caso gli studenti più bravi del 4° anno e gli studenti più scarsi del 5° ottengo che in media gli studenti del 5° sono meno preparati.
SYSTEMATIC RANDOM SAMPLE
- Parte da un valore random, e poi procede in modo sistematico. (es: esce lettera G, allora poi proseguo con H, I, L ....)
:check: è fair, ogni membro ha pari opportunità di essere train o test
-
-
4 - FEATURE SELECTION
- Abbiamo già avuto modo di vedere questa caratteristica. Ora completiamo la sua analisi.
- La feature selection può essere usata con tre approcci.
- Come scelgo l'approccio?
- Innanzitutto dipende da fattori quali costi, tempi etc...
- Se ho tantissime righe da analizzare allora ha senso Forward Search.
- Se ho poche righe andrebbe bene un approccio Exausisitve (Filter o Wrapper)
FILTER APPROACH
Il subset delle feature dipende solo dalle feature, non dal classificatore. Ovvero mi limito a considerare la correlazione con la feature da stimare (alta) e la correlazione con le altre feature (bassa). Ho due risultati per queso approccio:
- subset preciso delle feature
:red_cross: usa threshold
:check: molto veloce
- ranking
:red_cross: vengono ordinate per importanza, però se voglio prendere le prime 5 potrei trovarle altamente correlate tra loro.
CIoè se voglio 5 feature non è detto che siano le prime 5 fornite dal ranking.
WRAPPER APPROACH
Ottimizza la scelta per lo specifico classificatore, è lui che sceglie cosa usare.
Le tecniche sono testate solo sul traning set (testing set non usabile).
:red_cross: qui diamo per scontata la scelta del classificatore, chi mi dice che questo che ho preso è ottimale per il mio scopo?
:red_cross: cosa vuol dire scelta migliore delle feature? solo recall alta? solo precision alta? tutte alte?
se una aumenta e una diminuisce, è migliorato?
APPROCCI GREEDY
- forward search : parto da insieme piu piccolo di attributi, incremento finchè non trovo un bound nei miglioramenti.
:red_cross: potrei perdere molte coppie migliori di quella trovata, solo perchè sono ingordo e proseguo sulla prima strada buona.
:check: meno oneroso tra tutti
- backward search: approccio inverso.
:red_cross: oneroso, ho lo stesso problema del forward (ma al contrario)
DOVE VIENE FATTA FEATURE SELECTION?
- Poichè sto creando miglior training set, sicuramente non posso toccare il testing set.
- Se uso wrapper, quindi scelta la fa il classificatore, come fa la scelta? usa il testing set! (come abbiamo già visto!).
- C'è un modo per evitare l'uso del testing set?
TUNING WRAPPER
E' una tecnica che uso sopratutto nel wrapper, perchè dipende dal classificatore!
Divido il training set in:
- training set, (quindi lo riduco rispetto alla condizione iniziale)
- validation set, dove provo la feature selection.
- Il suo scopo non è migliorare la predizione, ma semplicemente alleggerire le metriche usate.
esempio:
se training va da 1 a 6, magari le feature migliori le trovo usando come training 1-3 e validation 4-6.
Scoperte queste, faccio training 1-6 basato su feature selection e testing vero e proprio su feature 7.ATTENZIONE
- Quando faccio questi ragionamenti, il testing è un qualcosa che ho sempre. E' come fare un esercizio sapendo che esiste un risultato, svolgerlo e confrontarlo.
Sarebbe molto diverso fare l'esercizio senza sapere il risultato, perchè non potrei mai dire con certezza che quello è veramente il risultato, senza confrontarlo con fonte certa.
- Inoltre è sempre possibile che una nuova release cambi tutte le predizioni fatte! (Magari viene la nuova release riprogetta da 0 il software!)
- Scelgo il modello con training + validation
- La sua accuratezza la valuto con training + validation + testing
-