Fix acronyms

src/chapter_1.md

@@ -7,20 +7,20 @@ Negli ultimi anni l'industria non è stata a guardare, ma ha dato vita a sempre
 Gli strumenti e i software che fanno uso di queste tecnologie sono ormai parte della nostra vita quotidiana e pervadono i campi più disparati.
 Tra questi sicuramente possiamo annoverare: riconoscimento di immagini, diagnosi di malattie, \ac{NLP}, guida autonoma e riconoscimento vocale.
 
-La crescente produzione di software basato sul \acl{ML} ha generato un forte impulso anche per quanto riguarda la ricerca.
+La crescente produzione di software basato sul \ac{ML} ha generato un forte impulso anche per quanto riguarda la ricerca.
 L'attenzione non è stata puntata unicamente sullo studio di nuovi modelli e architetture, ma anche sul processo di sviluppo di questi prodotti per andare a valutare i vari problemi da un punto di vista ingegneristico.
 In letteratura non mancano studi atti ad evidenziare le differenze tra progetti di \ac{ML} e progetti classici [@gonzalez2020statemluniverse10], né tanto meno confronti dei progetti rispetto alle dipendenze e alle librerie utilizzate [@han2020empiricalstudydependency].
 
-Molti studi sono, invece, incentrati sulle problematiche legate allo sviluppo di applicazioni di \acl{ML}.
+Molti studi sono, invece, incentrati sulle problematiche legate allo sviluppo di applicazioni di \ac{ML}.
 In alcuni casi l'analisi è stata svolta per librerie specifiche [@zhang2018empiricalstudytensorflow], in altri casi il focus è stato puntato sulle discussioni di \ac{SO} [@hassan2009predictingfaultsusing; @shannon1948mathematicaltheorycommunication].
 In altri casi ancora l'attenzione è stata rivolta su problematiche specifiche come quella del \ac{SATD} [@liu2021exploratorystudyintroduction].
 
-Anche il seguente lavoro si concentra sui difetti riscontrati all'interno delle applicazioni di \acl{ML}.
+Anche il seguente lavoro si concentra sui difetti riscontrati all'interno delle applicazioni di \ac{ML}.
 In questo caso però la ricerca di differenze è legata agli interventi di *issue fixing* relativi al \ac{ML} rispetto ad interventi di correzione generici.
 
 ## Obiettivi della tesi {#sec:goals}
 
-Questo studio vuole verificare la presenza di differenze, all'interno di progetti di \acl{ML}, rispetto a come sono trattate le *issues* legate a tematiche di \ac{ML} e quelle generiche.
+Questo studio vuole verificare la presenza di differenze, all'interno di progetti di \ac{ML}, rispetto a come sono trattate le *issues* legate a tematiche di \ac{ML} e quelle generiche.
 In particolare si vuole capire come la risoluzione di queste problematiche va ad impattare sull'architettura, sia in termini di moduli modificati sia in termini di entropia generata.
 Si vuole anche scoprire se sono presenti delle fasi del processo di sviluppo che sono più critiche di altre.
 Infine si vuole capire se le *issues* sono trattate tutte allo stesso modo per quanto riguarda il livello di discussione e il tempo necessario alla loro risoluzione.

src/chapter_2.md

@@ -1,8 +1,14 @@
 # Stato dell'arte {#sec:related-works}
 
-## Confronto tra progetti di ML e progetti generici
+In questo capitolo verrano presentati diversi lavori di ricerca alla base di questo studio.
+I lavori, sebbene tutti incentrati sul \ac{ML}, vanno ad approfondire diversi aspetti.
+In alcuni casi l'attenzione principale è rivolta alle difficoltà e alla problematiche riscontrate dagli sviluppatori.
+In altri casi viene svolto un confronto tra progetti di \ac{ML} e progetti generici o tra progetti che fanno uso di diversi framework di \ac{ML}.
+Infine viene anche presentato un lavoro sulla complessità del processo di cambiamento del software e su i suoi effetti sull'introduzione di difetti.
 
-Nello studio di Gonzalez *et al.* [@gonzalez2020statemluniverse10] ci vengono presentate le principali differenze tra i repository di \acl{ML} e i progetti classici.
+## Confronto tra progetti di machine learning e progetti generici
+
+Nello studio di Gonzalez *et al.* [@gonzalez2020statemluniverse10] ci vengono presentate le principali differenze tra i repository di \ac{ML} e i progetti classici.
 I dati per lo studio sono stati recuperati attraverso l'\ac{API} messa a disposizione di GitHub attraverso la quale è stato possible collezionare i dati associati a 9325 progetti open source così raggruppati:
 
 - 5224 progetti legati all'\ac{AI} e al \ac{ML} divisi a loro volta in:
@@ -13,7 +19,7 @@ I dati per lo studio sono stati recuperati attraverso l'\ac{API} messa a disposi
 Gli aspetti considerati dallo studio sono molteplici e di varia natura.
 Una prima analisi è stata condotta rispetto alla nascita dei vari repositories.
 In questo modo è stato possibile individuare nel 2017 l'anno del *boom* dei repositori di \ac{AI} & \ac{ML}.
-Infatti questo è stato il primo anno in cui sono stati creati più progetti legati al \acl{ML} rispetto a quelli generici.
+Infatti questo è stato il primo anno in cui sono stati creati più progetti legati al \ac{ML} rispetto a quelli generici.
 
 Una seconda analisi ha permesso di capire come varia la partecipazione ai vari progetti.
 Per poter svolgere questa analisi i contributori sono stati divisi in:
@@ -21,12 +27,12 @@ Per poter svolgere questa analisi i contributori sono stati divisi in:
 - *esterni*: i loro contributi sono limitati ad aprire *issues* e commentare le discussioni.
 - *interni*: oltre a svolgere i compiti precedentemente elencati devono anche aver chiuso delle issues o eseguito dei commit sul progetto.
 
-In base a questa divisione si è visto come i tools di \acl{ML} hanno un numero di contributori interni superiore rispetto ai progetti generici.
+In base a questa divisione si è visto come i tools di \ac{ML} hanno un numero di contributori interni superiore rispetto ai progetti generici.
 Quest'ultimi però hanno una maggiore partecipazione esterna.
 Se invece l'analisi viene svolta considerando unicamente gli autori dei commit si scopre che i progetti generici mediamente hanno più *contributors*, ma i top 4 repositories con più committer sono tutti legati al mondo del \ac{ML}.
 
 Un'ulteriore analisi è stata svolta anche per quanto riguarda il linguaggio con cui sono stati realizzati i vari progetti.
-Sia nel caso delle applicazioni che nei tools di \acl{ML} il linguaggio più popolare è Python, mentre la seconda posizione varia.
+Sia nel caso delle applicazioni che nei tools di \ac{ML} il linguaggio più popolare è Python, mentre la seconda posizione varia.
 Nel caso dei tools questa è occupata da C++, mentre nelle applicazioni dai Notebook Jupyter.
 Nei progetti generici invece Python occupa solo la terza posizione in quanto a popolarità e le prime due sono occupate da JavaScript e Java.
 
@@ -78,7 +84,7 @@ Da questi due studi si evince una forte somiglianza per quanto riguarda `TensorF
 La principale differenza viene riscontrata per quanto riguarda i campi di applicazione, con `TensorFlow` che viene generalmente preferito fatti salvi gli ambiti di ricerca.
 Mentre `Theano` presenta molte diversità sia per quanto riguarda gli impieghi che le discussioni.
 
-## Analisi dei progetti di ML multi-linguaggio
+## Analisi dei progetti di machine learning multi-linguaggio
 
 Lo studio di Grichi *et al.* [@grichi2020impactmultilanguagedevelopment] si concentra sui sistemi *multi-linguaggio*.
 In questo caso si vuole capire se i sistemi di \ac{ML} sono più soggetti all'essere realizzati attraverso linguaggi diversi.
@@ -87,32 +93,32 @@ Inoltre analizzando le \ac{PR} realizzate in più linguaggi si vuole capire se q
 L'analisi è stata svolta su 27 progetti open source hostati su GitHub.
 I progetti sono poi stati classificati in tre categorie:
 
-- Cat I: include 10 sistemi di \acl{ML} *multi-linguaggio*.
+- Cat I: include 10 sistemi di \ac{ML} *multi-linguaggio*.
 - Cat II: include 10 sistemi generici *multi-linguaggio*.
-- Cat III: include 7 sistemi di \acl{ML} *mono-linguaggio*.
+- Cat III: include 7 sistemi di \ac{ML} *mono-linguaggio*.
 
 Successivamente sono state scaricate le \ac{PR} di ogni progetto considerato.
 Le \ac{PR}s sono state categorizzate per individuare quelle accettate e quelle rifiutate.
-Inoltre le \acl{PR} sono state categorizzate anche il base al numero di linguaggi utilizzati.
+Inoltre le \ac{PR} sono state categorizzate anche il base al numero di linguaggi utilizzati.
 In questo modo è stato possibile individuare le \ac{PR} *mono-linguaggio* e quelle *multi-linguaggio*.
-Infine per ogni \ac{PR} è stato individuato il tempo necessario alla sua accettazione o chiusura e i difetti introdotti dalla \acl{PR}.
+Infine per ogni \ac{PR} è stato individuato il tempo necessario alla sua accettazione o chiusura e i difetti introdotti dalla \ac{PR}.
 
 Per quanto riguarda la percentuale di linguaggi di programmazione utilizzati i progetti della categoria I e II sono comparabili.
 La principale differenza riguarda i tipi di linguaggi utilizzati.
-Nel caso dei progetti *multi-linguaggio* di \acl{ML} l'accoppiata più comune è Python e C/C++.
+Nel caso dei progetti *multi-linguaggio* di \ac{ML} l'accoppiata più comune è Python e C/C++.
 Mentre nel caso dei progetti generici la coppia più comune è data da Java e C/C++.
 I progetti della categoria I e II sono paragonabili anche rispetto al numero di \ac{PR}s e \ac{PR}s *multi-linguaggio*.
 
-Lo studio ha evidenziato come all'interno dei progetti di \acl{ML} le \acl{PR} *mono-linguaggio* sono accettate molto più facilmente rispetto a quelle *multi-linguaggio*.
+Lo studio ha evidenziato come all'interno dei progetti di \ac{ML} le \ac{PR} *mono-linguaggio* sono accettate molto più facilmente rispetto a quelle *multi-linguaggio*.
 Inoltre anche nel caso in cui queste vengano accettate, il tempo necessario alla loro accettazione è maggiore.
 Infine si è visto anche che rispetto alle \ac{PR}s *multi-linguaggio* non esistono differenze in base all'introduzione di *bug* tra i progetti della categoria I e II.
-Mentre le \acl{PR} che includono un singolo linguaggio sembrano essere più affette da *bug* nel caso dei sistemi di \acl{ML}.
+Mentre le \ac{PR} che includono un singolo linguaggio sembrano essere più affette da *bug* nel caso dei sistemi di \ac{ML}.
 
-## Problematiche caratteristiche del ML
+## Problematiche caratteristiche del machine learning
 
-In letteratura sono presenti anche lavori che si concentrano sull'analisi delle problematiche e dei *bug* riscontrati all'interno di applicazioni di \acl{ML}.
+In letteratura sono presenti anche lavori che si concentrano sull'analisi delle problematiche e dei *bug* riscontrati all'interno di applicazioni di \ac{ML}.
 Nello studio di Zhang *et al.* [@zhang2018empiricalstudytensorflow] l'attenzione è rivolta unicamente alle problematiche correlate a `TensorFlow`.
-Per lo studio sono stati recuperati dei *bug* di `TensorFlow` sia da progetti su GitHub (88 elementi) sia da quesiti su \acl{SO} (87 elementi).
+Per lo studio sono stati recuperati dei *bug* di `TensorFlow` sia da progetti su GitHub (88 elementi) sia da quesiti su \ac{SO} (87 elementi).
 
 Gli autori dello studio, per poter individuare la causa dei *bug* e i loro sintomi hanno dovuto analizzare manualmente gli elementi del dataset.
 Nel caso di *bug* discussi su \ac{SO} le informazioni sono state recuperate dalla discussione.
@@ -134,12 +140,12 @@ Per quanto riguarda le cause è stato possibile individuarne sei:
 - *Structure Inefficiency*: questa categoria può essere vista come una versione più *soft* della prima categoria.
 Infatti in questo caso il problema nella struttura non genera un errore ma solo delle inefficienze.
 
-Anche lo studio di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults] ha come obbiettivo l'analisi delle problematiche legate al \acl{ML}.
+Anche lo studio di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults] ha come obbiettivo l'analisi delle problematiche legate al \ac{ML}.
 In questo caso però la visione è più ampia e non si limita ad una singola libreria.
 Inoltre in questo caso lo scopo ultimo del lavoro è la costruzione di una tassonomia per le problematiche di \ac{ML}.
 
-Anche in questo caso i dati sono stati recuperati sia da \acl{SO} che da GitHub.
+Anche in questo caso i dati sono stati recuperati sia da \ac{SO} che da GitHub.
-Inoltre per questo studio è stata anche svolta un'intervista a 20 persone tra ricercatori e sviluppatori nel campo del \acl{ML}.
+Inoltre per questo studio è stata anche svolta un'intervista a 20 persone tra ricercatori e sviluppatori nel campo del \ac{ML}.
 Partendo da questi dati è stata costruita una tassonomia attraverso un approccio *bottom-up*.
 La tassonomia si compone di 5 categorie *top-level*, 3 delle quali sono state divise in sotto categorie.
 
@@ -150,38 +156,38 @@ Tra le categorie di primo livello ci sono:
 - *Training*: questa categoria è la più ampia della tassonomia.
   Rientrano in questa categoria la qualità e il preprocessing dei dati utilizzati per l'apprendimento, il *tuning* degli *hyperparametri*, la scelta della funzione di perdita più appropriata ecc.
 - *GPU Usage*: in questa categoria ricadono tutti i problemi nell'uso della \ac{GPU}.
-- *API*: rientrano in questa categoria tutti i problemi generati da un non corretto utilizzo dell'\ac{API} del framework di \acl{ML}.
+- *API*: rientrano in questa categoria tutti i problemi generati da un non corretto utilizzo dell'\ac{API} del framework di \ac{ML}.
 
 Come si può notare, fatta salva la specificità del primo lavoro, esiste una forte similitudine tra le categorie di problemi individuate dai due studi.
 
-## Analisi delle discussioni di Stack Overflow riguardanti il ML
+## Analisi delle discussioni di Stack Overflow riguardanti il machine learning
 
-Nello studio di Bangash *et al.* [@bangash2019whatdevelopersknow] viene svolta un'analisi degli argomenti di \acl{ML} discussi più frequentemente dagli sviluppatori.
+Nello studio di Bangash *et al.* [@bangash2019whatdevelopersknow] viene svolta un'analisi degli argomenti di \ac{ML} discussi più frequentemente dagli sviluppatori.
 In questo caso, a differenza dello studio di Han *et al.* [@han2020whatprogrammersdiscuss] discusso precedentemente, non viene svolta alcuna distinzione in base alla libreria utilizzata.
-Inoltre questo studio utilizza unicamente informazioni recuperate da \acl{SO}, mentre l'altro lavoro univa le domande di \ac{SO} alla discussione generata all'interno dei repositories di GitHub.
+Inoltre questo studio utilizza unicamente informazioni recuperate da \ac{SO}, mentre l'altro lavoro univa le domande di \ac{SO} alla discussione generata all'interno dei repositories di GitHub.
 
 In questo caso il topic più frequentemente discusso riguarda la presenza di errori all'interno del codice.
 Seguono discussioni rispetto agli algoritmi di apprendimento e al training dei dati.
-Lo studio ha evidenziato anche come molte discussioni riguardano librerie e framework di \acl{ML} come ad esempio `numpy`, `pandas`, `keras`, `Scikit-Learn`, ecc.
+Lo studio ha evidenziato anche come molte discussioni riguardano librerie e framework di \ac{ML} come ad esempio `numpy`, `pandas`, `keras`, `Scikit-Learn`, ecc.
 Tutte queste discussioni sono state inserite nel topic *framework*.
 
-Anche nel lavoro di Alshangiti *et al.* [@alshangiti2019whydevelopingmachine] vengono analizzate le domande presenti sulla piattaforma \acl{SO}.
+Anche nel lavoro di Alshangiti *et al.* [@alshangiti2019whydevelopingmachine] vengono analizzate le domande presenti sulla piattaforma \ac{SO}.
-In questo caso però oltre ad un analisi qualitativa rispetto al contenuto di queste discussioni è stata eseguita anche un'analisi comparativa tra le discussioni inerenti al \acl{ML} e le altre.
+In questo caso però oltre ad un analisi qualitativa rispetto al contenuto di queste discussioni è stata eseguita anche un'analisi comparativa tra le discussioni inerenti al \ac{ML} e le altre.
 
 Per svolgere questa analisi gli autori sono partiti dal dump del database di \ac{SO} e hanno individuato tre campioni:
 
 - *Quantitative Study Sample*: si compone di 86983 domande inerenti al \ac{ML}, con le relative risposte.
-  L'individuazione dei post è avvenuta attraverso la definizione di una lista contente 50 tag utilizzate su \ac{SO} per le domande di \acl{ML}.
+  L'individuazione dei post è avvenuta attraverso la definizione di una lista contente 50 tag utilizzate su \ac{SO} per le domande di \ac{ML}.
 - *Qualitative Study Sample*: contiene 684 post realizzati da 50 utenti.
   Questo campione è stato ottenuto eseguendo un ulteriore campionamento sul campione discusso al punto precedente.
-- *Baseline Sample*: si compone di post che non riguardano il \acl{ML}.
+- *Baseline Sample*: si compone di post che non riguardano il \ac{ML}.
   Questo campione viene utilizzato per comparare le domande di \ac{ML} con quelle generiche.
 
-La prima *\ac{RQ}* dello studio vuole verificare se rispondere ad una domanda inerente al \acl{ML} sia più complicato.
+La prima *\ac{RQ}* dello studio vuole verificare se rispondere ad una domanda inerente al \ac{ML} sia più complicato.
 Per valutare la complessità di risposta sono state contate le domande che non presentano alcuna risposta, le domande che non presentano risposte accettate e la mediana del tempo necessario affinché una domanda abbia una risposta accettata.
 Dal confronto tra il primo e il terzo sample rispetto a queste metriche è emerso che i post inerenti al \ac{ML} hanno una maggiore probabilità di non avere risposte/risposte accettate.
-Inoltre si è visto come mediamente le domande di \acl{ML} necessitano di un tempo dieci volte maggiore per poter avere una risposta accettata.
+Inoltre si è visto come mediamente le domande di \ac{ML} necessitano di un tempo dieci volte maggiore per poter avere una risposta accettata.
-Una spiegazione a questo fenomeno ci viene fornita dalla seconda *\ac{RQ}* in cui viene evidenziato che all'interno della community di \acl{SO} c'è una carenza di esperti di \acl{ML} [^expertise-rank].
+Una spiegazione a questo fenomeno ci viene fornita dalla seconda *\ac{RQ}* in cui viene evidenziato che all'interno della community di \ac{SO} c'è una carenza di esperti di \ac{ML} [^expertise-rank].
 
 [^expertise-rank]: L'individuazione degli esperti è avvenuta secondo l'approccio *ExpertiseRank*.
 Questo approccio crea un grafo diretto, in cui gli utenti sono rappresentati dai nodi e gli archi rappresentano una relazione di aiuto, attraverso il quale è possibile determinare l'esperienza degli utenti.
@@ -190,7 +196,7 @@ Se l'utente C risponde ad una domanda di B, allora questo avrà una esperienza s
 
 Lo studio è stato in grado anche di individuare le fasi in cui gli sviluppatori riscontrano maggiori problematiche.
 In generale le maggiori difficoltà sono state riscontrate nel *preprocessing dei dati*, nella configurazione dell'ambiente di sviluppo e nel deployment del modello.
-Per quanto riguarda i task specifici del \acl{DL} le maggiori problematiche riguardano applicazioni di \ac{NLP} e riconoscimento degli oggetti.
+Per quanto riguarda i task specifici del \ac{DL} le maggiori problematiche riguardano applicazioni di \ac{NLP} e riconoscimento degli oggetti.
 Infine lo studio ha mostrato come, nonostante la vasta adozione, molti utenti riscontrano problemi nell'utilizzo dell'\ac{API} di `TensorFlow`.
 
 ## Entropia di un cambiamento {#sec:entropy}

src/chapter_3.md

@@ -2,28 +2,28 @@
 
 ## Research Questions
 
-Gli obiettivi di questa tesi illustrati nella @sec:goals sono stati racchiusi in cinque \acl{RQ} di seguito elencate.
+Gli obiettivi di questa tesi illustrati nella @sec:goals sono stati racchiusi in cinque \ac{RQ} di seguito elencate.
 
 - **RQ1**: *come il \ac{ML} e' distribuito sull'architettura dei progetti?*
 
   In questa *\ac{RQ}* si vuole investigare l'architettura dei progetti.
   In particolare l'attenzione viene concentrata sui files e sulle directories modificate durante interventi di *issues fixing*.
-  Obiettivo di questa domanda è anche individuare la percentuale di files che utilizzano import riconducibili a librerie e framework di \acl{ML}.
+  Obiettivo di questa domanda è anche individuare la percentuale di files che utilizzano import riconducibili a librerie e framework di \ac{ML}.
 - **RQ2**: *come sono distribuiti i bug sulle diverse fasi di \ac{ML}?* 
 
-  Il workflow tipico per lo sviluppo di un'applicazione di \acl{ML} si compone di più fasi.
+  Il workflow tipico per lo sviluppo di un'applicazione di \ac{ML} si compone di più fasi.
   L'obiettivo di questa *\ac{RQ}* è quello di individuare le fasi più critiche per quanto riguarda l'introduzione di difetti all'interno del prodotto software.
 - **RQ3**: *esiste una differenza di entropy tra \ac{ML} bug e altri bug?*
 
-  A partire dai lavori precedenti svolti sull'entropia di un cambiamento, si vuole capire se esiste una differenza in termini di entropia generata tra le correzioni dei difetti ascrivibili al \acl{ML} e gli altri difetti.
+  A partire dai lavori precedenti svolti sull'entropia di un cambiamento, si vuole capire se esiste una differenza in termini di entropia generata tra le correzioni dei difetti ascrivibili al \ac{ML} e gli altri difetti.
 - **RQ4**: *come varia il livello di discussione tra \ac{ML} bug e altri bug?*
 
   Questa *\ac{RQ}* riguarda il livello di discussione dei *bug*.
-  In particolare si vuole capire se, all'interno dei progetti di \acl{ML}, i bug generici sono discussi con lo stesso livello di approfondimento di quelli specifici del \ac{ML}.
+  In particolare si vuole capire se, all'interno dei progetti di \ac{ML}, i bug generici sono discussi con lo stesso livello di approfondimento di quelli specifici del \ac{ML}.
 - **RQ5**: *come varia il time-to-fix tra \ac{ML} bug e altri bug?*
 
   Un altro aspetto caratteristico di un *fix* è il tempo necessario per poter essere attuato.
-  Questa *\ac{RQ}* ha lo scopo di verificare l'esistenza di differenze tra i *bug* generici e quelli di \acl{ML}.
+  Questa *\ac{RQ}* ha lo scopo di verificare l'esistenza di differenze tra i *bug* generici e quelli di \ac{ML}.
 
 ## Selezione dei progetti
 
@@ -74,8 +74,8 @@ I due modelli considerati sono:
 - un modello *naïve Bayes* [@2021naivebayesclassifier; @harrington2012machinelearningaction].
 
 La classificazione mediante il classificatore statico non necessita di un *labeling* manuale dei dati, ma richiede la definizione dei vocaboli tipici del \ac{ML}.
-La lista dei termini caratteristici del \acl{ML} non è stata costruita da zero, ma è basata sul lavoro di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults].
+La lista dei termini caratteristici del \ac{ML} non è stata costruita da zero, ma è basata sul lavoro di Humbatova *et al.* [@humbatova-2019-taxonomyrealfaults].
-In questo modo tutte le issues che utilizzavano almeno un vocabolo tipico del \acl{ML} sono state classificate come issues di \ac{ML}.
+In questo modo tutte le issues che utilizzavano almeno un vocabolo tipico del \ac{ML} sono state classificate come issues di \ac{ML}.
 
 Nel caso del modello *naïve Bayes*, essendo questo un algoritmo di apprendimento supervisionato, si è resa necessaria una classificazione manuale delle issues.
 A tal scopo è stato eseguito un campionamento stratificato in base al progetto di provenienza di $376$ issues che sono state divise tra due lettori e labellate.
@@ -141,8 +141,8 @@ In particolare è stato conservato:
 - Le linee modificate.
 - La lista delle *issues* citate.
 
-A questo punto è stato possibile separare i *fix* di \acl{ML} da quelli generici.
+A questo punto è stato possibile separare i *fix* di \ac{ML} da quelli generici.
-La classificazione è avvenuta attraverso la lista delle issues citate all'interno del *commit message* e sono stati considerati come commit di \ac{ML} tutti quei commit che facevano riferimento ad almeno una issue di \acl{ML}.
+La classificazione è avvenuta attraverso la lista delle issues citate all'interno del *commit message* e sono stati considerati come commit di \ac{ML} tutti quei commit che facevano riferimento ad almeno una issue di \ac{ML}.
 
 ![Risultato della classificazione dei commit](figures/count-commit.pdf){#fig:count-commit width=80%}
 
@@ -153,9 +153,9 @@ La classificazione è avvenuta attraverso la lista delle issues citate all'inter
 ### RQ1: come il ML e' distribuito sull'architettura dei progetti?
 
 In questa prima domanda si vuole andare a capire quant'è ampia la *superficie* del progetto che viene modificata durante gli interventi di *fix*, facendo distinzione tra le correzioni che riguardano il \ac{ML} e quelle generiche.
-Inoltre si vuole anche capire quanti file importano librerie tipiche del \acl{ML}.
+Inoltre si vuole anche capire quanti file importano librerie tipiche del \ac{ML}.
 
-Per poter svolgere la prima analisi è stato necessario individuare il numero totale di file modificati per *fix* generici e per i *fix* specifici del \acl{ML}.
+Per poter svolgere la prima analisi è stato necessario individuare il numero totale di file modificati per *fix* generici e per i *fix* specifici del \ac{ML}.
 A tal fine i commit sono stati raggruppati rispetto al progetto e al tipo di cambiamento (\ac{ML}, no \ac{ML}).
 All'interno di ogni raggruppamento si è eseguita la concatenazione della lista dei file modificati.
 Poiché non si è interessati al numero di modifiche che ha subito ogni file le liste sono state trasformate in insiemi per eliminare le ripetizioni.
@@ -168,17 +168,17 @@ Infine eseguendo l'union set tra questi due insiemi si è ottenuto l'insieme tot
 A questo punto per ogni progetto si è calcolata la percentuale di file modificati durante interventi di *fix* di \ac{ML} (`ml_file_ratio`) e la percentuale di file modificati durante *fix* generici (`no_ml_file_ratio`).
 
 Attraverso la funzione di libreria Python `os.path.dirname` sono stati ottenuti i tre insiemi sopra citati anche per quanto riguarda le directories.
-E in modo analogo si è calcolata la percentuale di directories modificate durante interventi di \acl{ML} (`ml_dirs_ratio`) e interventi generici (`no_ml_dirs_ratio`).
+E in modo analogo si è calcolata la percentuale di directories modificate durante interventi di \ac{ML} (`ml_dirs_ratio`) e interventi generici (`no_ml_dirs_ratio`).
 Queste distribuzioni sono state analizzate graficamente attraverso l'ausilio di boxplot.
 
 Per la seconda analisi si è reso necessario conoscere per ogni file la lista degli import utilizzati.
 Questa informazione è stata recuperata attraverso uno script, che dato in input un progetto restituisce la lista dei files affiancati dalla lista degli import utilizzati all'interno del file stesso.
-L'individuazione dei file di \acl{ML} è avvenuta mediante la definizione di due gruppi di librerie tipiche del \ac{ML}.
+L'individuazione dei file di \ac{ML} è avvenuta mediante la definizione di due gruppi di librerie tipiche del \ac{ML}.
 
-- Gruppo 1: librerie specifiche del \acl{ML} come ad esempio `keras`, `TensorFlow` e `Pytorch`.
+- Gruppo 1: librerie specifiche del \ac{ML} come ad esempio `keras`, `TensorFlow` e `Pytorch`.
 - Gruppo 2: librerie utilizzate in ambito \ac{ML}, ma anche in altri contesti. Appartengono a questo gruppo librerie come `numpy`, `scipy` e `pandas`.
 
-Ogni file è stato classificato come di \acl{ML} o meno in base a due livelli severità.
+Ogni file è stato classificato come di \ac{ML} o meno in base a due livelli severità.
 Nel caso della severità *base* per rientrare all'interno dei file che fanno uso di librerie di \ac{ML} bastava importare almeno una libreria contenuta in uno dei due gruppi precedentemente descritti.
 Mentre nel caso di severità *strict* era necessario importare almeno una libreria presente nel primo gruppo.
 

src/chapter_4.md

@@ -3,18 +3,18 @@
 ## RQ1: come il ML e' distribuito sull'architettura dei progetti? {#sec:rq1}
 
 Dalla @fig:files-directories si può notare che i cambiamenti generici vanno ad impattare su una superficie maggiore del sistema, sia che l'analisi sia svolta al livello di files che di directories.
-Un'ulteriore aspetto interessante riguarda la varianza delle distribuzioni, infatti, indipendentemente dalla granularità dell'analisi, il dato riguardante i cambiamenti di \acl{ML} è caratterizzato da una maggiore varianza.
+Un'ulteriore aspetto interessante riguarda la varianza delle distribuzioni, infatti, indipendentemente dalla granularità dell'analisi, il dato riguardante i cambiamenti di \ac{ML} è caratterizzato da una maggiore varianza.
 
 ![Percentuale di files e directories modificate in base al tipo di cambiamento](figures/files-and-directories.pdf){#fig:files-directories width=100%}
 
 Nel boxplot in @fig:imports sono invece riportati i risultati per quanto riguarda l'utilizzo di import di \ac{ML}.
-Si può notare che, indipendentemente dalla severità dell'analisi, la percentuale di file che utilizzano librerie di \acl{ML} è caratterizzata da una forte varianza.
+Si può notare che, indipendentemente dalla severità dell'analisi, la percentuale di file che utilizzano librerie di \ac{ML} è caratterizzata da una forte varianza.
 Ciò indica che i progetti inclusi all'interno dello studio sono di varia natura e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
 Inoltre, considerando l'analisi *strict*, è possibile osservare come solo un $25\%$ dei progetti abbia una percentuale di files di \ac{ML} superiore al $45\%$.
 
 ![Percentuale di file che utilizzano librerie di ML](figures/imports.pdf){#fig:imports width=80%}
 
-In relazione all'analisi *strict* sono stati poi analizzati i cinque progetti più \acl{ML} *intensive* per valutare eventuali caratteristiche comuni rispetto al dominio applicativo.
+In relazione all'analisi *strict* sono stati poi analizzati i cinque progetti più \ac{ML} *intensive* per valutare eventuali caratteristiche comuni rispetto al dominio applicativo.
 Com'è possibile notare dalla @tbl:ml-intensive i vari progetti si occupano di problematiche diverse, ma in quasi tutti i casi è prevista l'estrapolazione di informazioni da immagini.
 L'unica eccezione è data dal progetto *jdb78/pytorch-forecasting* che si occupa del *forecasting* di serie temporali.
 
@@ -84,7 +84,7 @@ Osservando invece il boxplot[^boxplot-discussion] in @fig:discussion-comments si
 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.
 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 cinque, quindi nel $50\%$ interno tutte le issues hanno almeno un commento di risposta.
+Mentre la differenza interquartile dei *fix* di \ac{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.
 
@@ -104,7 +104,7 @@ Mentre la differenza interquartile dei *fix* di \acl{ML} è compreso tra uno e c
 
 I risultati dell'analisi rispetto alle parole medie contenute in un commento 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.
-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 \ac{ML} c'è maggiore discussione, ma la discussione è anche più *densa*.
 
 Anche in questo caso sono stati svolti i test statistici.
 In @tbl:test-discussion è possibile vedere come per entrambe le metriche considerate il *p-value* sia abbondantemente inferiore alla soglia di $0.05$ quindi abbiamo una conferma della diversità delle due distribuzioni riscontrata dal boxplot.
@@ -133,14 +133,14 @@ Ne sono un esempio la issue tratta precedentemente nel caso dei commenti, ma anc
 Altri fattori che contribuiscono a spiegare questo dato sono la presenza di blocchi di errori (*mittagessen/kraken/206*) o messaggi di log utili ad inquadrare l'origine del problema (*robertmartin8/PyPortfolioOpt/177*).
 
 \begin{tcolorbox}[colback=white, boxrule=0.3mm]
-Le \emph{issues} di \acl{ML} sono caratterizzata da una maggiore discussione.
+Le \emph{issues} di \ac{ML} sono caratterizzata da una maggiore discussione.
 Un valore molto elevato di parole per commento può indicare uno scambio massiccio all'interno della discussione di \emph{snippet} di codice, di log d'errore e configurazioni dell'ambiente.
 \end{tcolorbox}
 
 ## RQ5: come varia il time-to-fix tra ML bug e altri bug? {#sec:rq5}
 
 Anche in questo caso, osservando la @fig:day-to-fix, è 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 \ac{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.
 Questo vuol dire che il $50\%$ basso dei *bug* di \ac{ML} viene comunque risolto in tempi brevi (due giorni circa), mentre l'altro $50\%$ può richiedere una quantità di tempo decisamente superiore.
 
@@ -148,7 +148,7 @@ Questo vuol dire che il $50\%$ basso dei *bug* di \ac{ML} viene comunque risolto
 
 Un'ulteriore testimonianza del maggior tempo necessario per risolvere le problematiche legate al \ac{ML} ci viene data dagli outlier.
 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 una *issue*, necessaria di un *time-to-fix* superiore ai trentacinque giorni.
+Mentre nel caso dei *fix* di \ac{ML} per essere considerato outlier una *issue*, necessaria di un *time-to-fix* superiore ai trentacinque giorni.
 
 Il maggior tempo necessario ad attuare la correzione indica che i *bug* di \ac{ML} sono più difficili da individuare e correggere rispetto a quelli generici.
 Inoltre questo risultato contribuisce a spiegare il dato emerso dalla sezione precedente, in quanto per individuare la fonte del problema sembrerebbe essere necessaria una discussione più approfondita.
@@ -173,7 +173,7 @@ Questi risultati non solo confermano la differenza osservata nel boxplot, ma ci
 : Risultati dei test statistici per quanto riguarda il time-to-fix {#tbl:test-time-to-fix}
 
 \begin{tcolorbox}[colback=white, boxrule=0.3mm]
-Le problematiche di \acl{ML} richiedono più tempo per essere risolte.
+Le problematiche di \ac{ML} richiedono più tempo per essere risolte.
 La bassa priorità di una \emph{issue} e la presenza di \emph{work around} sono fattori che contribuiscono a ritardare l'intervento di \emph{fix}.
 \end{tcolorbox}
 

src/chapter_5.md

@@ -1,18 +1,18 @@
 # Conclusioni {#sec:conclusions}
 
 La *RQ1* (@sec:rq1) ci ha permesso di inquadrare la natura dei progetti considerati per questo studio.
-Attraverso l'analisi degli import si è mostrato come l'utilizzo di librerie di \acl{ML} vari a seconda del progetto.
+Attraverso l'analisi degli import si è mostrato come l'utilizzo di librerie di \ac{ML} vari a seconda del progetto.
 Da questo dato si può capire che i progetti all'interno del dataset sono diversi tra di loro e che alcuni sono più incentrati sul \ac{ML} rispetto ad altri.
-Si è anche visto che la percentuale di progetti con un numero di *source files* di \acl{ML} superiore al $45\%$ sia molto limitata.
+Si è anche visto che la percentuale di progetti con un numero di *source files* di \ac{ML} superiore al $45\%$ sia molto limitata.
 Inoltre andando ad analizzare la porzione di sistema impattata dai cambiamenti si è visto come anche in questo caso il dato sia caratterizzato da una forte variabilità.
 
-Le *RQ3*, *RQ4* e *RQ5* (da @sec:rq3) sono andate a valutare nello specifico le differenze in termini di entropia, discussione e *time-to-fix* tra gli interventi di *issue fixing* generici e quelli specifici del \acl{ML}.
+Le *RQ3*, *RQ4* e *RQ5* (da @sec:rq3) sono andate a valutare nello specifico le differenze in termini di entropia, discussione e *time-to-fix* tra gli interventi di *issue fixing* generici e quelli specifici del \ac{ML}.
 Da queste analisi si evince che tra i due tipi di interventi ci sono sia similitudini che differenze.
 Nel caso dell'entropia e della complessità del processo di cambiamento del software non sono emerse differenze rilevanti.
 Questo ci porta a pensare che il processo di cambiamento non varia in base al tipo di intervento, ma sia costante.
 
 Nel caso del livello di discussione e del *time-to-fix* sono emerse delle differenze confermate anche dai test statistici effettuati.
-In entrambi i casi l'essere un *fix* legato al \acl{ML} ha spinto la metrica verso l'alto.
+In entrambi i casi l'essere un *fix* legato al \ac{ML} ha spinto la metrica verso l'alto.
 Nel caso dei messaggi scambiati non solo si è riscontrato un numero medio di messaggi più elevato, ma si è visto anche che questi mediamente sono più lunghi.
 Questo dato potrebbe dipendere sia dal maggiore tempo richiesto per d'individuazione e correzione delle problematiche legate al \ac{ML}, sia da un maggiore interesse per queste problematiche rispetto alle altre.