Определяет, есть ли простое число в интервале, о котором известно, что оно находится в P или NP-полных?

13

Из этого поста я узнал, что в стеке есть поток, и есть несколько относительно быстрых алгоритмов для просеивания интервала чисел, чтобы увидеть, есть ли в этом интервале простое число. Тем не менее, означает ли это, что общая проблема решения: (Существует ли простое число в интервале?) В P. (Было много ответов на этот пост, которые я не читал, поэтому я прошу прощения, если этот вопрос дубликат или ненужный).

С одной стороны, если интервал достаточно велик (например, ), то применяется что-то вроде постулата Бертрана, и в этом интервале определенно есть простое число. Однако я также знаю, что между двумя простыми числами есть сколь угодно большие промежутки (например, . [N,2N][N!,N!+N]

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

Ari
источник

Ответы:

17

Итак, ваша проблема заключается в следующем:

Входные данные: целые числа Вопрос: существует ли простое число в [ , u ] ?,u
[,u]

Насколько я знаю, неизвестно, есть ли эта проблема в P или нет.

Вот что я знаю:

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

  • Если гипотеза Крамера верна, то проблема в гипотезе П. Крамера гласит, что разрыв между последовательными простыми числами около равен O ( ( log n ) 2 ) , поэтому следующий алгоритм будет в P: перебирать числа , + 1 , + 2 , + 3 , , проверяя каждое, является ли оно простым; если вы найдете тот, который является основным, немедленно остановитесь с ответом «да»; если ты ударил тебя , остановись без ответа. Гипотеза Крамера говорит нам, что вы остановитесь после большинства OnO((logn)2),+1,+2,+3,...U primality-тесты, чтобы алгоритм работал за полиномиальное время.О((журнал)2)

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

  • Вот еще один простой алгоритм: повторно выбрать случайное целое число из [ , u ] и проверить, является ли оно простым. Остановитесь, если вы найдете простое число или если вы пробовали каждое целое число в [ , u ], и ни одно из них не было простым. Эвристически, мы должны ожидать, что это будет эффективно на практике. Теорема о простых числах говорит нам, что если вы случайным образом выберете число в окрестности u , вероятность его простоты будет около 1 / log n . Таким образом, эвристически, мы должны ожидать, что после примерно O ( log u )р[,U][,U]U1/журналNО(журналU)итерации, вы, как правило, найдете простое число и остановку, если она существует. С другой стороны, из-за проблемы со сборщиком купонов, если в диапазоне нет простого числа , вы остановитесь после O ( ( u - l ) log ( u - l ) ) итераций. Итак, если бы у нас была хорошая верхняя граница для размера самого длинного разрыва между простыми числами, это означало бы, что проблема в BPP. Отсюда следует, что даже без такой верхней границы случайные задачи являются легкими.[,U]О((U-L)журнал(U-L))

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

  • Благодаря этим методам, проблема, вероятно, проста на практике.

  • Из-за вышеупомянутых замечаний я лично сомневаюсь, что проблема является NP-полной.

DW
источник
О(U)
О(поли(журналU))
О(поли(журналU))О(поли(U))
журналUU
Нет необходимости, вы прояснили мое замешательство. Большое спасибо!
Quelklef