За свою академическую карьеру я прочитал немало научных работ по различным темам информатики. Многие из них включают реализацию и некоторую оценку этой реализации, но я обнаружил, что очень немногие из них действительно публикуют код, который они использовали.
Для меня преимущества включения фактической реализации будут значительными, а именно:
- Расширение доверия или воспроизводимости (просто проверьте это сами!)
- Разъяснение неясностей (особенно для работ, написанных не носителями языка)
- Повторное использование кода для приложений
Так почему же так мало статей действительно содержат какой-либо код?
Я полагаю, что организация, стоящая за этим документом, могла бы использовать реализацию в своих собственных приложениях, и поэтому не хотела бы выпускать ее, но если это так, зачем вообще писать статью?
soft-question
research-practice
paper-review
Кевин Долан
источник
источник
Ответы:
Вот хорошо аргументированная статья Дэвида Донохо и Джонатана Бакхейта, которую я читал в аспирантуре и которая касается именно этой темы с точки зрения исследователей вейвлетов:
«WaveLab и воспроизводимые исследования»
Их идея была еще более амбициозной - предоставить код для воспроизведения всех цифр в их документах в удобной упаковке Matlab.
Мне очень нравится их идея, но я думаю, что проблемы очевидны.
(1) Это дополнительная работа (очистка кода, создание хотя бы элементарного пользовательского интерфейса, написание некоторой документации, оказание некоторой поддержки, когда люди неизбежно сталкиваются с проблемами)
(2) Это на самом деле не требуется / не ожидается большинством конференций / рецензентов
Но я не могу не чувствовать, что исследовательское сообщество CS выиграло бы, если бы ожидалось сделать код и данные, используемые в любой публикации, общедоступными в удобном для использования формате. Я признаю, что я не сделал этого сам, даже когда объем работы был бы управляемым. Я думаю, что просто трудно заставить себя приложить дополнительные усилия, когда нет внешнего толчка.
источник
Если вы работаете в промышленной лаборатории, гораздо проще получить документ, утвержденный к выпуску, чем получить код, утвержденный к выпуску (даже если документ содержит всю информацию, необходимую для перезаписи кода). Виновата бюрократия.
источник
Переносится и расширяется из комментария:
Я думаю, что это должно варьироваться в зависимости от подполя. Почти все материалы по Theory B, с которыми я знаком (и особенно Haskell, Agda и иногда связанные с Coq), включают в себя опубликованный код, иногда даже в виде приложения или, что еще лучше, в тексте статьи. Достаточно много статей, например, от ICFP, изначально написаны как грамотные программы, и их источник полностью опубликован авторами. Изрядное количество из них, в свою очередь, привело к извлечению библиотек для распространения.
Из оставшихся бумаг у достаточного количества никогда не было кода для начала. Из них, вероятно, есть две основные причины. Во-первых, это статьи, основным содержанием которых являются деревья доказательств, правила ввода с соответствующими доказательствами обоснованности и тому подобное. Из них достижения в области механизированной метатеории побудили по крайней мере некоторых авторов предоставить код в качестве средства выбора теорем (см. Слайды Вейриха на POPLmark: http://www.seas.upenn.edu/~sweirich/talks/cambridge-09. PDF). Во-вторых, те, которые произошли от материала Bird-Merteens (banannas & co.). Они, как правило, переводятся на функциональный язык без особого труда. Тем не менее, я подозреваю, что, как правило, происходит потеря общности, и что решение конкретных вопросов синтаксиса и типизации излишне усложняет ситуацию и усложняет следование эквациональным рассуждениям.
Я хотел немного обосновать свои наблюдения, так же как и приблизительный подсчет первых двух дней работы ICFP 2010. Из стандартных документов (т.е. не отчетов об опыте или приглашенных бесед) 12 из 21 предоставили какой-то код. Три предоставили Coq (четвертый требовал частичное доказательство, но не опубликовал его). Три подготовил Хаскелл. Три предоставлены Агды. Один предоставил Схему, один предоставил Caml, а другой предоставил Twelf. (Обратите внимание, что некоторые предоставили код для более чем одного помощника по проверке или для формализации и реализации). Из оставшихся работ некоторые работали на достаточно высоком уровне абстракции, поэтому его реализация в помощнике по проверке стала бы новой работой сама по себе, и еще немало работ, которые, как я подозреваю, могли бы быть реализованы в помощнике по проверке с использованием стандартные методы, но, безусловно, потребовалось бы немало усилий для этого.
источник
Вы считаете, что код должен быть опубликован, но спрашиваете, почему в документах нет кода. Это две разные вещи.
В большинстве случаев просто не хватает места для публикации значительного количества кода. В моей области исследований (обработка изображений) псевдокод или информация об архитектуре часто гораздо более ценны, и я никогда не застревал из-за отсутствия кода на бумаге. Это часто оставляется в качестве упражнения для читателя, который понял статью.
Тем не менее, есть много кода для иллюстрации работ. У авторов обычно есть веб-страница, и даже если рецензент не имеет возможности попробовать и проверить сам код, естественный отбор, кажется, работает довольно хорошо, и авторы, которые не публикуют код, цитируются гораздо реже.
источник
Об этом, возможно, уже спрашивали некоторое время назад, однако я всегда был сильно настроен по этому поводу, поэтому я дам свои два цента. Я работал в течение многих лет (не больше) в сообществе SAT. Большинство исследователей редко публикуют свой код. Статья публикуется вместе с алгоритмом, но очень редко можно увидеть фактический код SAT-решателя (MAXSAT-решателя) и т. Д., Опубликованный вместе со статьей.
И реальность такова, что с помощью только кода, опубликованного в статье, у вас никогда не будет возможности воспроизвести эксперименты автора. Не только потому, что опубликованный код не является полным (конечно), но также и потому, что даже опубликованный псевдокод редко переводит полупрямо в то, что фактически реализовано.
Причину этого трудно понять, и она может зависеть от исследователя к исследователю, но в большинстве случаев она двоякая.
Во-первых, исследователь, как правило, постоянно работает в одном решателе, публикуя статьи после работ в одном и том же решателе и постепенно добавляя новые функции, которые переводят в новые версии решателя. Существует нездоровая навязчивая идея, что конкуренция будет использовать ваш решатель для дальнейшей карьеры, расширяя его и публикуя статьи без должного доверия (имеется в виду, соавторство).
Во-вторых, некоторый код действительно (как и все программное обеспечение) написан в спешке. Полуготовые сценарии. Непроверенные функции и т. Д. Публикуя этот код, исследователь чувствовал бы, что он будет смущать себя и наносить ущерб их репутации.
Я оставляю вас с недавней ссылкой на это от ACM: http://cacm.acm.org/magazines/2011/5/107698-the-importance-of-reviewing-the-code/fulltext
источник
Исторически научные статьи должны были печататься на бумаге, а журналы доставлялись на международном уровне. Каждая дополнительная страница использовалась, чтобы добавить значительную стоимость, поэтому статьи были подвержены ограничениям по длине, и даже простой рабочий код обычно занимал гораздо больше места, чем неформальное описание.
Сегодня нет веских причин не включать код в какую-либо статью, ссылающуюся на алгоритм.
Также может быть полезно отказаться от ориентированных на печать форматов, таких как pdf и postscript, в пользу более семантически осведомленных форматов (HTML с MathML или, возможно, вариант с открытым исходным кодом Mathematica).
источник