relazione - Istat.it

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
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 SAS1 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
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 1.500 (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
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 dk e i pesi calibrati
wk, 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 ∑ G ( d k , wk )

k ∈s

 ∑ wk x k = X
 k ∈s
(1)
Nell’equazione precedente è stato indicato con X il vettore dei totali noti e con xk 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:
L≤
wk
≤U
dk
k∈s
con
0 ≤ L ≤1≤U
(2)
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
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 dk, la funzione distanza G, le variabili ausiliarie xk, i totali noti X, ed i bounds
[L,U] e restituirà, come output principale, il vettore dei pesi calibrati wk.
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
1.3: Ambiente
HW e SW di
sperimentazione
Fase 2: Sviluppo prototipale per il test
2.1: Definizione dell’ambiente
di prototipazione
2.2: Test di efficacia
Fase 3: Realizzazione del test di fattibilità
2.3: Test di efficienza
3.1: Test di efficienza
e ottimizzazione
3.2: Test di efficacia
e correzione
Schema 1: Scomposizione del test di fattibilità in macro fasi temporali e sottofasi logiche
5
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 70.000
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
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 10-10). 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.
8.405e-16
7.460e-12
2.326e-11
5.590e-10
1.189e-10
1.086e-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
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 NewtonRaphson, 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
R calibrate corretta
PC
R calibrate corretta
Server
155 minuti
R calibrate_iter
PC
84 secondi
R calibrate_iter
Server
86 secondi
–
> 4 giorni
–
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
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
LEGACY
(–)
ESTENDIBILE ( + )
EFFICIENZA
(=)
EFFICIENZA
QUALITA’ DEL SOFTWARE
(+)
(=)
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
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
errore
errore
standard relativo %
1531592,64 9948,24
0,65
87612,3 1827,89
2,09
Stime118096,89
ed errori di campionamento
3441,11
2,91
358668,86 4458,85
1,24
errore
errore
variabile
stima 2648,92
88532,33
2,99
standard relativo %
87612,3 1827,89
2,09
Y1
1531592,64 9948,24
0,65
118096,89
3441,11
2,91
Y2
87612,3 1827,89
2,09
358668,86
4458,85
1,24
Stime118096,89
ed errori
di 3441,11
campionamento
Y3
2,91
88532,33
2648,924458,85 2,99 1,24
Y4
358668,86
errore
errore
358668,86 4458,85
1,24
Y5
88532,33
2,99
variabile
stima 2648,92
standard
relativo %
88532,3387612,3
2648,921827,89
2,99 2,09
Y6
Y1
1531592,64 9948,24
0,65
Y7
118096,89 3441,11
2,91
Y2
87612,3 1827,89
2,09
Y8
358668,86 4458,85
1,24
Y3
118096,89 3441,11
2,91
Y9
88532,33 2648,92
2,99
Y4
358668,86 4458,85
1,24
Y10
358668,86 4458,85
1,24
Y5
88532,33 2648,92
2,99
Y11
88532,33 2648,92
2,99
Y6
87612,3 1827,89
2,09
Y7
118096,89 3441,11
2,91
Y8
358668,86 4458,85
1,24
Y9
88532,33 2648,92
2,99
Y10
358668,86 4458,85
1,24
Y11
88532,33 2648,92
2,99
variabile stima
Y1
Y2
Y3
Y4
Y5
Y6
Y7
Y8
Y9
Y10
Y11
GENESEES/SAS
DATI
INPUT
CALIBRAZIONE
DATI
OUTPUT
STIME
ED
ERRORI
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
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
errore
errore
standard relativo %
1531592,64 9948,24
0,65
87612,3 1827,89
2,09
Stime118096,89
ed errori di campionamento
3441,11
2,91
358668,86 4458,85
1,24
errore
errore
variabile
stima 2648,92
88532,33
2,99
standard relativo %
87612,3 1827,89
2,09
Y1
1531592,64 9948,24
0,65
118096,89
3441,11
2,91
Y2
87612,3 1827,89
2,09
358668,86
4458,85
1,24
Stime118096,89
ed errori
di 3441,11
campionamento
Y3
2,91
88532,33
2648,924458,85 2,99 1,24
Y4
358668,86
errore
errore
358668,86 4458,85
1,24
Y5
88532,33
2,99
variabile
stima 2648,92
standard
relativo %
88532,3387612,3
2648,921827,89
2,99 2,09
Y6
Y1
1531592,64 9948,24
0,65
Y7
118096,89 3441,11
2,91
Y2
87612,3 1827,89
2,09
Y8
358668,86 4458,85
1,24
Y3
118096,89 3441,11
2,91
Y9
88532,33 2648,92
2,99
Y4
358668,86 4458,85
1,24
Y10
358668,86 4458,85
1,24
Y5
88532,33 2648,92
2,99
Y11
88532,33 2648,92
2,99
Y6
87612,3 1827,89
2,09
Y7
118096,89 3441,11
2,91
Y8
358668,86 4458,85
1,24
Y9
88532,33 2648,92
2,99
Y10
358668,86 4458,85
1,24
Y11
88532,33 2648,92
2,99
variabile stima
GENESEES/R
CALIBRAZIONE
STIME
ED
ERRORI
Y1
Y2
Y3
Y4
Y5
Y6
Y7
Y8
Y9
Y10
Y11
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 6.2.
6.3 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
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 2007. 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 2008. 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 2008.
8
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
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,
http://www.istat.it/dati/pubbsci/contributi/Contributi/contr_2007/2007_4.pdf.
Lumley, T. (2006) “survey: analysis of complex survey samples”, R package version 3.6-5,
http://cran.at.r-project.org/web/packages/survey/index.html.
Lumley, T. (2004) “Analysis of complex survey samples”. Journal of Statistical Software 9(1):
1-19.
Zardetto, D. (2008) “EVER: Estimation of Variance by Efficient Replication”, R package version
0.9-6 (to be submitted to CRAN), Istat, Italy,
http://www.istat.it/strumenti/metodi/software/produzione_stime/ever/index.html.
R Development Core Team (2008) “An Introduction to R”, R Foundation for Statistical
Computing, Vienna, Austria,
http://cran.r-project.org/doc/manuals/R-intro.pdf.
R Development Core Team (2008) “R Language Definition”, R Foundation for Statistical
Computing, Vienna, Austria,
http://cran.r-project.org/doc/manuals/R-lang.pdf.
R Development Core Team (2008) “Writing R Extensions”, R Foundation for Statistical
Computing, Vienna, Austria,
http://cran.r-project.org/doc/manuals/R-exts.pdf.
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, 1993.
Kott, Phillip S. (2001) “The Delete-A-Group Jackknife”, Journal of Official Statistics, Vol.17,
No.4, pp. 521-526.
13