Non so se sia normale, ma dovrebbe essere normale che tutti i revisori facciano sforzi ragionevoli per verificare che le affermazioni degli autori siano corrette, quindi nella misura in cui non è normale, Posso solo elogiare il revisore per essere disposto a fare uno sforzo che altri revisori non fanno. Ciò che intendi come "sfiducia" è il revisore che fa il proprio lavoro, niente di più o meno (ed è probabilmente in qualche modo esatto dire che il compito di un revisore è quello di diffidare delle affermazioni dell'autore, quindi non vedo l'idea di essere diffidato da un recensore come qualcosa di cui vergognarsi o da cui offendere).

A proposito, dovrebbe anche essere normale per gli autori rendere disponibile qualsiasi software (incluso il codice sorgente quando possibile) necessario per replicare e verificare i loro risultati. Quindi, se non sei soddisfatto del fatto che il revisore ti risponda con richieste fastidiose che ritardano la decisione sul tuo articolo, la prossima volta puoi prevenire tali problemi rilasciando il tuo codice sorgente (o almeno presentandolo alla rivista) insieme al tuo manoscritto. Sono sicuro che il revisore sarebbe molto più felice e alla fine tutti ne trarrebbero vantaggio, incluso te.

Vengo da un campo diverso, in cui il codice che usiamo non è un output importante. Ma se un arbitro chiedesse il codice, lo forniremmo e saremmo felici. La maggior parte del nostro lavoro è fatto in python, quindi un eseguibile non sarebbe usuale, il sorgente lo sarebbe (vero anche per matlab).

In effetti l'unica cosa che trovo leggermente strana qui è l'uso di eseguibile piuttosto che source.

Non essere offeso dalla richiesta per un paio di motivi: non è compito dei revisori fidarsi di te; è loro compito controllare la tua carta. Se un revisore è abbastanza interessato al tuo lavoro da desiderare di eseguire il tuo codice, non ha ignorato il tuo documento senza averlo fatto.

Per riassumere la situazione con i tuoi dati: -

1) Hai inventato un algoritmo su carta / Matlab / qualunque cosa.

2) Hai implementato quell'algoritmo in qualche programmazione linguaggio.

3) Hai costruito una serie di dati di test per esercitare il tuo algoritmo e hai ottenuto alcuni risultati per ciò che dovrebbe fare in teoria.

4) Hai messo quel test dati attraverso il codice e ne sono usciti alcuni risultati per ciò che fa nella pratica.

In questo processo ci sono vari punti in cui le cose possono andare storte con la tua metodologia. Il tuo codice potrebbe non riflettere correttamente il tuo algoritmo. I dati del test potrebbero essere stati elaborati a ritroso dal codice anziché in avanti dall'algoritmo. I dati di test per il tuo algoritmo e i dati di test per il tuo codice potrebbero non essere gli stessi.

A meno che il revisore non abbia l'algoritmo e il codice sorgente e tutti i dati di test per entrambi e tutti i dati di output per entrambi, non possono verificare che il tuo lavoro sia corretto e le tue conclusioni siano valide. Questo non è soggetto a controversia - è logicamente impossibile, se vogliono rivedere adeguatamente il tuo lavoro. Qualsiasi altra cosa è fare supposizioni che potrebbero non essere valide.

Sono stato personalmente colpito da questa situazione, quando la mia azienda ha acquistato un IP della teoria del controllo da un ricercatore. Aveva scritto articoli su come avrebbe dovuto funzionare e la teoria alla base, e poi aveva costruito dell'elettronica per implementare la sua teoria. I suoi articoli coprivano la teoria e includevano anche schemi per l'elettronica. Quando ho letto questo per capire come implementare la sua teoria nel software, ho scoperto che lo schema aveva un filtro extra. L'azione di questo filtro si è rivelata fondamentale per la stabilità o addirittura l'efficacia del sistema, ma non è stata documentata in nessun punto del suo lavoro. È stato solo quando abbiamo ricevuto una telefonata con lui che abbiamo scoperto qual era lo scopo del filtro e come avremmo dovuto regolarlo.

Questo era in un documento che in teoria era stato sottoposto a peer review quando è stato pubblicato. Chiaramente non era stato sottoposto a peer review abbastanza a fondo! I suoi risultati hanno mostrato che, dati gli stessi dati, l'output dell'implementazione era abbastanza vicino all'output teorico atteso e l'effetto del filtro si trovava in un punto diverso nella risposta. Tuttavia, l'implementazione in modo piatto non avrebbe mai funzionato senza questo filtro presente e non sarebbe stato affatto difficile includerlo nel modello teorico. Avrebbe anche potuto dire "questo filtro è necessario per questi motivi, ma può essere ignorato in quest'area della risposta che stiamo cercando per questi motivi" e sarebbe stato coperto. Ciò che non è accettabile è quello che ha fatto, ovvero non menzionarlo affatto, perché il risultato finale è che qualcuno che cerca di implementare il suo lavoro non sarebbe in grado di farlo.

Come ho detto, lui ancora ha pubblicato il suo articolo e nessuno si è lamentato in quel momento. Tuttavia, avrebbe dovuto essere individuato dai suoi revisori originali. Nel tuo caso, il tuo revisore dovrebbe cercare discrepanze come questa: è l'intero punto della revisione tra pari. Quindi, se le persone ti chiedono cose che non hai reso disponibili, (a) è un buon segno che stanno controllando accuratamente e (b) avresti dovuto renderlo disponibile in primo luogo come best practice.

Le presentazioni di artefatti sono una cosa in CS. Quello che ho visto è che prepareresti una macchina virtuale, dove il tuo software è già configurato e pronto per fare esperimenti. Quindi, il revisore potrebbe riferirsi al fatto che la rivista ha qualche procedura ufficiale per l'invio di artefatti. In alternativa, alcuni autori rendono disponibile il codice sorgente dei loro strumenti e benchmark tramite servizi come github e il revisore potrebbe suggerire che dovresti farlo anche tu. Per quanto riguarda la sfiducia, gli informatici sono naturalmente diffidenti nei confronti dei benchmark e dei confronti degli strumenti, poiché i dati finali possono dipendere molto da come è impostato il tuo esperimento (ad esempio, se confronti la tua implementazione di un algoritmo esistente, l'hai implementato correttamente ). Potrebbe anche essere che i numeri che fornisci nel documento sembrino un po 'strani, ma poi il revisore avrebbe indicato ciò che esattamente non gli sembra giusto.

Inviare un eseguibile non è la stessa cosa che inviare il codice sorgente. Un eseguibile in realtà non dà al destinatario alcun accesso al tuo codice originale (come dovrebbe già sapere uno studente di informatica, ovviamente). Non vedo alcun problema con questa richiesta.

Data la mia esperienza personale con le comunità open source e il presupposto che l'articolo includa la totalità dell'algoritmo in questione, l'invio del codice sorgente o la relativa compilazione di detto software non produrrebbe molti effetti negativi.

Ciò consentirebbe al revisore di verificare i risultati e le affermazioni fatte dall'autore dell'articolo. Il problema chiave che il revisore potrebbe cercare è che tu abbia implementato correttamente l'algoritmo nel codice sorgente e non ti affidi per errore a una funzionalità del linguaggio di programmazione, del sistema operativo o dell'hardware per fare affermazioni sul suo tempo di esecuzione o su altre funzionalità.

A prima vista, vorrei riferire che nei casi legati all'I / O è facile scambiare algoritmi efficienti per, ad esempio, la capacità di Javascript di rendere asincrona quasi ogni chiamata di funzione. Ovviamente questo si vede principalmente nelle operazioni di I / O piuttosto che nei loop computazionali proliferativi. Quindi l'efficienza misurata non è quella dell'algoritmo come prova formale ma; invece si basa su una caratteristica specifica della lingua.

Il punto saliente è che ci sono molti casi in cui l'algoritmo formale e l'implementazione possono divergere dal rappresentarsi fedelmente e così facendo la conclusione, se basata su metriche empiriche come il tempo di esecuzione, può essere eseguita in molte questioni in cui un'implementazione impropria può attestare una conclusione errata.

Il codice sorgente può contenere bug e per rivedere in modo veramente efficace un algoritmo, una descrizione in prosa del metodo da sola potrebbe non essere sufficiente. Condividere qualcosa oltre il testo è vantaggioso; un buon documento con il codice sorgente effettivo (+ input di esempio) è il gold standard per la riproducibilità.

Una ruga divertente: a seconda di dove si trova il tuo revisore, potresti non essere autorizzato per dare loro un binario. Ad esempio, alcuni codici utilizzano librerie proprietarie concesse in licenza liberamente nel mondo accademico, ma qualcuno nell'industria potrebbe richiedere una licenza separata anche per utilizzare un file binario esistente, tanto meno per compilarlo. (questo mi è successo una volta, anche se non come parte della revisione tra pari)

È una richiesta idiota da parte sua.

1. Potrebbe prendere un virus.
2. Non esiste un modo realistico per verificare che l'eseguibile implementa quanto descritto nel tuo articolo, ergo in nessun modo la richiesta ha alcun valore scientifico.

Dovrebbe chiedere il codice sorgente, e questo è tutto ciò che dovresti accettare dagli.