Отзыв документов CS (конференции)

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

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

Я понимаю, что такие ошибки не убьют людей напрямую, как могли бы ошибки в науках о жизни, но я все еще обеспокоен. Может более серьезная версия https://xkcd.com/386/ , но все же.

Конкретный случай

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

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

Я тоже не в этой области — я вмешался просто потому, что дружил с одним студентом, проводившим исследования с экспертами А, и он просто попросил меня помочь, когда не смог понять статью Б.

РЕДАКТИРОВАТЬ : я забыл указать, почему я говорю «грубая небрежность», и я согласен, что это было плохо с моей стороны. Вот нейтральные факты, насколько я могу их вспомнить/проверить:

  • включенный псевдокод имеет ошибку типа в критической процедуре — если вы индексируете матрицу, вам нужны два индекса, а не один. Мы начали расследование, потому что не могли понять псевдокод. Это было во второй статье конкретно о реализации. РЕДАКТИРОВАТЬ: все 8 обращений к массиву в 21 строке имеют ошибку этого типа, так что это не опечатка.
  • алгоритм не работает на работающем примере. РЕДАКТИРОВАТЬ: под запуском примера здесь подразумевался пример, используемый на протяжении всего документа. Но я перепроверил, и оскорбительный пример - это всего лишь второй, который они используют.
  • документ реализует и сравнивает алгоритм, который он описывает, с наивной реализацией, но не обнаружил, что результаты алгоритма (EDIT) неверны. После того, как вы сделали 90% работы, сравнить результаты довольно легко.

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

РЕДАКТИРОВАТЬ2 :

  • Вопрос начинается со слов «Предположим, вы узнаете [о случае, который...] пахнет грубой небрежностью», а затем фокусируется на опровержении (а не на неправомерных действиях). Вы можете подвергнуть сомнению это предположение только в том случае, если такого случая не существует. Я делаю набросок одного примера, но это просто подтверждающие доказательства; в центре внимания вопроса не может быть рассмотрение конкретного дела. Я не против обсудить это дело, но я просто пытаюсь аргументировать правдоподобие.
  • Я все еще думаю, что в таком контексте следует сравнивать ожидаемые и фактические результаты, по крайней мере, после того, как вы реализовали оба. В руководящих принципах Немецкого научного фонда говорится, что «хорошая научная практика включает следующие фундаментальные принципы: ... последовательно и критически подвергать сомнению все результаты». Что кажется мне здравым смыслом.
  • Я уверен, что знаю о честных ошибках (которые тоже надо как-то исправлять). Никто не ожидает, что все доказательства будут безошибочными и формализованными.
  • Google предполагает, что «халатность» может быть «грубой», только если она угрожает жизни людей. Я этого точно не предлагаю. Если это так, я извиняюсь за это и делаю поправку на халатность.
Разбрасывание «грубой небрежности» в отношении ошибки в документе делает этот вопрос очень нагруженным. Все исследования совершают (и публикуют) «ошибки» — у нас есть ранние результаты, мы неверно их интерпретируем, мы узнаем больше позже и заново анализируем проблему. И тогда мы напишем лучшую, надеюсь, более правильную статью. Теперь исходный документ с ошибкой все еще может быть полезен для ссылки, если он был первым, кто поднял и описал проблему, даже если «решение» было неверным.
В первой статье приведены 3 других решения той же проблемы и уже несколько вариантов. (Также я отредактировал вопрос, чтобы уточнить, откуда это взялось, что я должен был сделать раньше).
Первая "грубая небрежность" выглядит как опечатка. Во-вторых, причуда, связанная с установкой, или то, что они представили неправильный пример. Третьим может быть небрежный анализ или то, что они не удосужились упомянуть, думая, что это очевидно.
@Davidmh Основываясь на вашем комментарии, я, должно быть, был неясен и пытался уточнить, что я имел в виду.
«если вы индексируете матрицу, вам нужно два индекса, а не один». Это не верно. Просто объявите, если матрица является основной по строкам, и доступ к записям как [i + j * # cols] вместо [i, j], и все готово. (И вот как матрицы реализованы в конце)
@FooBar Я знаю о порядке строк, но больше нигде в этой статье не используется это обозначение, и здесь это не имеет смысла. Мы попытались исправить подпрограмму, но нам удалось доказать, что остальная часть алгоритма не может работать независимо от того, что делает эта подпрограмма — «ошибка типа» была лишь отправной точкой. Но, откровенно говоря, как только авторы подтвердили, что статья ошибочна, и поскольку я не буду называть статью (и никто здесь этого не делает), я не думаю, что будет продуктивно защищать статью, которую вы не видели.

Ответы (2)

Исправить ошибки в материалах конференции, безусловно, возможно — я сам это сделал.

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

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

Я не знаю, изменилась ли ситуация с тех пор, но когда я спросил Springer в 2008 году, возможно ли добавить исправленную версию вклада LNCS (или ссылку на исправленную версию, хранящуюся во внешнем хранилище) в SpringerLink, на случай, если опубликованная версия содержит фактическую ошибку, ответ был таким: «Нам не разрешено добавлять или изменять что-либо в документах lncs на SpringerLink. Единственное, что мы могли бы сделать, это ввести текст опечатки, объясняющий ошибку. это, но наш отдел исправлений может не одобрить это».
Где опечатка (которая на самом деле является новой статьей с doi и всем остальным) для опубликованного доклада конференции? Если это специальный выпуск обычного журнала, окей, следующий номер, а иначе? Через год с материалами очередной конференции? Скорее всего, не. Конечно, было бы просто опубликовать его в Интернете, но журналы так не работают, не так ли?
Я не знаю, как Springer это делает (или не делает), но IEEE добавляет исправление к «абстрактной» странице в IEEE Xplore.
А, нашел информацию об ошибках для IEEE и Springer, но не для ACM, по адресу: supportcenter.ieee.org/app/answers/detail/a_id/1012/~/… и springer.com/gp/authors-editors/journal-author /…

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

Правильнее было бы упомянуть ошибку в более поздней статье и исправить ее там. И было бы хорошим стилем перестать впоследствии цитировать старую. Но я бы не стал рассматривать это как грубый научный проступок. Они просто немного увеличивают свой индекс Хирша.

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

«Тот, кто заинтересован, все равно не будет доверять исходному документу конференции» - это несколько специфично для данной области. В некоторых подобластях CS документ конференции является основным, за ним не обязательно следует какая-либо другая статья.
@ORMapper Это не говорит ничего хорошего об актуальности указанной статьи, не так ли? Я имею в виду, если это единственная статья и хорошо цитируется, хорошо, но в противном случае я скажу, что она была только что опубликована, потому что автору нужно было быть первым автором другой статьи, чтобы получить докторскую степень. ;-) По общему признанию, я не знаком с обычаями в CS.
«Это не говорит ничего хорошего об актуальности упомянутой статьи, не так ли?» - не позволяет сделать вывод об актуальности статьи. «Признаться, я не знаком с обычаями в CS». - нет, очевидно, что нет :) (Обратите внимание, что CS разнообразен. Обычаи различаются даже между подполями.)
Хорошо. ОП говорит, что за документом конференции последовал обычный, который, по его мнению, был сделан правильно. И как бы то ни было, я не верю, что люди в CS или где-либо еще не очень подозрительны при чтении статей конференции. Они написаны с фиксированным сроком, и средний рецензент не уделяет им такого же внимания, как обычные статьи.
Что ж, ОП также говорит, что они «вне поля», и, по общему признанию, журнальные статьи действительно являются основным каналом публикации в большинстве областей. Тем не менее, для всех намерений и целей, в некоторых областях документы конференции являются обычными документами.
Я действительно из другой области CS, но несколько источников подтверждают, что документы конференций CS часто имеют наибольшее значение, см., Например, academia.stackexchange.com/q/38086/8966 .
Отзыв документов CS (конференции)
СпросиСетьПолитика конфиденциальности1y, 0v