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

62

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

algorithms asymptotics

— dsaxton
источник

7

Одна реальная проблема с этим свойством, которое приходит на ум, - взлом хэша несоленого пароля, когда он сформулирован как «если дано n хешей, взломайте хотя бы один хеш». Поскольку скорость взлома будет линейно масштабироваться с n, время работы будет пропорционально 1 / n - за исключением того, что мы не можем фактически назначить определенное время, так как взлом является стохастическим и не имеет постоянной верхней границы по времени.

— Амон

1

@amon Время работы не масштабируется как . Требуется время чтобы прочитать хэшей, которые вы указали в качестве входных данных!

1 / n

$1/n$

n

$n$

n

$n$

— Дэвид Ричерби

3

Вы имеете в виду проще в абсолютном или относительном выражении? Какие меры стоимости вы разрешаете? Требуете ли вы строго снижения стоимости или недостаточно (с какого-то момента) достаточно?

— Рафаэль

2

@DavidRicherby В этом примере допустимо игнорировать затраты на чтение входных данных, пока я не сделаю никаких заявлений об абсолютной стоимости. Вместо этого скорость увеличивается линейно с входом. Следовательно, n • T (1)> T (n) даже при рассмотрении затрат на чтение входных данных. Т.е. для этой проблемы легче решить большой вход сразу, чем разделить вход, даже если проблема делится. Я не говорю, что T (n)> T (n + 1) для всех n.

— Амон

4

Всем, кто хочет опубликовать еще один ответ в форме: «Некоторая проблема, когда ввод - это вопрос, плюс много подсказок об ответе»: это не работает. Самые сложные входные данные длины - это те, где вы используете все бит, чтобы задать вопрос и не давать подсказок. Тот факт, что легко отвечать на короткие вопросы с большим количеством подсказок, не означает, что наихудшее время выполнения хорошо.

n

$n$

n

$n$

— Дэвид Ричерби

39

Нет, это невозможно: по крайней мере, не в асимптотическом смысле, когда вам нужно, чтобы проблема становилась все проще и проще, навсегда, как . $n \to \infty$

Пусть будет наилучшим временем выполнения для решения такой проблемы, где - размер входных данных. Обратите внимание, что время выполнения - это количество команд, выполняемых алгоритмом, поэтому оно должно быть неотрицательным целым числом. Другими словами, для всех . Теперь, если мы рассмотрим функцию , мы увидим, что нет такой функции, которая является строго монотонно убывающей. (Каким бы ни было , оно должно быть конечным, скажем, ; но так как монотонно строго убывает, и $T(n)$ $n$ $T(n) \in \mathbb{N}$ $n$ $T: \mathbb{N} \to \mathbb{N}$ $T(0)$ $T(0)=c$ $T$ $T(c) \le 0$ $T(c+1) \le -1$ , что невозможно.) По аналогичным причинам не существует функции, которая асимптотически строго убывает: мы можем аналогичным образом доказать, что не существует функции времени выполнения где существует такое, что для всех , монотонно строго убывает (любая такая функция должна в конечном итоге стать отрицательной). $T(n)$ $n_0$ $n \ge n_0$ $T(n)$

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

Обратите внимание, что этот ответ охватывает только детерминированные алгоритмы (т. Е. Время выполнения в худшем случае). Это не исключает возможности рандомизированных алгоритмов, чье ожидаемое время работы строго монотонно уменьшается, навсегда. Я не знаю, возможно ли существование такого алгоритма. Я благодарю Бени Чернявского-Паскина за это наблюдение .

— DW
источник

9

Это хорошее доказательство, но я не согласен с предпосылкой. Вместо того, чтобы запрашивать строго монотонно убывающее время выполнения, вопрос может быть более разумным: требовать функции, где существуют a, b с a <b, так что T (a)> T (b), то есть не строго монотонно убывающим. Тогда, конечно, можно найти подходящие целочисленные функции. Но почему целые числа? У меня сложилось впечатление, что время выполнения обозначает время, а не количество команд (кроме, конечно, для машин Тьюринга), и что выражение T может использовать нецелочисленные операции, такие как log () или нецелые показатели.

— Амон

2

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

— Дэвид Ричерби

3

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

T (n) = n^{2} \cdot (1 + ϵ)^{- n} + n

$T(n) = n^2 \cdot (1+\epsilon)^{-n} + n$

T (n) \sim n

$T(n) \sim n$

T (n) \approx n^{2}

$T(n) \approx n^2$

n

$n$

— Рафаэль

2

@Raphael, не проблема становится проще: становится больше , как становится больше, поэтому проблема становится все труднее , поскольку становится больше, когда достаточно велико. В первом предложении моего ответа я утверждал, что ни одна проблема не может продолжаться вечно. Конечно, проблема может стать легче на некоторое время ( скажем, может уменьшиться для ), но это не может продолжаться вечно.

T (n) \sim n

$T(n) \sim n$

T (n)

$T(n)$

n

$n$

n

$n$

n

$n$

T (n)

$T(n)$

n \leq c

$n \le c$

— DW

1

Даже с целочисленными временами для рандомизированного алгоритма ожидаемое время (или любая другая мера распределения) может быть дробным и может постепенно приближаться к некоторой константе сверху. [Это не означает, что такие проблемы действительно существуют, только то, что аргумент «нет такой функции существует» является недостаточным.]

T

$T$

— Бени Чернявский-Паскин

25

Хотя это не совсем ответ на ваш вопрос, алгоритм поиска строк Бойера-Мура подходит близко. Как Роберт Мур говорит на своем веб-сайте об алгоритме,

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

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

— Рик Декер
источник

10

Можно утверждать, что шаблон - это не размер проблемы, а длина искомой строки. Как и в приведенном выше комментарии Дэвида Ричерби , я бы сказал, что длина шаблона - это скорее подсказка о том, как решить проблему (о поиске строки), чем сама проблема (проверка, соответствует ли шаблон строке определенной длины). .)

— Кевин - Восстановить Монику

4

@Kevin Это утверждение предполагает, что поиск шаблона длины в тексте длиной быстрее, чем поиск шаблона длины . Глядя на такие входные данные с фиксированным отношением (т. Е. Пары строк), я думаю, что Рик дал подходящий ответ на вопрос (если не в классическом, асимптотическом смысле).

\sqrt{n}

$\sqrt{n}$

n

$n$

\log n

$\log n$

— Рафаэль

10

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

Направления : чем дольше ваши направления, они иногда могут стать легче. Например, если я хочу, чтобы Карты Google указывали, как проехать 3000 миль на запад, я мог бы доехать до Западного побережья и получить инструкции по вождению по пересеченной местности. Но если бы я хотел проехать 6000 миль на запад, я бы получил гораздо более простые инструкции: сесть на самолет из Нью-Йорка и Хоккайдо. Предоставить мне маршрут по пересеченной местности, который включает в себя движение, дороги, погоду и т. Д., Довольно сложно алгоритмически, но сказать мне, чтобы сесть на самолет и поиск рейсов в базе данных, сравнительно значительно проще. График сложности ASCII в зависимости от расстояния:

           |     /
           |    /
Difficulty |   /                  ____-------
           |  /           ____----
           | /    ____----
            ---------------------------------
                       Distance

Рендеринг : скажем, я хочу рендеринг одного лица и рендеринг 1000 лиц; это для рекламного щита, поэтому оба конечных изображения должны быть размером 10000 на 5000 пикселей. Реалистично воспроизвести одно лицо было бы трудно - при разрешении в несколько тысяч пикселей по ширине вы должны использовать действительно мощные машины - но для толпы из 1000 лиц каждое лицо должно иметь ширину всего в десять пикселей и его можно легко клонировать! Я мог бы, вероятно, отрисовать 1000 лиц на своем ноутбуке, но для рендеринга реалистичного лица в 10000 пикселей потребуется очень много времени и мощных машин. График сложности ASCII в сравнении с визуализированными объектами, показывающий, как сложность рендеринга n объектов в изображение заданного размера быстро уменьшается, а затем медленно возвращается:

           | -    
           |- -                     _________
Difficulty |   --      ______-------            
           |     ------      
           |       
            ---------------------------------
                        Objects

Аппаратное управление : многое с аппаратным обеспечением становится намного проще. «Двигатель X 1 градус» сложен и / или невозможен, и вам придется иметь дело со всеми видами вещей, с которыми вам не придется сталкиваться при «Двигателе Х 322 градус».

Краткосрочные задачи: скажем, вы хотите, чтобы элемент X включался (очень небольшое количество времени) каждую секунду. Увеличивая время работы X, вам потребуется менее сложное программное и аппаратное обеспечение.

— Оуэн Верстейг
источник

В своем примере «Указания», пожалуйста, укажите, что именно является вычислительной проблемой, а что является примером. Мне совсем не ясно, что ваш пример в 6 тыс. Миль - это более крупный пример или просто пример легкой части чего-либо (например, если я дам вам большой граф, связанный граф, плюс одну изолированную вершину, то запрос о кратчайших путях вообще «сложно», но запрос кратчайшего пути из изолированной вершины в любое место тривиален). Опять же, для вашего примера рендеринга, что является реальной вычислительной проблемой? В каком случае вы измеряете сложность?

— Дэвид Ричерби

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

— Дэвид Ричерби

Я думаю, что для перемещения параметров будет название 2 городов, а n будет количество символов для их кодирования.

— Эмори

3

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

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

— Корт Аммон
источник

2

Вопрос интересный и ПОЛЕЗНЫЙ, потому что наша философия в информатике заключается в том, чтобы решать проблемы: чем больше мы читаем, тем сложнее. Но, на самом деле, большинство проблем, которые представлены в типичном (сложном), могут быть легко представлены «простым» способом; даже зная реакцию DW (что неверно, учитывая, что «легкий» не означает «быстрее», означает «менее медленный»; поэтому вам не нужно находить отрицательные моменты, вы обнаруживаете асимптотическое время).

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

Пример: Какой самый длинный путь в автомобиле между Лондоном и Парижем, когда нужно дважды посещать французский и британский город и не посещать другую страну? учитывая, вы должны поехать в Бирмингем до Эшфорда, Орлеан до Версаля, Ля-Рошель до Лиможа и т.д ...

Понятно, что эта проблема с длинными записями будет проще, чем с короткими.

Пример использования: Представьте себе игру, управляемую машиной, и ИА компьютера должен определить, должен ли он исследовать больше в игре, чтобы найти больше подсказок, или нет, если сейчас пришло время сделать вывод, какое решение лучше принять ,

— Хуан Мануэль Дато
источник

2

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

— Дэвид Ричерби

@ Давид, ваш ответ совершенно неверный: 1. Запись не является графиком: большой график является ПАРАМЕТРОМ. Таким образом, гамильтонова задача преобразуется в постоянную (очень большую, но постоянную). 2. Запись является решением проблемы, поэтому: если больше, вы предлагаете комбинаторный анализ подсказок. Ввод одной подсказки дает помощь, две подсказки - двойную, три подсказки будут близки к 4 дважды ..., потому что вы исключаете возможные решения. Таким образом, это был не гамильтониан, это решение из специфического графа, и проблема в том, ЧТО делать с частями решений.

— Хуан Мануэль Дато

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

— Том ван дер Занден

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

— Хуан Мануэль Дато

n \log n

$n\log n$

1

Рассмотрим программу, которая принимает в качестве входных данных то, что вы знаете о пароле, а затем пытается его взломать. Я думаю, что это делает то, что вы хотите. Например:

Нет ввода-> грубая сила взломать все символы и слова любой длины
Длина пароля -> Перебор всех символов в слове такой длины
Содержащие символы -> Сокращает список символов для проверки
...
Содержит символы, включая несколько вхождений и длину -> Только вычисления перестановок
Все символы в правильном порядке -> в основном решил сам

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

Так что все сводится к тому, сколько абстракции вы позволите.

— RunOrVeith
источник

2

b

$b$

0

На самом деле, у меня есть проблема, которая уменьшается по мере увеличения данных. Одно из моих приложений записывает атрибуты определенного продукта, скажем, сыр. Атрибутами являются, например, CheeseType, Brand, Country, Area, MilkType и т. Д. Каждый месяц или около того я получаю список новых сыров, которые появились на рынке за это время, вместе с их атрибутами. Теперь эти атрибуты набираются вручную группой людей. Некоторые делают опечатки, или просто не знают значения для всех атрибутов.

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

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

Так что да, некоторые проблемы решаются в конце концов, когда у вас достаточно данных.

— Крис
источник

1

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

— Дэвид Ричерби

Это реальная проблема (у меня уже была дважды), которая не может быть решена с небольшим количеством данных. Он может, и даже становится легче отличить хорошие значения от неправильных, так как объем становится высоким. Заслуживает внимания ответ на вопрос «Есть ли проблемы, которые становятся легче по мере увеличения их размера?» Неважно, сколько типов сыров подходит, в конце концов, при достаточном объеме, у них будет больше «хитов», чем опечаток. Это cs .stackexchange, а не математика, поэтому проблемы разные, и их решение иногда просто связано с большей уверенностью в результатах.

— Крис

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

— Дэн Хендерсон

2

«Становится более эффективным»! = «Становится легче».

— Дэвид Ричерби

-1

Рассмотрим NP-полную задачу 3-SAT. Если вы продолжаете увеличивать проблему, предоставляя входные данные в форме x_i = true / false, вы либо в конечном итоге преобразуете отдельные дизъюнкции в предложения с двумя переменными, создавая тем самым проблему 2-SAT, которая решительно равна P, либо вы просто получаете истинный / ложный ответ.

В случае, когда на входах x_i = true / false имеется избыточность (один и тот же вход предоставлен много раз или противоречивые входы), вы можете легко отсортировать входы и либо игнорировать избыточные значения, либо сообщить об ошибке, если значения противоречат.

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

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

— v vv cvvcv
источник

1

Эти конкретные входные данные становятся проще. Однако, когда вы учитываете все возможные входные данные, 3SAT в целом становится значительно сложнее, когда вы добавляете больше предложений: жесткие входные данные - это входы без этих «подсказок». Если вы не разрешаете вводить общие данные, вам необходимо указать, какие именно данные вы допускаете

— Дэвид Ричерби

Прежде всего: мы согласны с тем, что добавление дополнительных входов может увеличить время работы. Я говорю по существу то же самое выше. Во-вторых, я четко говорю, что мы берем существующий 3-SAT и добавляем только входные данные в форме x_i = true / false. Я думаю, что это достаточно ясно, и мне не нужно делать никаких дополнительных разъяснений. Я думаю, что вы берете на себя труд составить самое неверное толкование того, что я написал. Пожалуйста, не беспокойтесь.

— vv vv cvvcv

1

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

— Дэвид Ричерби

Не могли бы вы четко заявить о своем понимании «моего требования»? Как только вы попытаетесь уточнить это, я почти уверен, что вы перестанете тратить трафик интернета.

— vv vv cvvcv

Я ученый, а не читатель разума. Уточнение вашего требования - ваша работа, а не моя.

— Дэвид Ричерби

-1

Вопрос спрашивает: «возможно ли иметь проблему, которая на самом деле становится легче, когда входные данные увеличиваются в размере?» Что делать, если входные данные являются ресурсами, которые будут использоваться алгоритмом для работы над заданием. Общеизвестно, что чем больше ресурсов, тем лучше. Ниже приведен пример, в котором чем больше сотрудников, тем лучше.

$n$
$t$ $p$

$n$

3) Вывод:
вывод - это пути между задачами, которые должны выполнять сотрудники. Каждый путь связан с количеством сотрудников, принимающих его. Например:

$n1$
$n2$
$n3$
$n4$
$n5$

4) Возможное решение.
Одним из возможных решений является сначала вычисление кратчайшего пути к ближайшим узлам из A. Это будет прямой путь. Затем рекурсивно вычислите прямой путь для каждой посещенной задачи. Результатом является дерево. Например:

          
      до н.э
    Делавэр

$n$ $n1$ $n2$ $n2 \neq 0$

$n=\infty$ $n = 1$

$n$

— yemelitc
источник

6

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

— DW

На входе может быть просто число (количество ресурсов). Это повлияет на количество дополнительных вычислений, которые придется выполнить алгоритму. Я отредактирую ответ, чтобы привести более конкретный пример.

— yemelitc

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

— Дэвид Ричерби,

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

— yemelitc