Domanda:
In che modo le riviste accademiche proteggono dai risultati empirici forniti dai bug?
Akavall
2014-03-14 03:15:10 UTC
view on stackexchange narkive permalink

Come dice il titolo.

Il mio background è in Economia / Finanza (principalmente), molti argomenti in questi campi (e sono sicuro che altri campi) richiedono una programmazione abbastanza complicata, abbastanza da poter essere facilmente rovinare qualcosa. In che modo le riviste accademiche si difendono dai risultati generati dai bug?

Per quanto ne so nessuno vede mai il mio codice, potrebbero essere centinaia o addirittura migliaia di righe di codice spazzatura senza una singola funzione (per non parlare dei test unitari) piene di bug, e ho mantenuto "aggiustare" le cose fino a quando i miei risultati "avevano un senso", e poi li riportarono felicemente. Come può un diario dire che i miei risultati sono spazzatura?

Short answer: **They don't.**
Penso che sarà interessante quando più persone condivideranno codice e dati. Trovare piccoli bug può diventare più una routine, proprio come lo è con i progetti di codifica non accademici.
Questo è un ottimo punto per rendere il codice pubblicamente disponibile. Ho visto pubblicazioni su dati analizzati con software che non solo non è disponibile, ma l'intero algoritmo è segreto anche per i ricercatori che hanno fatto l'analisi.
@Davidmh che stranamente mi ricorda [questo fumetto SMBC] (http://www.smbc-comics.com/?id=3073#comic).
Nota che un'implicazione è che non dovresti mai presumere che il codice pubblicato sia automaticamente corretto.
@JeromyAnglim Non è del tutto pratico condividere il codice attraverso. Il nostro codice interno è di quasi 1 milione di righe in 4 diversi linguaggi di programmazione. Condividerlo, in particolare come parte di un processo di revisione di una rivista, sarebbe impossibile. Per non parlare delle licenze imposte dalla nostra università lo vieta ...
@tpg2114 non è sicuramente "impossibile condividere". Quanto sarebbe difficile includere nell'articolo un collegamento a un progetto GitHub insieme a un timestamp? Ci vorrebbero 40 caratteri.
IMO, se le riviste dessero la preferenza a documenti che arrivano da molto tempo con un collegamento a github, che contiene codice leggibile pulito, anche meglio con i test unitari, aiuterebbe un po 'la questione dei bug. Altri potrebbero trovare bug, inoltre gli autori originali sarebbero costretti a scrivere codice pulito, che li aiuterebbe a non commettere errori. Inoltre, spesso non è chiaro cosa stiano facendo esattamente determinati passaggi in un documento, avere accesso alla fonte potrebbe aiutare a comprendere ogni dettaglio del documento.
@ANeves La nostra università ha messo una licenza commerciale sul nostro codice, quindi la distribuzione del sorgente non è possibile senza che qualcuno acquisti una licenza e il prezzo è di centinaia di migliaia di dollari. Inoltre, anche se potessimo inviare il codice solo ai revisori di un articolo di una rivista, non è possibile che i revisori possano digerire anche una piccola frazione del codice più l'articolo che stanno esaminando nel tempo concesso dalla rivista. Quindi "impossibile" è probabilmente la parola sbagliata - così poco pratico che non accadrebbe è una scelta migliore.
Inoltre, la generazione dei nostri risultati potrebbe richiedere diversi mesi per decine di migliaia di processori. Mi piace l'idea di distribuire codici e far verificare i risultati come parte del processo scientifico, ma non è pratico in tutti i campi
Tre risposte:
Marc Claesen
2014-03-14 03:26:23 UTC
view on stackexchange narkive permalink

Le riviste non forniscono mai alcuna garanzia in merito alla validità del contenuto in esse pubblicato, sebbene ciò possa sembrare implicito. Idealmente, gli errori vengono rilevati durante il processo di revisione. Nota che questo problema non è specifico dei bug di programmazione, errori sottili possono verificarsi in tutti i tipi di impostazioni, inclusi gli esperimenti fisici. È importante essere sempre critici riguardo a qualsiasi risultato in qualsiasi articolo, anche articoli altamente citati nelle riviste più importanti (anche se è meno probabile che siano sbagliati, potrebbero comunque esserlo).

Le lettere all'editore non sono rare nel mio dominio quando vengono pubblicati risultati discutibili. Nella peggiore delle ipotesi, i documenti pubblicati possono essere ritirati dopo che la validità dei loro risultati è stata formalmente respinta. Tuttavia, le ritrattazioni per questo motivo sembrano essere piuttosto rare.

Questo è uno dei motivi per cui i risultati riproducibili sono così importanti. Se diversi ricercatori indipendenti sembrano giungere a conclusioni simili, è probabile che abbiano ragione.

Grazie per la risposta. Dici che se diversi ricercatori indipendenti raggiungono conclusioni simili, è probabile che i risultati siano corretti. Tuttavia, se pubblichi alcuni risultati e poi trovo la stessa cosa, le riviste pubblicheranno il mio articolo? Ha valore perché supporta il tuo risultato, ma d'altra parte non ho fatto nulla di nuovo, quindi la mia sensazione istintiva è che il mio articolo non verrà pubblicato.
@Akavall Presumibilmente una volta verificati i risultati originali, è possibile aggiungere / estendere / applicare il codice a un altro problema. Ciò rende i tuoi nuovi risultati leggermente più affidabili poiché hai dimostrato di poter eguagliare ciò che hanno fatto gli altri. Quindi il nuovo lavoro è il motivo per cui un articolo viene pubblicato e la verifica degli altri risultati fa parte della tua giustificazione per il nuovo lavoro.
"Se diversi ricercatori indipendenti sembrano arrivare a conclusioni simili, probabilmente hanno ragione" ... A MENO CHE non abbiano utilizzato tutti lo stesso codice :-)
@Flyto Hai assolutamente ragione. Questo è ciò che intendevo per * indipendente *.
eh, punto giusto. Ma almeno in alcuni campi, non sarei sorpreso di vedere i ricercatori che si considerano indipendenti l'uno dall'altro mentre utilizzano gli stessi strumenti scritti da altri.
cbeleites unhappy with SX
2014-03-14 17:09:46 UTC
view on stackexchange narkive permalink

Oltre alla risposta di Marc Claesen:

  • Esistono alcune riviste che richiedono l'invio del codice e in cui la recensione includeva esplicitamente quel codice, ad es. il Journal of Statistical Software

  • In uno dei miei ultimi articoli, un revisore ha posto esattamente questa domanda. Ecco la nostra risposta nel testo:

    I controlli includono test unitari per garantire la correttezza di calcolo, che consistono in ca. il doppio delle righe di codice rispetto alle definizioni di funzione effettive.

    Includo questo perché anche se la rivista non ha una politica esplicita riguardo al codice, sia i revisori che gli autori possono già iniziare con pratiche di codifica e test: sono incoraggiato da questa esperienza a includere tali dichiarazioni anche in futuro come autore e chiederò come revisore.

Flyto
2014-03-20 16:10:00 UTC
view on stackexchange narkive permalink

Questo è un problema che inizia a essere riconosciuto ed è stato descritto da alcuni come una " crisi di riproducibilità". Ci sono stati esempi di articoli in importanti riviste ritirati dopo che sono stati trovati bug nel codice dei ricercatori. Questo articolo descrive alcuni dei problemi in modo più dettagliato.

A mio avviso ci sono tre percorsi principali per affrontarli,

  1. Insegna ai programmatori scientifici buona pratica di sviluppo software
  2. Rendi il codice sorgente e i set di dati disponibili e citabili, con DOI e con la certezza che saranno disponibili e invariati a lungo termine.
  3. Ottieni riviste su richiedono che la fonte e i dati siano disponibili (anche se probabilmente devono essere fatti dei compromessi laddove i dati sono riservati dal punto di vista commerciale) e che i revisori conducano la revisione del codice. Ciò potrebbe non essere semplice poiché (come notato nell'articolo Post & Votta collegato sopra) non sarà sempre possibile trovare un revisore qualificato per rivedere il codice e sufficientemente esperto della scienza coinvolta. (e questo prima ancora di considerare quanto tempo potrebbe richiedere la revisione del codice!)

Il progetto Software Carpentry ha lo scopo di affrontare i punti 1 e 2 sopra, e potrebbe essere di interesse.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...