L uso di R per il calcolo delle stime e degli errori: risultati ottenuti e lavori in corso

Transcript

1 Il software per la statistica ufficiale: dai sistemi proprietari a quelli open source Roma, 4 marzo 2008 L uso di R per il calcolo delle stime e degli errori: risultati ottenuti e lavori in corso Diego Zardetto, Monica Scannapieco Istat Direzione centrale per le tecnologie ed il supporto metodologico

2 Sintesi La presente relazione documenta in modo sintetico i risultati conseguiti dagli autori con riferimento alle due seguenti attività: 1) test di fattibilità della migrazione da SAS ad R di una specifica fase del processo di produzione delle indagini campionarie: la calibrazione dei dati ed il calcolo di stime ed errori, 2) progettazione e sviluppo di un software interamente basato su R in grado di sostituire una applicazione di uso comune in Istat e basata su SAS: il software GENESEES. 1 Introduzione Da tempo in Istat è in corso una riflessione sulla possibilità e l opportunità di sostituire una parte dei software proprietari utilizzati con software liberi (free) ed a codice sorgente aperto (open source). Tale riflessione coinvolge a pieno titolo il sistema SAS 1 che, entrato in Istituto nei primi anni 80 come software per l analisi dei dati e la ricerca statistica, è divenuto nel tempo il sistema di elaborazione dominante in buona parte dei processi di produzione dell informazione statistica. E in questo contesto che deve essere collocato il lavoro di cui la presente relazione intende dare conto. Essa ha, infatti, lo scopo di documentare in modo sintetico i risultati conseguiti dagli autori con riferimento a due attività logicamente interconnesse, sebbene distinte e temporalmente sequenziali: la prima attività, che definiremo di sperimentazione, si è concretizzata nel test di fattibilità della migrazione da SAS ad R di una specifica fase del processo di produzione delle indagini campionarie: la calibrazione dei dati ed il calcolo di stime ed errori; la seconda attività, innescata dall esito positivo del test e tuttora in corso, concerne la progettazione e lo sviluppo di un software interamente basato su R in grado di sostituire una applicazione di uso comune in Istat e basata su SAS: il software GENESEES. 2 Necessità del test di fattibilità Oggi R viene generalmente ritenuto il candidato naturale a sostituire, in una ottica di medio periodo, il sistema SAS in Istat. Tuttavia, quando circa due anni fa si diede inizio allo studio sistematico di R, in Istituto esistevano due punti di vista radicalmente divergenti sul nuovo strumento software: da una parte si registrava un consenso unanime sulle grandi potenzialità di R nell analisi dei dati e nella ricerca statistica, dall altra, un diffuso scetticismo sulla capacità di R, come sistema di elaborazione tout court, di incontrare le esigenze tipiche dei processi di produzione dell Istat. Lo scetticismo si articolava su tre dubbi principali: 1) Gestione di grosse moli di dati. Alcune delle fasi in cui è tradizionalmente scomposto, in un istituto di statistica ufficiale, il processo di produzione delle informazioni statistiche, richiedono l elaborazione automatica di ingenti moli di dati. Oltre al caso evidente dei Censimenti Generali, questa considerazione si applica, in Istat, alle principali indagini campionarie condotte su vasta scala. Il dubbio sulle potenzialità di R discende, a questo proposito, direttamente da un noto punto debole del sistema: la gestione della memoria. In effetti, R, al contrario del SAS, non dispone di un sofisticato sistema di buffering in grado di ottimizzare la gestione dello swapping su memoria secondaria. R delega questa operazione al sistema operativo. Per conseguenza, se un processo R usa più memoria della RAM disponibile, tipicamente diventa molto lento. Inoltre una sessione R su piattaforma Windows a 32 bit non può ottenere dal sistema operativo più di 3GB di memoria allocabile. 1 Il CNIPA, nel parere trasmesso nel 2004 in occasione del rinnovo delle licenze fornite dal SAS Institute, premeva affinché l Istat effettuasse una sperimentazione di prodotti software alternativi, anche di tipo open source, al fine di eliminare, o di contenere, la dipendenza dei sistemi e di conseguenza dell attività istituzionale dell Istituto da un unico fornitore e da un unica tecnologia proprietaria. Nel parere del 2005 il CNIPA ribadiva quanto sopra ed invitava l Istat a procedere in tempi brevi a sperimentare tali prodotti. 2

3 2) Velocità di elaborazione. Le elaborazioni cui vengono sottoposti i dati di indagine sono, talvolta, caratterizzate da elevata complessità computazionale. Se si considera che, come accennato al punto precedente, esse coinvolgono spesso ingenti moli di dati, si comprende facilmente l esigenza di sistemi software particolarmente efficienti. Da questo punto di vista il dubbio su R discende direttamente dalla sua natura di linguaggio interpretato. Tale caratteristica penalizza in modo particolare l efficienza dei programmi R che fanno ricorso a cicli: essi risultano, infatti, 2 ordini di grandezza più lenti di compilati C o Fortran. R, d altra parte, dispone di metodi di vettorizzazione davvero efficienti e flessibili, che consentono, nella maggior parte dei casi, di evitare le strutture di ciclo. 3) Affidabilità dei package aggiuntivi. L Istat, come istituto di statistica ufficiale, ha il dovere di garantire il rispetto, nella propria attività di elaborazione dei dati, dei più severi standard metodologici. Ciò richiede, dal punto di vista informatico, di accertare in modo rigoroso l affidabilità dei processi software cui venga demandata la soluzione automatica di specifici problemi statistici. Il dubbio su R riguarda, in questo rispetto, proprio la sua natura free e open source: l assenza, cioè, di una software-house grande ed importante (come il SAS Institute) in grado di certificare (per così dire) i programmi resi disponibili. Fra i tre dubbi esposti, quest ultimo appare certamente il più insidioso. Infatti la maggiore ricchezza del software R risiede proprio nei suoi oltre (ad oggi) package aggiuntivi, dedicati alla soluzione di problemi specifici. Sebbene costituiscano un enorme patrimonio di risorse informatiche (per di più in continua e veloce crescita) tali package sono prodotti e resi disponibili a titolo gratuito alla comunità mondiale degli utilizzatori da una libera comunità di sviluppatori nonprofessionisti, generalmente provenienti dal mondo accademico e della ricerca. Nessuno dei tre dubbi esposti poteva essere astrattamente liquidato come destituito di fondamento. Per conseguenza, l iniziale scetticismo registrato sulla proposta di R come alternativa al SAS in Istat esigeva attenzione e risposte difendibili. Allo scopo di ricercare tali risposte, fondandole su evidenze empiriche e su risultati riproducibili, si è ritenuto necessario dare inizio ad una sperimentazione finalizzata a testare la fattibilità della migrazione da SAS ad R di una specifica fase del processo di produzione. 3 Caratteristiche del test di fattibilità Il primo passo da compiere, nel progettare il test di fattibilità, riguardava la scelta di una specifica fase del processo di produzione. Abbiamo ritenuto opportuno selezionare la fase di calibrazione (o ponderazione vincolata) dei dati, propedeutica all utilizzo degli stimatori di calibrazione per il calcolo delle stime e degli errori standard. Occorreva, poi, isolare una particolare indagine campionaria, i cui dati potessero fungere da terreno concreto di sperimentazione. La nostra scelta è ricaduta sull indagine Forze di Lavoro (FOL), una delle maggiori indagini correnti condotte dall Istat. In terzo luogo è stato necessario setacciare la ricca offerta di package aggiuntivi di R, per individuarne uno che coprisse, almeno in parte, le esigenze tipiche della fase di calibrazione. Il candidato migliore è stato individuato nel package survey, un package maturo (cioè giunto ad una versione stabile) sviluppato da Thomas Lumley, professore di biostatistica dell università di Washington e membro del R-Core development team. Il criterio in base al quale sono state operate le scelte (i) della fase di calibrazione e (ii) dell indagine FOL, obbedisce alla volontà di determinare, nel test di fattibilità, il banco di prova più severo possibile per R. Si è inteso, in altri termini, selezionare le elaborazioni che si presumeva fossero in grado di mettere in massima difficoltà il software, sollecitandone proprio i punti deboli illustrati nel capitolo 2: gestione di elaborazioni di elevata complessità computazionale su grandi moli di dati. E del tutto evidente, fra l altro, che condurre il test di fattibilità nel cosiddetto worst-case scenario avrebbe avuto il vantaggio di garantire, nell eventualità di un esito positivo del test, la fattibilità della migrazione in tutti i contesti applicativi più semplici di quello esplicitamente indagato. 3

4 Relativamente alla dimensione delle strutture dati manipolate, occorre precisare come l indagine FOL non sia stata scelta tanto per la sua, pur cospicua, dimensione campionaria, quanto, piuttosto, per il fatto che nella fase di calibrazione dei dati FOL viene imposto un numero molto elevato di vincoli. E, infatti, proprio l elevato numero di vincoli a far esplodere la dimensione delle strutture dati che il software deve elaborare per risolvere il problema di calibrazione. 3.1 Il problema di calibrazione Come già accennato, la fase di calibrazione dei dati è, nelle indagini campionarie, propedeutica all utilizzo degli stimatori di calibrazione per il calcolo delle stime e dei relativi errori standard ed intervalli di confidenza. Gli stimatori di calibrazione possono essere visti come un raffinamento dei più semplici stimatori di Horvitz-Thompson (HT). Gli stimatori HT sono costruiti a partire dai cosiddetti pesi diretti delle unità selezionate nel campione. I pesi diretti dipendono solo dal disegno di campionamento adottato (eguagliano, per la precisione, gli inversi delle probabilità di inclusione delle unità nel campione) ed il loro calcolo non presenta, in genere, alcuna difficoltà. D altra parte, gli stimatori HT, pur essendo corretti (almeno in assenza di mancate risposte totali), non sono particolarmente efficienti. Gli stimatori di calibrazione, solo asintoticamente corretti, sono in grado di determinare, rispetto a quelli HT, un notevole guadagno di efficienza, vale a dire una cospicua riduzione della varianza campionaria delle stime. Tale notevole proprietà discende dal fatto che gli stimatori di calibrazione fanno esplicitamente uso di informazioni ausiliarie, relative alla popolazione obiettivo dell indagine ma derivate da fonti ad essa esterne. Queste informazioni vengono tipicamente rappresentate nella forma di totali noti di variabili ausiliarie : ci si deve, allora, attendere (in genere) un guadagno in efficienza tanto maggiore quanto maggiore risulti la correlazione fra le variabili ausiliarie e le variabili di interesse su cui si intenda calcolare le stime. Il prezzo da pagare per fruire dei vantaggi degli stimatori di calibrazione consiste nel fatto che essi fanno ricorso a pesi più complessi dei pesi diretti usati dagli stimatori HT. In effetti il calcolo dei cosiddetti pesi calibrati (o pesi finali ) richiede di risolvere un complesso problema di ottimizzazione vincolata. La funzione da minimizzare è una funzione di distanza G tra i pesi diretti d k e i pesi calibrati w k, e i vincoli sono rappresentati da condizioni di uguaglianza delle stime campionarie dei totali delle variabili ausiliarie con i rispettivi totali noti della popolazione: min k k s w s G( d, w ) k x k k = X k (1) Nell equazione precedente è stato indicato con X il vettore dei totali noti e con x k il vettore delle variabili ausiliare osservate sulla k-esima unità campionaria. Al problema formulato nell equazione (1) vengono, molto spesso, aggiunti ulteriori vincoli, detti vincoli di range, del tipo seguente: w L k U k s con 0 L 1 U (2) d k Attraverso il sistema di disequazioni (2) è, infatti, possibile eliminare il rischio che i pesi finali, soluzione del problema (1), presentino valori patologici (ad esempio, negativi) o indesiderati (ad esempio, enormi rispetto ai pesi diretti). L espressione problema di calibrazione è comunemente usata per designare il complesso delle equazioni (1) e (2). 4

5 3.2 La calibrazione in Istat Nei contesti applicativi reali il problema di calibrazione non può essere risolto analiticamente. Occorre, dunque, demandarne la soluzione ad appositi programmi di calcolo che operino per via numerica. Un software che risolva il problema di calibrazione acquisirà come dati di input i pesi diretti d k, la funzione distanza G, le variabili ausiliarie x k, i totali noti X, ed i bounds [L,U] e restituirà, come output principale, il vettore dei pesi calibrati w k. Il calcolo dei pesi calibrati per le indagini campionarie dell Istat è correntemente effettuato da un sistema software dedicato: GENESEES. Il sistema GENESEES (GENEralized Sampling Estimates and Errors in Surveys) è stato sviluppato in Istat a partire dalla fine degli anni 90, è disponibile nella versione stabile attuale dal 2001/2002 ed è interamente implementato in SAS (principalmente in SAS Macro e IML, per gli algoritmi di calcolo, e in SAS/AF con SCL, per l interfaccia utente di tipo grafico). Oltre alla funzionalità di calibrazione, il sistema rende disponibili agli utenti funzionalità per il calcolo delle stime, degli errori standard e degli intervalli di confidenza degli stimatori di uso più comune (totali, medie, rapporti). Il metodo di stima della varianza campionaria che implementa è il cosiddetto metodo analitico, basato sulla linearizzazione di Taylor e sulla teoria degli stimatori di regressione generalizzata. Come è stato illustrato nel capitolo 3, il test di fattibilità oggetto della presente relazione riguarda la migrazione da SAS ad R del processo di calibrazione dei dati FOL. In questo contesto il candidato naturale a giocare il ruolo di sistema di benchmark è, ovviamente, proprio GENESEES. 4 Fasi del test di fattibilità Il test di fattibilità introdotto nel capitolo 3 è stato strutturato nel modo sintetizzato dallo Schema 1. Esso si articola in tre macro fasi temporalmente sequenziali (che, però, si scambiano informazioni in modo non banale, come rappresentato nello schema dalle frecce), a loro volta decomposte in sottofasi logicamente distinte (seppure non necessariamente sequenziali). Fase 1: Definizione dell ambiente di test 1.1: Selezione sistema di benchmark 1.2: Selezione dati di benchmark Fase 2: Sviluppo prototipale per il test 1.3: Ambiente HW e SW di sperimentazione 2.1: Definizione dell ambiente di prototipazione 2.2: Test di efficacia Fase 3: Realizzazione del test di fattibilità 3.1: Test di efficienza e ottimizzazione 2.3: Test di efficienza 3.2: Test di efficacia e correzione Schema 1: Scomposizione del test di fattibilità in macro fasi temporali e sottofasi logiche 5

6 Lo scopo delle tre macro fasi, le operazioni in esse effettuate ed i risultati conseguiti sono concisamente illustrati in quanto segue. Fase 1: Definizione dell ambiente di test. In questa fase è stato definito l ambiente di test, sono state, cioè, operate le scelte definitive (1.1) del sistema software di benchmark, (1.2) dei dataset su cui condurre il test e (1.3) delle caratteristiche software (SW) ed hardware (HW) delle piattaforme tecnologiche da utilizzare. Sulla base di quanto argomentato nelle sezioni 3 e 3.2, il sistema di benchmark coincide con il sistema da cui migrare: GENESEES/SAS. La volontà di condurre il test nel cosiddetto worstcase scenario (come anticipato nel capitolo 3) ha, poi, comportato la selezione dei dataset dell indagine FOL come dati di benchmark. Infine, le caratteristiche HW e SW delle piattaforme sono state scelte in modo da rispecchiare le dotazioni standard disponibili in Istat: PC Windows XP, 760 MB RAM, CPU da 3 GHz e Server Linux, 10 GB RAM, 4 CPU da 2 GHz. Fase 2: Sviluppo prototipale per il test. La fase di sviluppo prototipale si è rivelata fondamentale per il progetto dei test comparativi di efficacia ed efficienza eseguiti nella successiva fase 3. Grazie ad essa è stato possibile (i) prendere dimestichezza con il package survey di R, comprenderne l architettura generale e testarne in modo estensivo le singole funzioni, (ii) stabilire esattamente in quale misura le soluzioni proposte da survey/r fossero sovrapponibili a quelle di GENESEES\SAS e (iii) adattarle ad esse mediante interventi mirati di programmazione. Il test delle funzioni è stato condotto, in questa fase, variando quanto più possibile le configurazioni dei parametri di input ed operando su dataset di prova di dimensione ridotta, in modo da posporre ogni considerazione relativa alla loro efficienza su dataset realistici (quali quelli di benchmark). In ogni caso, gli esiti dei test prototipali di efficacia (2.1) ed efficienza (2.2), oltre a segnalare con prontezza errori e/o malfunzionamenti, hanno fornito preziose indicazioni su quale fosse il modo più opportuno di realizzare i test effettivi della fase 3. Fase 3: Realizzazione del test di fattibilità. Una volta garantito, come esito della fase di sviluppo prototipale per il test, che il software survey/r adattato risolvesse esattamente lo stesso problema della funzione di calibrazione di GENESEES/SAS, si è proceduto al test comparativo dei due sistemi sui dati di benchmark dell indagine FOL. Lo studio ha previsto il confronto sistematico delle performance dei due software, sia dal punto di vista dell efficacia (correttezza dei risultati) che dell efficienza (in termini di gestione della memoria e tempi di esecuzione). Gli esiti principali sono brevemente discussi nel capitolo 5. 5 Risultati del test di fattibilità In quanto segue riportiamo in estrema sintesi i principali risultati conseguiti nel test comparativo di survey/r e GENESEES/SAS sul problema di calibrazione dell indagine FOL. 5.1 Efficacia Il modo più semplice ed immediato per valutare l efficacia della funzionalità di calibrazione di survey/r, usando GENESEES/SAS come benchmark, consiste nel confrontare gli oltre pesi finali ottenuti, a partire dai dati dell indagine FOL, con i due sistemi. Nello scatter plot di Figura 1 sono riportati in ascissa i pesi calibrati calcolati con il sistema di benchmark GENESEES/SAS ed in ordinata le differenze relative fra i pesi in ascissa e quelli calcolati con il sistema survey/r. La scala dell asse delle ascisse fornisce immediatamente la sensazione di un ottimo accordo fra i due software. 6

7 Figura 1: Scatter plot (in ordinata i pesi calibrati da GENESEES/SAS, in ascissa le differenze relative fra i pesi in ascissa e quelli calcolati con il sistema survey/r) Una valutazione più precisa della misura di tale accordo può essere ricavata dallo studio delle distribuzioni delle differenze relative fra i pesi prodotti in output dai due software. In Figura 2 è riportata la sintesi della distribuzione delle differenza relative ottenuta usando la funzione summary di R. La massima differenza relativa fra il peso finale attribuito da GENESEES/SAS ad un arbitrario record del data set di Forze Lavoro ed il corrispondente peso calcolato da survey/r è di ordine 10-7 (la media addirittura di ordine ). E, per conseguenza, lecito asserire che i risultati prodotti dai due software sono, a tutti gli effetti pratici, identici. > summary(abs(pesi_genesees-pesi_survey)/pesi_genesees) Min. 1st Qu. Median Mean 3rd Qu. Max e e e e e e-7 Figura 2: Sintesi della distribuzione delle differenza relative fra i pesi calibrati da GENESEES/SAS e survey/r 5.2 Efficienza La funzione cui è demandata, nel package survey, la soluzione del problema di calibrazione (nella formulazione generale espressa nelle equazioni (1) e (2) della sezione 3.1) è la funzione calibrate. L esito dei test di efficienza della funzione calibrate è sintetizzato nella Tabella 1: righe successive della tabella si riferiscono a versioni cronologicamente successive della funzione. 7

8 In ambiente server, i primi tentativi di invocazione della calibrate sui dataset completi dell indagine FOL non sono andati a buon fine. Il comportamento dell applicazione era scoraggiante: dopo esser stata attiva per circa 4 giorni ed aver compiuto le 50 iterazioni di default, la calibrate terminava senza convergere. Tale circostanza appariva preoccupante per due ragioni concettualmente distinte: (i) la mancata convergenza dell algoritmo di Newton- Raphson, nonostante il problema di calibrazione fosse certamente compatibile ed il numero di iterazioni effettuate congruo; (ii) l estrema lentezza dell applicazione, nonostante la cospicua dotazione di RAM e CPU del server. Per individuare la causa della mancata convergenza è stato necessario procedere ad una analisi puntuale del codice della calibrate. Ciò ci ha condotto all individuazione di un bug del programma: un errore commesso nel calcolo della derivata prima della funzione di calibrazione associata alla distanza logaritmica. L errore in questione degradava a tal punto la velocità di convergenza dell algoritmo di Newton-Raphson da renderlo, a tutti gli effetti, inutilizzabile. La correzione del bug ha portato alla scrittura di una nuova funzione calibrate ( calibrate corretta in Tabella 1) che è stata sostituita a quella originariamente fornita dal package survey. Il tempo di esecuzione della nuova calibrate su server è risultato di circa 2 ore e mezza, e la convergenza è stata raggiunta in 5 iterazioni. In ultimo, il bug individuato è stato segnalato all autore di survey che ha provveduto a fissarlo nella successiva release del package. La correzione del bug, sebbene abbia velocizzato l algoritmo risolutivo della calibrate (diminuendo il numero di iterazioni necessarie per ottenerne la convergenza), non si è rivelata sufficiente a risolvere alla radice il problema della lentezza della funzione. Anzi, lo studio del comportamento della calibrate in ambiente PC ha confermato in modo evidente come la funzione non fosse dispendiosa solo in termini di cicli CPU, ma anche e in certo senso più gravemente in termini di memoria. In effetti, il tentativo di invocare su PC la calibrate (con gli stessi parametri utilizzati in ambiente server) ha portato alla saturazione della memoria disponibile (si veda la prima riga della Tabella 1). Funzione Ambiente Tempo R calibrate originaria PC R calibrate originaria Server > 4 giorni R calibrate corretta PC R calibrate corretta Server 155 minuti R calibrate_iter PC 84 secondi R calibrate_iter Server 86 secondi Tabella 1: Tempi di esecuzione della funzione calibrate del package survey sui dati dell indagine FOL La ricerca di una soluzione in grado di garantire, anche in ambiente PC, l uso della calibrate, ci ha condotto a riconsiderare la struttura algebrica del problema di calibrazione. L esito dell analisi si è concretizzato nella progettazione di una versione iterata della funzione (indicata con il nome calibrate_iter in Tabella 1). Per la precisione, in virtù della natura delle variabili ausiliarie e dei vincoli usati nell indagine FOL, è stato possibile decomporre l originale problema di calibrazione in sottoproblemi indipendenti, ciascuno dei quali relativo ad una sola sotto-popolazione regionale. I benefici di tale decomposizione del problema riguardano sia la memoria che il carico computazionale, e, quindi, il tempo di elaborazione. In effetti la calibrate_iter, oltre ad evitare la saturazione della memoria del PC, si è rivelata particolarmente efficiente, ottenendo il risultato atteso in circa 90 secondi; il tempo di esecuzione registrato in ambiente server è confrontabile con quello osservato in ambiente PC. 8

9 In GENESEES/SAS l esecuzione della funzione riponderazione, con input costituito dal dataset dell indagine FOL, ha comportato un tempo totale di esecuzione di circa 9 minuti (in ambiente PC). Poiché il processo di calibrazione eseguito da GENESEES/SAS è anch esso iterativo, il tempo in esame deve essere paragonato a quello della calibrate_iter in ambiente PC. Da tale confronto risulta che la calibrate_iter è circa 6 volte più veloce della funzione di riponderazione del sistema di benchmark. La differenza di performance è imputabile a molteplici fattori, che includono certamente la diversa natura dei linguaggi di programmazione utilizzati (R e SAS/IML) e la diversa progettazione del software. In più va ricordato che la funzione di riponderazione di GENESEES/SAS, oltre a calcolare i pesi finali del processo di calibrazione, produce anche data set e report di diagnostica (funzionalità, quest ultima, non prevista dalla calibrate). In conclusione, l esito del test di fattibilità si è rivelato positivo. Al prezzo di un numero contenuto di interventi mirati di programmazione è stato, infatti, possibile ottenere con il software survey/r risultati comparabili (se non addirittura superiori) a quelli del sistema di benchmark (sia in termini di efficacia, sia in termini di efficienza). 6 Il progetto di migrazione di GENESEES L esito positivo del test di fattibilità condotto sulla fase di calibrazione ed analoghi, incoraggianti risultati nel calcolo di stime ed errori standard, hanno consentito di avviare un progetto più ambizioso: l effettiva migrazione del sistema GENESEES da SAS ad R. Obiettivo minimo di tale migrazione è il progetto e lo sviluppo di un sistema interamente basato su R (che indicheremo, in quanto segue, col nome GENESEES/R) in grado di replicare le funzionalità principali di GENESEES/SAS. E chiaro che la migrazione di un sistema complesso come GENESEES dall ambiente SAS all ambiente R, dotato di caratteristiche tecnologiche e paradigma di programmazione profondamente diversi, non possa realisticamente ridursi ad una operazione di semplice traduzione di codice. Occorre, al contrario, ripensare le soluzioni adottate e riprogettare, almeno parzialmente, l applicazione. Da questo punto di vista la migrazione di GENESEES può essere riguardata come una occasione per re-ingegnerizzare il software, tentando di migliorarne la qualità complessiva. La Tabella 2 riporta in modo schematico le caratteristiche dell originario sistema GENESEES/SAS e quelle del progetto del sistema migrato GENESEES/R. Caratteristiche GENESEES/SAS GENESEES/R LINGUAGGIO SAS R ARCHITETTURA STANDALONE STANDALONE INTERFACCIA GUI GUI MONOLITICO ( ) MODULARE ( + ) QUALITA DEL SOFTWARE LEGACY ( ) ESTENDIBILE ( + ) EFFICIENZA ( = ) EFFICIENZA ( = ) Tabella 2: Principali caratteristiche del sistema GENESEES/SAS e del progetto GENESEES/R Riteniamo che il paradigma funzionale di R spinga intrinsecamente ad uno stile di progettazione del software più spiccatamente modulare di quanto capita col SAS. Tale caratteristica si riflette in modo naturale in una maggiore estendibilità e manutenibilità dei programmi, al prezzo di una trascurabile perdita di efficienza. 9

10 In quanto segue illustriamo, seppur in modo estremamente semplificato, tre interventi di reingegnerizzazione intrapresi nel progetto di migrazione. I primi due sono volti ad aumentare l usabilità del sistema migrato rispetto a quello originario, il terzo ad estenderne le funzionalità mediante l introduzione di nuovi metodi statistici. 6.1 Interazione con l utente a maggiore livello di astrazione Nella Figura 3 è rappresentata in modo semplificato una sessione di lavoro con il sistema GENESEES/SAS. Come si vede, gli utenti interagiscono con il sistema in due specifici punti del flusso di elaborazione: a monte ed a valle del processo di calibrazione. Concentriamo, per il momento, l attenzione sull interazione a monte. Essa è necessaria perché l utente possa fornire al programma di calibrazione i dati da elaborare. D altra parte, la funzione di calibrazione di GENESEES/SAS non è in grado di acquisire in input direttamente i dati campionari di indagine. L utente deve, al contrario, farsi carico di trasformare i dati campionari di indagine in opportune strutture dati prescritte dal sistema. Tipicamente questa incombenza richiede all utente di sviluppare appositi programmi SAS senza ricevere dal sistema alcun supporto. Stime ed errori di campionamento DATI INPUT CALIBRAZIONE GENESEES/SAS STIME ED ERRORI errore errore variabile stima standard relativo % Y , ,24 0,65 Y ,3 1827,89 2,09 Stime ,89 ed errori di campionamento 3441,11 2,91 Y3 Y , ,85 1,24 errore errore Y5 variabile 88532,33 stima 2648,92 2,99 standard relativo % Y ,3 1827,89 2,09 Y , ,24 0, , ,11 Y7 2, ,3 1827,89 Y2 2, , ,85 Y8 1,24 Stime ,89 ed errori di 3441,11 campionamento 2,91 Y , ,92 Y9 2, , ,85 Y4 1, , ,85 errore 1,24 errore Y10 variabile 88532,33 Y5 stima 2648,92 2, , ,92 standard 2,99 relativo Y11 % Y ,3 1827,89 2, , ,24 0,65 Y , ,11 2,91 Y ,3 1827,89 Y2 2, ,85 1,24 Y , , ,11 Y3 2, , ,92 2,99 Y , ,85 Y4 1, , ,85 1,24 Y , ,92 Y5 2, , ,92 2,99 Y ,3 1827,89 Y6 2,09 Y , ,11 2,91 Y , ,85 1,24 Y , ,92 2,99 Y , ,85 1,24 Y , ,92 2,99 DATI OUTPUT DATI INPUT Figura 3: Rappresentazione schematica del flusso di lavoro del sistema GENESEES/SAS Il punto che qui preme sottolineare è che questa modalità di interazione con l utente presenta almeno due serie controindicazioni. La prima è che la corretta costruzione dei dataset di input richiede all utente finale di studiare, comprende e rispettare una notevole quantità di istruzioni complesse (si consideri che tali istruzioni occupano circa 50 pagine del manuale della funzione di riponderazione di GNESEES/SAS). La seconda è che la necessità di sviluppare programmi SAS esterni al sistema, senza ricevere da esso alcun supporto, aumenta significativamente il rischio di errori nel flusso di lavoro. Nel progetto del sistema migrato GENESEES/R l interazione con l utente avviene a maggiore livello di astrazione. L utente non ha più bisogno di manipolare i dati campionari di indagine: si limita a passarli al software così come sono, corredandoli di metadati che descrivono in modo simbolico (i) il disegno di campionamento ed (ii) il modello di calibrazione; è il sistema stesso, a questo punto, a trasformare, in modo trasparente all utente, i dati di indagine nelle strutture necessarie a risolvere il problema di calibrazione. Queste complesse operazioni, guidate dai 10

11 metadati di input, sono facilmente programmabili in R in virtù della potenza del linguaggio nell elaborazione di informazioni simboliche. 6.2 Integrazione di funzionalità Passiamo a considerare l interazione che l utente di GENESEES/SAS ha con il sistema a valle del processo di calibrazione. Il punto nodale è, in questo caso, che il modulo di calcolo stime ed errori non è in grado di acquisire in input direttamente i dataset prodotti in output dal modulo di calibrazione. E, ancora una volta, l utente a doversi far carico di svolgere tutte le operazioni di trasformazione dati necessarie. In termini sintetici: le due funzionalità fondamentali di GENESEES/SAS, pur contenuti nel medesimo sistema software, non sono realmente integrate. Il progetto del sistema migrato GENESEES/R integra effettivamente le due funzionalità, sgravando l utente dagli oneri menzionati e garantendo un significativo miglioramento dell usabilità del sistema e della sua robustezza rispetto a possibili errori. calmodel=~(x+y:z) partition=~d1:d2... Stime ed errori di campionamento CALIBRAZIONE GENESEES/R STIME ED ERRORI errore errore variabile stima standard relativo % Y , ,24 0,65 Y ,3 1827,89 2,09 Stime ,89 ed errori di campionamento 3441,11 2,91 Y3 Y , ,85 1,24 errore errore Y5 variabile 88532,33 stima 2648,92 2,99 standard relativo % Y ,3 1827,89 2,09 Y , ,24 0, , ,11 Y7 2, ,3 1827,89 Y2 2, , ,85 Y8 1,24 Stime ,89 ed errori di 3441,11 campionamento 2,91 Y , ,92 Y9 2, , ,85 Y4 1, , ,85 errore 1,24 errore Y10 variabile 88532,33 Y5 stima 2648,92 2, , ,92 standard 2,99 relativo Y11 % Y ,3 1827,89 2, , ,24 0,65 Y , ,11 2,91 Y ,3 1827,89 Y2 2, ,85 1,24 Y , , ,11 Y3 2, , ,92 2,99 Y , ,85 Y4 1, , ,85 1,24 Y , ,92 Y5 2, , ,92 2,99 Y ,3 1827,89 Y6 2,09 Y , ,11 2,91 Y , ,85 1,24 Y , ,92 2,99 Y , ,85 1,24 Y , ,92 2,99 Figura 4: Rappresentazione schematica del flusso di lavoro del sistema GENESEES/R Senza entrare in dettagli di natura tecnica, osserviamo come l integrazione delle funzionalità di calibrazione e calcolo stime ed errori non si sia risolta in una banale ri-direzione di input: il risultato ha, al contrario, richiesto delicate modifiche dell algoritmo di calibrazione. Nella Figura 4 è rappresentata in modo semplificato una sessione di lavoro con il sistema GENESEES/R. Il confronto con la Figura 3 rende evidenti i benefici effetti, in termini di semplicità, usabilità e robustezza del software, determinati dalle attività di reingegnerizzazione documentate nelle sezioni 6.1 e Aggiunta di nuove funzionalità Nel progetto del sistema GENESEES/SAS è stato ritenuto opportuno introdurre, accanto alla tradizionale funzione di stima degli errori implementata in GENESEES/SAS, un nuovo modulo software dedicato alla stima della varianza campionaria mediante il metodo Delete-A-Group Jackknife (DAGJK). A questo scopo uno degli autori della relazione (Diego Zardetto) ha sviluppato un apposito package R di nome EVER (Estimation of Variance by Efficient Replication). Il metodo DAGJK, proposto da Philip Kott, appartiene alla classe dei metodi di replicazione del campione e può essere visto come una variante computazionalmente efficiente del tradizionale 11

12 metodo jackknife stratificato. La necessità di costruire una replica dei pesi originali per ogni PSU inclusa nel campione rende, di fatto, irrealistico il ricorso al metodo jackknife tradizionale per indagini complesse e grandi (decine di migliaia di PSU in strati numerosi e di dimensione molto variabile). L utilizzabilità pratica del metodo DAGJK poggia, al contrario, sulla capacità del metodo di costruire per una vasta gamma di stimatori e di disegni di campionamento stime degli errori standard (quasi) non distorte anche con un piccolo numero (qualche decina) di repliche. In aggiunta alla sua peculiare efficienza computazionale, il metodo DAGJK gode dei principali vantaggi comuni ai più diffusi metodi di replicazione del campione. I più significativi, rispetto al tradizionale metodo analitico (basato sulla linearizzazione di Taylor e sulla teoria degli stimatori di regressione generalizzata) implementato in GENESEES/SAS, sono i seguenti: - Minore complessità matematica - Procedura di calcolo indipendente dalla forma funzionale dello stimatore e dal disegno di campionamento - Utilizzabile anche per stimatori non-analitici (es. stime di povertà) 7 Stato di avanzamento del progetto La sperimentazione finalizzata a testare la fattibilità della migrazione da SAS ad R del sistema GENESEES ha avuto inizio a maggio 2006 e si è conclusa a maggio In parallelo è stato intrapreso, da gennaio 2007 a ottobre 2007, il progetto di migrazione verso R della funzionalità di calibrazione. La migrazione della funzionalità di calcolo delle stime e degli errori (con il metodo analitico di stima della varianza) è tuttora in corso. Lo sviluppo del package EVER ha avuto inizio ad agosto 2007 ed il rilascio della prima release del software è previsto per aprile-maggio Ad oggi non è ancora stato aperto un progetto per la realizzazione della GUI di cui il sistema GENESEES/R dovrà essere corredato. Una versione beta del sistema, priva di interfaccia grafica, potrebbe essere resa disponibile per luglio Conclusioni Le attività sinteticamente descritte nella presente relazione costituiscono, in Istat, una delle prime esperienze di utilizzo di R per la realizzazione di funzionalità standard nei processi di produzione. Il giudizio che ne deriva, in merito alla possibilità concreta di sostituire in un ottica di medio periodo il SAS con R, è pienamente positivo. Sebbene, infatti, alcuni problemi di R non siano stati, ad oggi, completamente superati (ci riferiamo, in particolare, alla gestione della memoria), ci sembra che essi siano più che compensati dai punti di forza del sistema: (i) l accesso al codice sorgente dei package, importante per la personalizzazione e l ottimizzazione delle soluzioni applicative e (ii) le grandi potenzialità di R come linguaggio di programmazione (elevato livello di astrazione, elaborazione di informazioni simboliche, semplicità di programmazione e tempi di sviluppo contenuti). 12

13 Riferimenti bibliografici Scannapieco, M., Zardetto, D., Barcaroli, G. (2007) La Calibrazione dei Dati con R: una Sperimentazione sull'indagine Forze di Lavoro ed un Confronto con GENESEES/SAS, Contributi Istat n. 4, Lumley, T. (2006) survey: analysis of complex survey samples, R package version 3.6-5, Lumley, T. (2004) Analysis of complex survey samples. Journal of Statistical Software 9(1): Zardetto, D. (2008) EVER: Estimation of Variance by Efficient Replication, R package version (to be submitted to CRAN), Istat, Italy, R Development Core Team (2008) An Introduction to R, R Foundation for Statistical Computing, Vienna, Austria, R Development Core Team (2008) R Language Definition, R Foundation for Statistical Computing, Vienna, Austria, R Development Core Team (2008) Writing R Extensions, R Foundation for Statistical Computing, Vienna, Austria, Pagliuca, D. (a cura di) (2005) Genesees v.3.0., Funzione Riponderazione. Manuale utente ed aspetti metodologici, Tecniche e Strumenti, Isat, n. 2. Pagliuca, D. (a cura di) (2005) Genesees v.3.0., Funzione Stime ed Errori. Manuale utente ed aspetti metodologici, Tecniche e Strumenti, Isat, n. 3. Gazzelloni, S. (a cura di) (2006) La Rilevazione sulle Forze di Lavoro: Contenuti, Metodologie, Organizzazione, Metodi e Norme, Istat, n. 32. Särndal C.E., Swensson B. and Wretman J. (1992) Model Assisted Survey Sampling, Springer Verlag. Deville J.C., Särndal C.E. and Sautory O. (1993) Generalized Raking Procedures in Survey Sampling, Journal of the American Statistical Association, vol.88, Kott, Phillip S. (2001) The Delete-A-Group Jackknife, Journal of Official Statistics, Vol.17, No.4, pp