Impostare seed prima di ogni blocco di codice o una volta per progetto?

Si consiglia di impostare un seme casuale in modo che i risultati possano essere riprodotti. Tuttavia, poiché il seme viene avanzato man mano che vengono disegnati numeri pseudo-casuali, i risultati potrebbero cambiare se un pezzo di codice ricava un numero aggiuntivo.

A prima vista, il controllo della versione sembra essere una soluzione a questo, in quanto consentirebbe almeno di tornare indietro e riprodurre la versione esistente quando si scrivevano i risultati nelle note o nella carta. Tuttavia, poiché basta un solo sorteggio per rovinare le cose, se aggiorni R anche i risultati potrebbero cambiare.

Mi rendo conto che questo è probabilmente problematico solo in rari casi, ma sono curioso di sapere se ci sono delle migliori pratiche qui. Questo è qualcosa con cui ho lottato nel mio lavoro.

random-generation

— Ari B. Friedman
fonte

Dipende da come eseguirai il codice o se c'è qualche codice un po 'stocastico in quanto disegna numeri casuali in modo casuale. (Un esempio di ciò sono i test di permutazione nel nostro pacchetto vegano in cui continuiamo a permutare solo fino a quando non abbiamo accumulato dati sufficienti per sapere se un risultato è diverso dall'errore di tipo I dichiarato tenendo conto di un tasso di errore di tipo II.) Anche se anche quello non dovrebbe influenzare i sorteggi ...

Se lo script finale verrà mai eseguito come processo batch o nella sua interezza e non ci sono disegni stocastici dal generatore di numeri pseudo-casuali, è sicuro impostare un seme nella parte superiore dello script ed eseguirlo nella sua interezza .

Se si desidera scorrere il codice, forse rieseguire i blocchi, è necessario una set.seed()chiamata prima di ogni chiamata di funzione che verrà disegnata dal generatore di numeri pseudo-casuale.

Per i miei articoli scientifici vado abitualmente super difensivo e metto semi prima di ogni pezzo di codice; questo consente di aggiornare lo script in un secondo momento e potrebbe essere necessario inserirlo nello script esistente in qualsiasi momento, ad esempio per rispondere ai commenti dei revisori o dei coautori.

Si spera che i risultati non dipenderanno da una particolare serie di valori pseduo-casuali, quindi il problema è riuscire a riprodurre i valori esatti indicati in un rapporto o in un documento. Anche se potresti essere super difensivo e impostare un seme su ogni blocco di codice, potresti comunque dover ricreare l'installazione esatta --- versione R e versioni del pacchetto, quindi la registrazione di questi dettagli è essenziale. Per essere ancora più sicuro, dovrai conservare versioni e pacchetti R precedenti per progetti / documenti specifici. In effetti, molte persone lo fanno.

— Gavin Simpson
fonte

+1. Per quanto riguarda l'ultimo paragrafo: non è necessario salvare tutta quella spazzatura e non è necessario ricreare un'intera installazione. Se sei specifico su quale RNG usi, quindi invece di accettare i valori predefiniti, tutto ciò che deve essere salvato sono (1) il codice sorgente per quel RNG (che di solito è breve) e (2) lo stato del RNG in ogni momento cruciale . Per la maggior parte dei Rlavori questo stato può essere trovato in .Random.seed. La mia più grande preoccupazione Rè che alcune routine potrebbero aggirare questo - e forse potrebbero ignorare del set.seedtutto in alcuni casi.

— whuber

@whuber Stavo pensando più in generale lì - se la preoccupazione è quella di riprodurre l'esatta serie di risultati probabilmente avrai bisogno della versione di R e delle versioni di tutti i pacchetti utilizzati. Di Pentecoste; R 3.0.0 ha cambiato la precisione con cui riportava i valori - non importante ma che era sufficiente per eliminare tutti i numerosi test di controllo dei pacchetti che stavano assumendo troppa precisione. Inoltre, i pacchetti vengono aggiornati regolarmente e le cose cambiano.

— Gavin Simpson,