Является ли неэтичным/ненаучным опускать данные, выпадающие из нормы, в публикации, когда они говорят в пользу вашего аргумента?

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

У меня много таких сюжетов, и из-за нехватки места я не могу выделить им много места. Участки имеют высоту 1-2 сантиметра. Проблема в том, что горстке (может быть, 5 или около того) этих образцов потребовалось смехотворно короткое время (скажем, несколько миллисекунд), тогда как почти все остальные точки данных заняли 2-3 порядка величины. дольше.

Я пытаюсь показать, что мой алгоритм работает быстро, поэтому я полагаю, что не повредит просто опустить эти несколько точек данных и сгенерировать больше выборок, верно?

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

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

Вы имели в виду, что 5 из 10 000 были супербыстрее?
@scaaahu: Да. (Есть ли другая возможная интерпретация моего вопроса, которую я упускаю?)
Нет, я просто хочу убедиться, что правильно прочитал ваш вопрос. Пять из 10 000 — это экстраординарно. Для этого могут быть и другие причины.
Решит ли сломанная ось вашу проблему?
@Wrzlprmft: Не совсем, сломанная ось была бы еще более запутанной, чем просто ее включение ...
Неэтично/ненаучно ли опускать выбросы данныхда.
Вау, этот вопрос получил гораздо больше просмотров, чем я ожидал...

Ответы (8)

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

Причина в том, что неожиданно «хорошие» данные могут быть таким же признаком проблем с вашей теорией, как и неожиданно плохие данные. Эти точки данных говорят вам, что у вас есть ошибка в вашем алгоритме? Они говорят, что инструменты, которые вы использовали для измерения времени, были ненадежными или неправильно откалиброванными? Или дело в том, что при определенных обстоятельствах ваши случайные проблемы решаются исключительно легко? Могут быть и другие возможности.

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

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

... проблемы с вашей теорией или с экспериментом. Помните: «Я не могу этого объяснить» — вот где можно найти настоящие открытия.
По крайней мере, я думаю, вам нужно выяснить, воспроизводятся ли значения выбросов путем повторного запуска одного и того же ввода - даже если ввод был сгенерирован "случайно", вы, вероятно, можете сохранить его и повторно использовать. Если они не воспроизводимы, и вы не можете объяснить, почему, следующим вопросом может быть «демонстрируют ли какие-либо из ваших результатов что-либо вообще».
Кроме того: было проведено несколько исследований, в которых то, что казалось выбросами, на самом деле было достоверными данными . Хотел бы я вспомнить их навскидку, но я кое-что читал об этом в прошлом году или около того.

Это ненаучно?

Да. Цель этих графиков не в том, чтобы показать, что алгоритм работает быстро, а в том, чтобы дать точное представление о его скорости. Намеренное удаление выбросов без объяснения причин дает искаженную картину. Это нормально, если вы четко об этом говорите (например, поясняете в подписи или тексте о том, какие выбросы были удалены и почему), но не в том случае, если вы делаете это молча.

Эти выбросы могут действительно иметь значение:

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

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

  3. Если кто-то реализует алгоритм и сравнит свои результаты с вашими, он может потратить время на то, чтобы понять, почему у него есть выбросы, а у вас нет.

Особенно для алгоритмов, где важна производительность в пограничных случаях, идея о том, что вы можете отбрасывать выбросы,... немного проблематична.
@Fomite: Ну, моя идея заключалась в том, что наихудшие случаи почти всегда интересны, но лучшие случаи редко бывают интересными, поскольку легко сделать так, чтобы алгоритм имел «быстрый путь» для возврата ответов на простые запросы. Например, представьте, что вы пытаетесь отсортировать список и обнаруживаете, что список уже отсортирован. Тогда вам вообще не нужно было бы делать что-либо еще, и алгоритм в этих случаях завершался бы намного быстрее. Но (если только ваш алгоритм не является рекурсивным) это время выполнения в лучшем случае не будет интересным при оценке производительности вашего алгоритма сортировки, поэтому вы можете попытаться исключить его.
@Mehrdad, такой алгоритм может быть полезен в ситуации, когда вы ожидаете, что ваши списки будут упорядочены большую часть времени, но не всегда. Лучшие случаи действительно интересны и, как показывают ваши собственные тесты, не так надуманы (раз в две тысячи случайных случаев).
@Davidmh: я никогда не отрицал полезность такого алгоритма. Я отрицал полезность построения наилучшего поведения такого алгоритма во многих (не во всех) случаях. Это затрудняет осмысленное сравнение алгоритма с другими, если только вы по какой-то причине не ожидаете, что списки будут упорядочены большую часть времени, чего обычно не происходит.

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

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

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

+1 за первый абзац. Это более убедительно, чем я нахожу некоторые другие ответы.

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

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

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

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

Что касается отображения этих выбросов, рассматривали ли вы возможность отображения этого графика с логарифмической (10) осью Y? Это уменьшит количество неиспользуемого пространства, но все же покажет, что есть выбросы.

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

@Mehrdad, это может быть немного экстремально, но это определенно не поможет вашей карьере. Вы в основном удаляете точки данных, потому что они не соответствуют вашему представлению о том, как должны выглядеть данные. Это указывает на то, что вы считаете свою идею более важной, чем реальность, что противоречит тому, чем занимается наука: созданием точного представления реальности.
Обычно скрытые или искаженные данные настигают преступника с неприятными последствиями. Если вы хотите рискнуть, это ваше дело. В целом люди в вашей области, которые являются вашими конкурентами, будут намного менее добры, чем люди на этом сайте. Им будет приятно доказать, что вы ошибаетесь, если вы таковы. Как уже говорили другие, вы должны быть в состоянии объяснить выбросы, иначе вы не готовы к публикации.
@Nzall Судя по моему прочтению вопроса, ОП не удалял точки данных, потому что они не соответствовали его представлению о том, как должны выглядеть данные. Когда вы запускаете программу много раз с различными входными значениями, вы можете по счастливой случайности получить некоторые данные, которые попадут прямо во все ветки if-then-else и структуры цикла-до-сделано, такие как диарея. Если нет ничего плохого в этих входных значениях, и нет ничего неудобного в этих временных результатах, и включение этих конкретных графиков излишне загромождает бумагу, то я не вижу проблемы в том, чтобы не выбрать эти ...
... конкретные сюжеты для включения в статью. Когда мы слышим «выброс», мы иногда делаем поспешные выводы. Может быть полезно изучить, что именно подразумевается под «выбросом», прежде чем делать вывод.
@ aparente001 Если у вас есть данные, которые проваливаются и дают неожиданные результаты, то вы должны понять, почему они проваливаются в эти трещины и почему они дают такие результаты. Экстремальные выбросы могут указывать на ошибку в вашем алгоритме обработки данных, что иногда может даже изменить результат того же алгоритма, примененного к другим точкам данных.
@Nzall - В этом случае это не неожиданные результаты, верно? Я понял, что некоторые входные значения по счастливой случайности занимают все короткие ветви в ромбах «если-то-иначе». ("Провалиться сквозь трещины" - это не то, о чем я говорил.)
@ aparente001 Как ИТ-специалист, входные данные, которые «по счастливой случайности» занимают все короткие ветви, с большой вероятностью не будут обрабатываться так же, как другие данные, и поэтому могут обрабатываться неправильно. То, что я сказал, технически ничем не отличается от большинства других ответов, за которые проголосовали больше, чем за меня.
@Nzall - Правда, ваш ответ похож на другие. Ваш недавно, и ваш занимает более сильную позицию. (Я предполагаю, что именно поэтому вы написали это — вы хотели пойти дальше, чем другие ответы.) // Посмотрите, если я предложу алгоритм, который ведет себя смехотворно хорошо с крошечной долей входных данных, которые были сгенерированы случайным образом, и я отказываюсь представить эти конкретные результаты производительности, чтобы поддержать мое заявление о том, что мой алгоритм быстрее, чем другие, что сильно отличается от исключения подмножества результатов производительности, которые опровергают мое утверждение. // Подумайте о блок-схеме. Скажем...
... для простоты у нас есть блок-схема, в которой есть ряд «если то-то и то-то, делай то или это, иначе ничего не делай», и некоторые случайно сгенерированные данные попадают в большинство или все else разветвляется, таким образом, смехотворно быстро проходя через блок-схему (именно здесь я использовал метафору диареи), означает ли это, что алгоритм не годится? Вот еще один способ взглянуть на это. Представьте себе дерево решений, в некоторых ветвях которого очень мало циклов, и иногда входные данные по счастливой случайности пересекают эти конкретные ветви. Время выполнения для тех конкретных ...
...входы могут быть смехотворно короткими. // Это правда, что в этом случае может быть хорошей идеей настроить программу на выполнение алгоритма десять раз подряд — всегда. Но это не устранило бы эти выбросы. // Что касается вашего комментария «берет все короткие ветки, то, скорее всего, он не будет обработан так же, как другие данные» — было бы неэтично пропустить процесс тестирования и проверки. У нас нет оснований думать, что OP скупился на тестирование; у нас есть признаки того, что он из кожи вон лез, чтобы избежать неэтичного поведения.

Чтобы быть прагматичным (и соглашаясь с общей философией полной прозрачности), просто разместите свои диаграммы в отведенном для этого месте, исключив выбросы, а затем поместите большую сноску на диаграмму, объясняющую, что 5 точек были исключены из-за ограничений размера на странице. и предложите там комментарий о том, почему/как эти точки существуют. Просто мои 2 цента от одного многострадального академика другому...

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

Всегда полезно изменить графики, чтобы данные выглядели более четкими. Никогда не рекомендуется изменять ваши данные, чтобы ваши графики выглядели более четкими.

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

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

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

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