norangebit/master-thesis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Refactor some phrases

Browse Source
This commit is contained in:
Raffaele Mignone 2021-06-08 10:53:00 +02:00
parent 1fa7839b6b
commit 404fabe83b
Signed by: norangebit
GPG Key ID: F5255658CB220573
1 changed files with 15 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
src/chapter_3.md
View File

@ -4,20 +4,21 @@
## RQ2: come sono distribuiti i bug sulle diverse fasi di ML? ## RQ2: come sono distribuiti i bug sulle diverse fasi di ML?
Come illustrato nella @sec:classificazione-commit per poter determinare la natura del *issue fix* si è fatto ricorso alla classificazione delle issues ad esso linkate. Come illustrato nella @sec:classificazione-commit per poter determinare la natura di un *issue fix* si è fatto ricorso alla classificazione delle *issues* ad esso associate.
Nel caso in cui la issue sia stata classificata manualmente, oltre all'individuazione della tipologia (\ac{ML}, non \ac{ML}) è stata individuata anche la fase in cui il problema si palesava (si veda @sec:classificazione-issues). La maggior parte delle *issues* è stata classificata automaticamente, ma è stato comunque necessario classificarne una porzione in modo manuale per poter avere un train/test set.
Questo dato aggiuntivo presente su alcune issues è stato *proiettato* anche sulla classificazione dei commit di *fix* per andare come questi sono distribuiti sulle varie fasi. Come detto precedentemente, nel caso delle *issues* classificate a mano, oltre all'individuazione della tipologia (\ac{ML}, non \ac{ML}) è stata individuata anche la fase in cui il problema si palesava (si veda @sec:classificazione-issues).
Questo dato aggiuntivo presente su alcune issues è stato *proiettato* anche sulla classificazione dei commit di *fix* per andare a valutare come questi sono distribuiti sulle varie fasi.
I risultati di questa analisi sono riportati in @fig:count-fix-phases. I risultati di questa analisi sono riportati in @fig:count-fix-phases.
![Istanze dei fix in base alla fase](figures/count-fix-phases.pdf){#fig:count-fix-phases width=70%} ![Istanze dei fix in base alla fase](figures/count-fix-phases.pdf){#fig:count-fix-phases width=70%}
Rispetto alla distribuzione sulle issues (@fig:labeling-phases) è possibile notare la scomparsa della fase *data collection*, inoltre è evidente anche la riduzione delle occorrenze di *model training* e una crescita di importanza per quanto riguarda le fasi di *model requirements* e *model deployment*. Rispetto alla distribuzione sulle issues (@fig:labeling-phases) è possibile notare la scomparsa della fase *data collection*, inoltre è evidente anche la riduzione delle occorrenze di *model training* e una crescita d'importanza per quanto riguarda le fasi di *model requirements* e *model deployment*.
Sfortunatamente i dati disponibili per questa analisi sono molti limitati, è stato possibile ricavare la fase solo per quaranta *fix*, per cui non è stato possibile altre analisi. Sfortunatamente i dati disponibili per questa analisi sono molto limitati (è stato possibile ricavare la fase solo per quaranta *fix*), per cui non è stato possibile effettuare delle analisi più approfondite.
## RQ3: esiste una differenza di entropy tra ML bug e altri bug? ## RQ3: esiste una differenza di entropy tra ML bug e altri bug?
La successiva analisi avevo lo scopo di verificare l'esistenza di una differenza tra l'entropia del *fix* rispetto alla natura di questi. La successiva analisi avevo lo scopo di verificare l'esistenza di una differenza tra l'entropia del *fix* rispetto alla natura di questi.
L'analisi è stata svolta sia a livello di file sia a livello di linee, quindi per ogni commit del dataset è stato necessario individuare sia il numero di file che hanno subito delle modifiche, sia il numero di linee alterate, considerando in questo modo sia le aggiunte che le rimozioni. L'analisi è stata svolta sia a livello di file, sia a livello di linee, quindi per ogni commit del dataset è stato necessario individuare sia il numero di file che hanno subito delle modifiche, sia il numero di linee alterate, considerando in questo modo sia le aggiunte che le rimozioni.
Inoltre per poter valutare l'entità del cambiamento è stato necessario conoscere anche il numero totale di file e di linee di ogni progetto. Inoltre per poter valutare l'entità del cambiamento è stato necessario conoscere anche il numero totale di file e di linee di ogni progetto.
Questi valori sono stati calcolati attraverso la storia `git` del branch `master`[^branch-master]. Questi valori sono stati calcolati attraverso la storia `git` del branch `master`[^branch-master].
@ -48,14 +49,14 @@ Una situazione analoga si riscontra anche nell'analisi sulle linee (@fig:lines-e
## RQ4: come varia il livello di discussione tra ML bug e altri bug? ## RQ4: come varia il livello di discussione tra ML bug e altri bug?
Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issues. Per rispondere a questa domanda è stato necessario andare a valutare il numero di commenti presenti all'interno di ogni issues.
Poiché un singolo commit può far riferimento a più issues il valore riportato è quello dei commenti medi. Poiché un singolo commit può far riferimento a più issues è stato considerato il numero di commenti medi.
I risultati ottenuti sono stati riportati nel boxplot[^boxplot-discussion] in @fig:discussion-comments. I risultati ottenuti sono stati riportati nel boxplot[^boxplot-discussion] in @fig:discussion-comments.
In questo caso si evince una differenza molto più marcata tra le due distribuzioni. In questo caso si evince una differenza molto più marcata tra le due distribuzioni.
In particolare è possibile notare che le *issue fix* di \ac{ML} presentano una maggiore discussione e anche una maggiore varianza. In particolare è possibile notare che le *issue fix* di \ac{ML} presentano una maggiore discussione e anche una maggiore varianza.
Se consideriamo la differenza interquartile, in modo da escludere completamente eventuali outlier, possiamo osservare che nei *fix* generici questa varia tra zero e uno. Se consideriamo la differenza interquartile, in modo da escludere completamente eventuali outlier, possiamo osservare che nei *fix* generici questa varia tra zero e uno.
Ciò vuol dire che il $50\%$ interno delle issues o non presenta commenti o ne presenta uno solo. Ciò vuol dire che il $50\%$ interno delle issues o non presenta commenti o ne presenta uno solo.
Mentre la differenza interquartile dei *fix* di \acl{ML} è compreso tra uno e due quindi nel $50\%$ interno tutte le issues hanno almeno un commento di risposta. Mentre la differenza interquartile dei *fix* di \acl{ML} è compreso tra uno e cinque quindi nel $50\%$ interno tutte le issues hanno almeno un commento di risposta.
[^boxplot-discussion]: In questo caso il limite superiore è pari al $97$-$esimo$ quantile. [^boxplot-discussion]: In questo caso il limite superiore è pari al $97$-$esimo$ quantile.
@ -73,7 +74,7 @@ Mentre la differenza interquartile dei *fix* di \acl{ML} è compreso tra uno e d
A questo punto si è cercato di capire se al maggior numero di commenti è associata effettivamente una maggiore quantità di informazioni scambiate. A questo punto si è cercato di capire se al maggior numero di commenti è associata effettivamente una maggiore quantità di informazioni scambiate.
Per svolgere questa analisi si è partiti dal presupposto che la quantità di informazioni scambiate sia proporzionale al numero di parole utilizzate nel commento. Per svolgere questa analisi si è partiti dal presupposto che la quantità di informazioni scambiate sia proporzionale al numero di parole utilizzate nel commento.
Quindi per ogni issues è stato calcolato il numero medio di parole presenti all'interno di un commento. Quindi per ogni *issue* è stato calcolato il numero medio di parole presenti all'interno di un commento.
I risultati di quest'ulteriore analisi sono riportati in @fig:discussion-words. I risultati di quest'ulteriore analisi sono riportati in @fig:discussion-words.
Anche in questo caso si può vedere che nel caso di \ac{ML} *fix* la distribuzione presenta valori più elevati e maggiore varianza. Anche in questo caso si può vedere che nel caso di \ac{ML} *fix* la distribuzione presenta valori più elevati e maggiore varianza.
Per cui non solo nei *fix* di \acl{ML} c'è maggiore discussione, ma la discussione è anche più *densa*. Per cui non solo nei *fix* di \acl{ML} c'è maggiore discussione, ma la discussione è anche più *densa*.
@ -81,18 +82,18 @@ Per cui non solo nei *fix* di \acl{ML} c'è maggiore discussione, ma la discussi
## RQ5: come varia il time-to-fix tra ML bug e altri bug? ## RQ5: come varia il time-to-fix tra ML bug e altri bug?
In quest'ultima analisi si vuole andare a valutare se c'è differenza nel tempo necessario per eseguire il *fix*. In quest'ultima analisi si vuole andare a valutare se c'è differenza nel tempo necessario per eseguire il *fix*.
Per valutare questo parametro è stato necessario estrarre dalle informazioni di ogni issue la data di apertura e di chiusura e calcolare i giorni che intercorrono tra queste. Per valutare questo parametro è stato necessario estrarre da ogni *issue* la data di apertura e di chiusura e calcolare i giorni che intercorrono tra queste.
I risultati così ottenuti sono stati riportati in @fig:day-to-fix. I risultati così ottenuti sono stati riportati in @fig:day-to-fix.
![Giorni necessari per il fix](figures/day-to-fix.pdf){#fig:day-to-fix width=70%} ![Giorni necessari per il fix](figures/day-to-fix.pdf){#fig:day-to-fix width=70%}
Anche per questo aspetto è possibile notare una netta differenza tra i *fix* di \ac{ML} e gli altri. Anche in questo caso è possibile notare una netta differenza tra i *fix* di \ac{ML} e gli altri.
In particolare i bug di \acl{ML} necessitano, mediamente, di maggior tempo per essere risolti e sono caratterizzati da una varianza maggiore. In particolare i bug di \acl{ML} necessitano, mediamente, di maggior tempo per essere risolti e sono caratterizzati da una varianza maggiore.
Inoltre è possibile vedere come la mediana non sia centrata, bensì spostata verso il basso. Inoltre è possibile vedere come la mediana non sia centrata, bensì spostata verso il basso.
Questo vuol dire che il $50\%$ basso dei *bug* di \ac{ML} viene comunque risolto in tempi brevi (tre giorni circa), mentre l'altro $50\%$ può richiedere una quantità di tempo decisamente superiore. Questo vuol dire che il $50\%$ basso dei *bug* di \ac{ML} viene comunque risolto in tempi brevi (tre giorni circa), mentre l'altro $50\%$ può richiedere una quantità di tempo decisamente superiore.
Un'ulteriore testimonianza del maggior tempo necessario per risolvere le problematiche legate al \ac{ML} ci viene data dagli outlier. Un'ulteriore testimonianza del maggior tempo necessario per risolvere le problematiche legate al \ac{ML} ci viene data dagli outlier.
Nel caso dei problemi generici questi vengono considerati come *anomali* se per essere risolti necessitano più di cinque giorni. Nel caso di un problema generico, questo, viene considerato come *anomalo* se per essere risolto necessita di un tempo superiore ai cinque giorni.
Mentre nel caso dei *fix* di \acl{ML} per essere considerato outlier ne necessaria un *time-to-fix* superiore ai trentacinque giorni. Mentre nel caso dei *fix* di \acl{ML} per essere considerato outlier un *issue*, necessaria di un *time-to-fix* superiore ai trentacinque giorni.
Il maggior tempo necessario ad attuare la correzione ci indica che i *bug* di \ac{ML} sono più difficili di quelli generici il che spiegherebbe anche il dato emerso dalla sezione precedente, in quanto per individuare la fonte del problema è necessaria una discussione più accurata. Il maggior tempo necessario ad attuare la correzione ci indica che i *bug* di \ac{ML} sono più difficili di quelli generici il che spiegherebbe anche il dato emerso dalla sezione precedente, in quanto per individuare la fonte del problema è necessaria una discussione più approfondita.