Нормально ли, что рецензент запрашивает исполняемый файл для проверки моих результатов?

Я не знаю, нормально ли это, но для всех рецензентов должно быть нормальным прилагать разумные усилия для проверки правильности утверждений авторов, поэтому в той мере, в какой это ненормально, я могу только похвалить рецензента за готовность сделать усилие, которое другие рецензенты не делают. То, что вы понимаете под «недоверием», — это то, что рецензент выполняет свою работу, не больше и не меньше (и, вероятно, будет несколько правильно сказать, что работа рецензента состоит в том, чтобы не доверять утверждениям автора, поэтому я не вижу идеи недоверия со стороны автора). рецензент как нечто, на что можно стыдиться или обижаться).

Между прочим, для авторов также должно быть нормальным предоставлять любое программное обеспечение (включая исходный код, когда это возможно), необходимое для воспроизведения и проверки их результатов. Поэтому, если вы недовольны тем, что рецензент возвращается к вам с назойливыми просьбами, которые задерживают решение по вашей статье, в следующий раз вы можете предупредить такие проблемы, опубликовав исходный код (или, по крайней мере, отправив его в журнал) вместе с рукописью. Я уверен, что рецензент был бы намного счастливее, и в конечном итоге выиграли бы все, включая вас.

Я пришел из другой области, в которой код, который мы используем, не является основным продуктом. Но если бы рефери попросил код, мы бы его предоставили и с радостью. Большая часть нашей работы выполняется на python, поэтому исполняемый файл не будет обычным, исходный код будет (также верно для Matlab).

На самом деле единственное, что я нахожу здесь немного странным, это использование исполняемого файла , а не исходного кода .

Не обижайтесь на просьбу по нескольким причинам: это не работа рецензентов доверять вам; это их работа, чтобы проверить вашу бумагу. Если рецензент проявляет достаточно интереса к вашей работе, чтобы захотеть запустить ваш код, он не отклонит вашу статью сразу.

Подводя итог ситуации с вашими данными: -

1) Вы придумали алгоритм на бумаге/Matlab/что угодно.

2) Вы реализовали этот алгоритм на каком-то языке программирования.

3) Вы построили набор тестовых данных для проверки своего алгоритма и получили некоторые результаты для того, что он должен делать в теории.

4) Вы поместили эти тестовые данные в код и получили некоторые результаты для того, что он делает на практике.

В этом процессе есть несколько мест, где что-то может пойти не так с вашей методологией. Ваш код может неправильно отражать ваш алгоритм. Ваши тестовые данные могли быть обработаны в обратном направлении от кода, а не вперед от алгоритма. Ваши тестовые данные для вашего алгоритма и ваши тестовые данные для вашего кода могут не совпадать.

Если у рецензента нет алгоритма , исходного кода и всех тестовых данных для обоих, а также всех выходных данных для обоих, он не может проверить, что ваша работа надежна, а ваши выводы верны. Это не подлежит оспариванию - это логически невозможно, если они хотят нормально оценить вашу работу. Все остальное — это предположения, которые могут оказаться неверными.

Меня лично затронула эта ситуация, когда моя компания купила интеллектуальную собственность по теории управления у исследователя. Он написал статьи о том, как это должно было работать, и о лежащей в его основе теории, а затем построил электронику для реализации своей теории. Его статьи касались теории, а также включали схемы электроники. Когда я прочитал это, чтобы выяснить, как реализовать его теорию в программном обеспечении, я обнаружил, что на схеме есть дополнительный фильтр. Действие этого фильтра оказалось критически важным для стабильности или даже эффективности системы, но нигде в его работе это не было задокументировано. Только когда мы поговорили с ним по телефону, мы узнали, какова цель фильтра и как мы должны были его настроить.

Это было в статье, которая теоретически прошла рецензирование при публикации. Ясно, что он не был достаточно тщательно рецензирован! Его результаты показали, что при тех же данных выход реализации был довольно близок к теоретическому ожидаемому результату, а эффект фильтра находился в другом месте отклика. Тем не менее, реализация никогда бы не работала без этого фильтра, и было бы совсем несложно включить его в теоретическую модель. Он мог бы даже сказать, что «этот фильтр требуется по этим причинам, но его можно игнорировать в той области ответа, которую мы рассматриваем по этим причинам», и его бы защитили. Что неприемлемо, так это то, что он сделал, то есть вообще не упомянул об этом,

Как я уже сказал, его статья все еще публиковалась, и в то время никто не жаловался. Хотя это должны были заметить его первоначальные рецензенты. В вашем случае ваш рецензент должен искать подобные несоответствия — в этом весь смысл рецензирования. Поэтому, если люди просят вас о вещах, которые вы не сделали доступными, (а) это хороший признак того, что они тщательно проверяют, и (б) вы должны были сделать это доступным в первую очередь в качестве наилучшей практики.

Представление артефактов — это вещь в CS. Что я видел, так это то, что вы готовите виртуальную машину, где ваше программное обеспечение уже настроено и готово для проведения экспериментов. Таким образом, рецензент может иметь в виду, что в журнале есть какая-то официальная процедура отправки артефактов. В качестве альтернативы, некоторые авторы просто предоставляют исходный код своих инструментов и тестов через такие сервисы, как github, и рецензент может предложить вам сделать то же самое. Что касается недоверия, компьютерщики, естественно, настороженно относятся к эталонным тестам и сравнениям инструментов, поскольку окончательные цифры могут во многом зависеть от того, как настроен ваш эксперимент (например, если вы сравниваете с собственной реализацией существующего алгоритма, правильно ли вы его реализовали? ). Также может быть, что цифры, которые вы приводите в статье, кажутся немного странными,

Отправка исполняемого файла — это не то же самое, что отправка исходного кода. Исполняемый файл на самом деле не дает получателю никакого доступа к вашему исходному коду (как, конечно, уже должен знать студент, изучающий информатику). Я не вижу проблемы в этом запросе.

Учитывая мой личный опыт работы с сообществами открытого исходного кода и предположение, что документ включает в себя весь рассматриваемый алгоритм, отправка исходного кода или соответствующей компиляции указанного программного обеспечения не приведет к большим негативным последствиям.

Это позволит рецензенту проверить результаты и утверждения, сделанные автором статьи. Ключевой вопрос, на который может обратить внимание рецензент, заключается в том, что вы правильно реализовали алгоритм в исходном коде и не полагаетесь по ошибке на функцию языка программирования, ОС или аппаратного обеспечения, чтобы делать заявления о времени его работы или других функциях.

Внезапно я бы сказал, что в случаях, связанных с вводом-выводом, легко спутать эффективные алгоритмы, например, со способностью Javascript сделать почти каждый вызов функции асинхронным. Конечно, это в основном наблюдается в связанных операциях ввода-вывода, а не в множащихся вычислительных циклах. Тогда измеряемая эффективность - это не эффективность алгоритма как формального доказательства, а; вместо этого он зависит от конкретной функции языка.

Существенным моментом является то, что существует много случаев, когда формальный алгоритм и реализация могут отличаться от точного представления друг друга, и при этом вывод, основанный на эмпирических показателях, таких как время выполнения, может столкнуться со многими проблемами, когда неправильная реализация может свидетельствовать о неверном заключении.

Исходный код может содержать ошибки, и для действительно эффективного обзора алгоритма одного описания метода может быть недостаточно. Полезно делиться чем-то помимо текста; хорошая статья с фактическим исходным кодом (+ примеры входных данных) является золотым стандартом воспроизводимости.

Одна забавная особенность: в зависимости от того, где находится ваш рецензент, вам может быть запрещено давать ему двоичный файл. Например, некоторый код использует проприетарные библиотеки, которые свободно лицензируются в академических кругах, но кому-то в промышленности может потребоваться отдельная лицензия даже для использования существующего бинарного файла, не говоря уже о его компиляции. (это случилось со мной однажды, но не в рамках экспертной оценки)

Идиотская просьба с его стороны.

1. Он мог заразиться вирусом.
2. У него нет реального способа проверить, что исполняемый файл реализует то, что описано в вашей статье, следовательно , запрос не имеет какой-либо научной ценности.

Он должен попросить исходный код, и это все, что вы должны ему дать.