Как можно проверить правильность работы решета, близкого к 2^64?

Небольшие простые числа — примерно до 1 000 000 000 000 — легко доступны из различных источников. На Prime Pages (utm.edu) есть списки для первых 50 миллионов простых чисел, primos.mat.br доходит до 10^12, а программы, подобные той, что доступны по адресу primesieve.org еще выше.

Однако, когда речь идет о числах, близких к 2^64, на странице Простые числа чуть меньше степени двойки на primes.utm.edu, и, похоже, это все.

Найденный там тест на простоту отказывается работать с числами, которые не соответствуют double, другие - в других местах - не отказываются и просто печатают мусор. Программа Primesieve.org отказывается работать с числами, которые не меньше чем 40 миллиардов меньше 2^64, что не внушает уверенности в качестве их кодирования. Везде один и тот же результат: nada, zilch, niente.

Шестеренки и шестеренки сит начинают скрипеть примерно на отметке 2^62, а ближе к 2^64 едва ли найдется шестеренка, которая не скрипела бы громко, угрожая развалиться. Следовательно, потребность в тестировании реализации является наибольшей там, где проверка наиболее затруднена из-за нехватки/отсутствия надежных справочных данных. Программа Primesieve.org кажется единственной, которая работает по крайней мере до 2^63 или около того, но я не слишком доверяю ей из-за вышеупомянутой проблемы.

Так как же тогда проверить правильность работы решета, близкого к 2^64? Существуют ли где-нибудь надежные списки для миллиона (или десяти миллионов, или ста миллионов) простых чисел чуть ниже и выше степеней двойки, таких как 2^64, 2^63 и так далее? Или существуют надежные (заслуживающие доверия, проверенные, проверенные) программы, которые выдают такие последовательности или могут проверять простые числа или списки простых чисел?

После проверки сита его можно использовать для создания удобных списков с суммами /checksums для множества интересных диапазонов, но без таких списков ситуация кажется сложной...

P.S.: я определил верхний предел для турбо-сивера Primesieve.org равным UINT64_MAX - 10 * UINT32_MAX или 0xFFFFFFFF600000009. Это означает, что только самые высокие простые числа 10 * UINT32_MAX пока не имеют никаких эталонных данных...


person DarthGizka    schedule 06.11.2014    source источник
comment
точно не вдохновляет... это не секвитор.   -  person Will Ness    schedule 07.11.2014
comment
Представьте себе проект в масштабе Primesieve.org: разрабатываемый десятилетиями движок sieve со всеми настройками, во всех смыслах и целях, является лучшей программой 2^64 sieve в мире, а с исполняемым файлом в консольном режиме, настолько набитым кодом, что он размером почти в мегабайт... И все же они предпочитают обрезать описание работы с «64-битного сита» до «почти» вместо того, чтобы исправлять код. В любом случае они, кажется, больше заботятся о пропускной способности (эталоны времени), чем о чем-либо еще. Думаю, Киму Валишу не нужны простые числа в верхнем диапазоне для его проекта...   -  person DarthGizka    schedule 08.11.2014
comment
Самопроверка содержит только один единственный тест в верхней половине диапазона, который содержит 2^32 числа, начиная с 10^19. Угадайте, что большинство ошибок происходит только в более высоких областях этого диапазона. Даже дерьмовый код Сильвы выдерживал 10^19 и падал только при попытке просеивания на 18446744025000000000 (что на несколько кратно 10^9 ниже предела для primesieve.org). Общее качество проекта отличное, со всеми прибамбасами. Я верю, что они самые быстрые просеиватели на планете, но я не верю, что их производительность близка к верхней границе их диапазона.   -  person DarthGizka    schedule 08.11.2014
comment
Не говоря уже о том, что простой подсчет простых чисел (установленных или очищенных битов растрового изображения) выявляет только некоторые виды ошибок, в то время как другие остаются незамеченными. Вот почему я спросил о контрольной сумме больших наборов простых чисел? (для проверки).   -  person DarthGizka    schedule 08.11.2014
comment
Bigints: да, я рассматривал их, после моды. А именно, я переключил все индексные переменные в своем эталонном коде с uint32_t на uint64_t, что устраняет многие классы потенциальных ошибок. Обычный код по-прежнему использует индексные переменные uint32_t, чтобы хорошо работать в 32-битном режиме. Но я всегда могу запустить его на эталонной реализации для проверки. Теперь моя проблема заключается в проверке эталонной реализации. И я думаю, что у других людей могут быть такие же проблемы, поэтому вопрос стоит задать здесь.   -  person DarthGizka    schedule 08.11.2014
comment
если вы просто измените все на bigint, не будет никаких проблем с манипулированием битами, за исключением ошибок в самом коде bigint, который, как я полагаю, должен быть свободен от ошибок. Так что это будет только медленно, хотя его сложность почти такая же (надеюсь). Затем вы можете просеять некоторый узкий диапазон высоких частот с обеими версиями и сравнить выходные данные для большей уверенности. Затем вы можете реализовать функцию подсчета простых чисел с помощью bigint и также сравнить подсчеты. Или реализовать некоторые (вероятностные) тесты на простоту, опять же с помощью bigints, и протестировать еще несколько сегментов...   -  person Will Ness    schedule 08.11.2014
comment
т. е. использовать несложное сито на bigints в качестве эталонной реализации. вы также можете свернуть свою собственную библиотеку large_int для больших целых чисел, ограниченных 128 битами, 512 битами или чем-то еще, что должно быть довольно тривиально, если нас интересует только достоверность, а не производительность.   -  person Will Ness    schedule 08.11.2014
comment
Уилл, хорошая мысль! Запишите это как ответ. Вы получаете мой голос, а также пару идей... Суть в устранении проблем за счет использования превосходной огневой мощи^W^Wдостаточно больших типов данных. Это не решает вопрос получения большого количества справочных данных, но помогает с надежностью.   -  person DarthGizka    schedule 08.11.2014
comment
вы также можете ответить на свой вопрос. :) не стесняйтесь использовать любую идею, которую вы получили от меня здесь. Отправьте мне пинг, если вы это сделаете, чтобы у меня был шанс проголосовать.   -  person Will Ness    schedule 08.11.2014
comment
о вашем сообщении о проверке кода: здесь, на SO, есть функция, позволяющая опубликовать вопрос и ответ на него одновременно. Потому что просьба о помощи в исправлении сломанного кода, я думаю, здесь актуальна (я не очень разбираюсь в юристах). Так что вы могли бы опубликовать их оба - вопрос и ваш ответ на него одновременно - здесь. Не было бы ожиданий, но вы могли бы изложить свою точку зрения и помочь другим (увидеть те ошибки, о которых вы упомянули).   -  person Will Ness    schedule 08.11.2014


Ответы (3)


Вместо того, чтобы искать предварительно вычисленный список, вы можете сравнить выходные данные вашего сита с другим ситом. Хорошее сито, написанное Toms Oliveira e Silva, доступно по адресу http://sweet.ua.pt/tos/software/prime_sieve.html.

Другой способ проверить ваш код — проверить простоту всех чисел, которые ваше сито сообщает как простые (или, наоборот, проверить не простоту всех чисел, которые ваше сито не сообщает как простые). Хороший способ сделать это — тест Бэйли-Вагстаффа. Вы можете найти качественную реализацию Томаса Р. Найсли по адресу http://www.trnicely.net/misc/bpsw.html.

Вас также могут заинтересовать таблицы псевдопростых чисел Яна Фейтсмы на http://www.janfeitsma.nl/math/psp2/index, которые полны до 264.

person user448810    schedule 06.11.2014
comment
Я исследовал трех «предков» проекта Primesieve.org — prime_sieve.c Ахима Фламменкампа., демонстрационный код Томаса Оливейры и Сильвы, на который вы ссылались, и ecprime Ким Валиш. Если бы я хотел вдохновения для написания новых сит, я мог бы снова обратиться к ним за идеями. Но это код для проверки концепции, не более. - person DarthGizka; 08.11.2014
comment
Допустим, я потратил время на то, чтобы заставить их просеять до 2 ^ 64-1 вместо того, чтобы падать, что тогда? Я по-прежнему не мог доверять их выводам, не сверяясь с чем-то надежным, поскольку их собственные авторы никогда не удосужились сделать это. Даже не удосужились проверить работу в критических углах предполагаемого рабочего диапазона, о чем свидетельствовали аварии. На данный момент я бы просто был доволен, чтобы проверить правильность работы моего собственного кода, большое спасибо. Я еще не сделал ecprime очень тщательно, и его качество, кажется, намного лучше. Но проблема курицы и яйца проверки остается. - person DarthGizka; 08.11.2014
comment
Тестирование на первичность как средство проверки работы сита имеет два недостатка. Во-первых, код проверки простоты более сложен, чем тестируемый код, и, следовательно, ему потребуется еще больше проверок, прежде чем ему можно будет доверять. Второе — пропускная способность. Выполнение тестов простоты на выходе сита выявит только ложные срабатывания (т. е. составные в выходных данных), но ошибки сита, близкие к ограничениям целочисленных типов, более склонны приводить к ложноотрицательным результатам (т. е. простые числа не сообщаются). Поверьте мне. БДТ. Следовательно, тесты на простоту должны выполняться для большинства нечетных чисел в целевом наборе. - person DarthGizka; 08.11.2014
comment
диапазоне, что занимает еще больше времени. На данный момент я использую программу Primesieve.org для выполнения основной части тестирования и создания тестовой инфраструктуры (эксперименты с конвейерной и пакетной операциями и т. д.), но для действительно интересного диапазона, близкого к 2^64, я не никаких справочных данных не имею... - person DarthGizka; 08.11.2014
comment
ecprime хорош, но он ограничивает числа 2 ^ 62. В файле limits указано 0 ‹= числа ‹= 2^62 = 4,61 * 10^18. В любом случае, для таких вещей, как проверка, намного лучше, если исполняемые файлы собираются и проверяются их авторами, а не собираются в целевой системе даже без make-файлов и прочего. - person DarthGizka; 08.11.2014
comment
Для проверки не имеет большого значения, как быстро он работает. Напишите простейшее сито, которое вы можете, а затем сравните его результат с вашим причудливым быстрым ситом. Или напишите простой тестер Миллера-Рабина и проверьте все нечетные числа в пределах 10 ^ 10 от вашего предела. Или скачайте gp/pari и получите список простых чисел, близких к вашему пределу. Или обратитесь за помощью на mersenneforum.org. - person user448810; 08.11.2014
comment
И да и нет. «Да» в том смысле, что пробное разделение за пару дней покроет хотя бы некоторые основания, а результат позволит выявить некоторые ошибки. "Нет" в том смысле, что пробное деление слишком медленное, чтобы покрыть достаточные диапазоны. «Нет» также в том смысле, что все более быстрые алгоритмы, даже в их простейшей реализации, слишком сложны, чтобы им можно было доверять без проверки, что является моментом, когда кошка кусает себя за хвост. - person DarthGizka; 08.11.2014
comment
Чтобы продемонстрировать этот момент, я опубликовал по-видимому, простое и надежное сито в обзоре кода, сито, которое, как было проверено, правильно работает до › 10^19 (то есть › 2^63), но близко к 2^64 оно демонстрирует серьезные ошибки. Например, отсутствие некоторых простых чисел. - person DarthGizka; 08.11.2014
comment
Я согласен с тем, что существующие надежные программы, такие как Primesieve.org, вероятно, лучший способ. Проблема заключается в том, чтобы найти тот, который выходит за рамки Primesieve.org, вплоть до 2^64-1. - person DarthGizka; 08.11.2014
comment
@DarthGizka, если вы возьмете самое простое сито и просто измените каждую переменную int на bigint, разве вы не будете удовлетворены его правильностью? (re: ваш связанный код, любой код, который использует что-либо, кроме +,-,*,/, не прост априори!) - person Will Ness; 08.11.2014
comment
@user448810: библиотека gmp содержит функцию mpz_probab_prime_p(), аналогичную упомянутому вами алгоритму (сочетает пробные Division и Miller-Rabin), что делает ваше решение практически практичным, опираясь на заслуживающий доверия, проверенный код gmp. - person DarthGizka; 08.11.2014
comment
В конце концов, gmp не так хорош для этого; он содержит только некоторые ингредиенты (включая Lucas AFAICS), но эти ингредиенты должны быть объединены в работающий детерминистический тест с использованием чего-то вроде кода Томаса Найсли для Baillie-PSW с использованием gmp. gp/PARI можно использовать как есть, без дополнительного программирования. Либо путем передачи вывода через программу sieve (или в файл), либо с помощью ее интерфейса forprime_t для перебора произвольных диапазонов простых чисел. Жаль, что его нельзя построить для 64-битного режима на неудобной системе LLP64, такой как Windows. forprime_t может работать и с unsigned long, а не только с большими целыми числами. - person DarthGizka; 11.11.2014

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

«Везде один и тот же результат: nada, zilch, niente». Вы недостаточно внимательно ищете. Есть много инструментов, которые делают это. Жаль, что Primesieve не доходит до 2 ^ 64-1, но это не значит, что ничего другого не подходит.

«Как тогда можно проверить правильную работу сита, близкого к 2^64?» Одна вещь, которую я сделал, это провел тест на крайний случай, который проходит через все комбинации начальных и конечных точек около 2 ^ 64-1, проверяя, что ряд методов дает одинаковые результаты. Это зависит от наличия списка этих простых чисел для начала, но есть много способов получить их. Это не только проверяет сито в этом диапазоне, но и проверяет условия начала/конца, чтобы убедиться, что там нет проблем.

Некоторые способы сгенерировать миллион простых чисел ниже 2^64:

time perl -Mntheory=:all -E 'forprimes { say } ~0-44347170,~0' | md5sum

Требуется ~ 2 с, чтобы сгенерировать 1 миллион простых чисел. Мы можем принудительно использовать другой код (Perl или GMP), использовать тесты на простоту и т. д. Много способов сделать это, включая, например, просто зацикливание и вызов is_provable_prime($n). Существуют также другие модули Perl, включая Math::Primality, хотя они намного медленнее.

echo 'forprime(i=2^64-44347170,2^64-1,print(i))' | time gp -f -q | md5sum

Требуется ~ 13 с, чтобы сгенерировать 1 миллион простых чисел. Как и в случае с модулем Perl, существует множество альтернативных способов, включая циклический вызов isprime, который представляет собой детерминированную процедуру (при условии, что используется недревняя версия Pari/GP).

#include <stdio.h>
#include <gmp.h>
int main(void) {
  mpz_t n;
  mpz_init_set_str(n,"18446744073665204445",10);
  mpz_nextprime(n, n);
  while (mpz_sizeinbase(n,2) < 65) {
    /* If you don't trust mpz_nextprime, one could add this:
     * if (!mpz_probab_prime_p(n, 100))
     *   { fprintf(stderr, "Bad nextprime!\n"); return -1; }
     */
    gmp_printf("%Zd\n",n);
    mpz_nextprime(n, n);
  }
  mpz_clear(n);
  return 0;
}

Занимает около 30 секунд и получает те же результаты. Этот более сомнительный, так как я не доверяю его 25 предварительно случайным базовым тестам MR так же, как BPSW или одному из методов доказательства, но в данном случае это не имеет значения, поскольку мы видим, что результаты совпадают. Добавление дополнительных 100 тестов очень затратно по времени, но крайне маловероятно получение ложных результатов (я подозреваю, что у нас есть перекрывающиеся базы, так что это также расточительно).

from sympy import nextprime
n = 2**64-44347170;
n = nextprime(n)
while n < 2**64:
  print n
  n = nextprime(n)

Использование Python SymPy. К сожалению, Primerange использует сумасшедшую память при задании 2 ^ 64-1, поэтому ее невозможно использовать. Выполнение простого метода nextprime не идеально — он занимает около 5 минут, но дает те же результаты (текущий SymPy isprime использует 46 простых оснований, что намного больше, чем необходимо для детерминированных результатов до 2^64).

Есть и другие инструменты, например. ФЛИНТ, ГЭП и т.д.

Я понимаю, что поскольку вы работаете в Windows, мир шаткий и многие вещи работают неправильно. Я протестировал ntheory Perl в Windows, и с Cygwin и Strawberry Perl из командной строки я получил те же результаты. Код GMP должен работать так же, при условии, что GMP работает правильно.

Изменить добавление: если ваши результаты не соответствуют одному из методов сравнения, то один из двух (или оба) неверны. Это может быть неправильный код сравнения! Это помогает всем, если вы найдете и сообщите об ошибках. Маловероятно, но возможно, что они оба ошибаются одинаково, поэтому мне нравится сравнивать с как можно большим количеством других источников. Для меня это более надежно, чем выбор одного «золотого» кода для сравнения. Особенно, если вы используете странную платформу, которая, возможно, не была тщательно протестирована.


Для BPSW существует несколько реализаций:

  • Пари. AES Lucas в исходном коде Pari, поэтому не уверен, насколько он переносим.
  • Т. Р. Красиво. Сильный Лукас, автономный код.
  • Дэвид Кливер. Стандартный, сильный или экстрасильный Лукас. Автономная библиотека, очень понятная, очень простая в использовании.
  • Мой код без GMP, включая математику Монтгомери на ассемблере для x86_64. Конечно, немного быстрее, чем коды bigint.
  • Мой код GMP. Стандартный, сильный, AES или сверхсильный Lucas. Быстрее, чем другие коды bigint. Также есть другие тесты Фробениуса и другие тесты на составность. Можно сделать автономным.
  • У меня есть версия, использующая LibTomMath, которую я надеюсь использовать на одной из виртуальных машин Perl6. Только интересно, если вы хотите использовать LTM.

Все проверено по сравнению с данными Фейтсма. Я уверен, что есть и другие реализации. У FLINT есть вариант, который работает довольно быстро, но на самом деле это не BPSW (но он был проверен для чисел до 2^64).

person DanaJ    schedule 24.11.2014
comment
Я бы с осторожностью относился к использованию mpz_nextprime() при использовании MPIR 2.6.x вместо GMP. Разработчики MPIR изменили mpz_nextprime(), чтобы он пробовал только 2 (!) базы. Они предполагают, что вы будете использовать mpz_isprime() для результата mpz_nextprime(). - person casevh; 25.11.2014
comment
mpz_nextprime в MPIR по-прежнему делает 25 баз, хотя помечен как устаревший и исчезнет в будущих версиях. (как и вызов GMP-API mpz_probab_prime_p). Новый вызов mpz_next_prime_candidate делает только 2. Я не вижу никаких упоминаний о mpz_isprime() ни в документации, ни в исходном дереве. - person DanaJ; 25.11.2014
comment
Поведение mpz_nextprime() было изменено. В копии 2.6.0, которая у меня есть, mpz_nextprime() просто вызывает mpz_next_likely_prime(), которая выполняет только 2 раунда MR. Это было исправлено в 2.7.0. mpz_nextprime() был изменен, чтобы вызывать mpz_next_likely_prime(), а затем вызывать miller-rabin еще 23 раза. Ссылка на mpz_isprime() была ошибкой; это должно быть mpz_probable_prime_p(). - person casevh; 25.11.2014
comment
Интересно. Я смотрел на 2.7.0. - person DanaJ; 25.11.2014
comment
Спасибо @DanaJ за очень информативную статью, а также за обнаружение ошибок, связанных с праймом, во FLINT и других важных системах; также спасибо @ casevh. Я хотел бы напомнить другим читателям, что такие функции, как isprime(), nextprime() и т. д., страдали от ошибочных реализаций во многих основных системах — средах выполнения Java/js, MPIR, FLINT, gp/PARI и т. д.; даже сейчас наборы тестов содержат только поверхностные проверки кода теста на простоту. Это означает, что априорное доверие к ним для целей проверки другого программного обеспечения довольно низкое, даже если они поставляются в виде предварительно скомпилированных двоичных файлов (что делают лишь немногие). - person DarthGizka; 26.11.2014
comment
Кроме того, есть разница между поиском ошибок и проверкой. Для охоты на жуков практически все подходит; гибкость и превосходная пропускная способность важнее многих других соображений. Верификация бывает разной. Доверие не может быть сгенерировано из ничего, а только передано, и оно прикрепляется только к самому проверенному бинарному файлу, поскольку компиляторы и системы сборки могут сломать даже правильный исходный код и статически скомпилированные библиотеки. То же самое для Миллера-Рабина, BPSW и так далее; доверие применяется только к наборам баз, проверенных до заданных пределов. 46 случайных баз — это перебор, но все же вероятностный, а не детерминированный. - person DarthGizka; 26.11.2014
comment
SymPy использует первые 46 простых оснований (а Perl6 в настоящее время использует первые 100), поэтому он является детерминированным и корректным для значений меньше 2^64. Это детерминированная, но неизвестная правильность для больших значений (для произвольных входных данных мы можем принять границу ошибки, но для состязательных ситуаций она либо верна, либо нет). Известны контрпримеры реализации SymPy и Perl6. - person DanaJ; 27.11.2014

В общем, нужно использовать менее наивные методы, чем пробное деление, или быть очень терпеливым. (документация gp/PARI)

Для 64-битных целых чисел пробное деление занимает в миллионы раз больше времени, чем даже простое решето, не говоря уже о чистокровных, таких как программа Кима Валиша (primesieve .org), что на несколько порядков быстрее.

Эталонное сито, которое я хочу проверить (есть автономный .cpp @ pastebin), находит около миллиона простых чисел в секунду, когда просеивание близко к 2 ^ 64, тогда как пробный код деления, который я поднял из реализации gmp, занимает 20 секунд, чтобы найти хотя бы одно. Ограничение пробного деления предварительными простыми числами (хранящимися в виде дельт с одним байтом на простое число для быстрой итерации) ускоряет его на порядок, но на моем ноутбуке по-прежнему выводится менее одного простого числа в секунду.

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

Более сложные тесты, такие как Миллера-Рабина или Baillie-PSW, связанный пользователем 448810, на несколько порядков быстрее, чем пробное деление. Было подтверждено, что для чисел до 2 ^ 64 метод Baillie-PSW является детерминированным (нет сильных псевдопростых чисел ниже этого порога). Критерий Миллера-Рабина может быть или не быть детерминированным вплоть до 2^64, если в качестве основания используются первые 12 простых чисел, или набор из 7 оснований, найденный Джимом Синкларом (имеется в виду, что «сеть предлагает утверждения на этот счет, но, по-видимому, никаких доказательств).

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

На странице Baillie-PSW Томаса Найсли есть исходный код, использующий gmp и gp /PARI может использовать либо gmp, либо собственный код. Последний также доступен в виде бинарного файла, что очень удобно, поскольку сборка gmp-кода на экзотической, необычной платформе, такой как MinGW, под Windows является нетривиальной задачей, даже если MPIR используется вместо gmp.

Это дает нам некоторые объемные данные, но все еще недостаточно для проверки сита, поскольку оно на порядки слишком медленно даже для покрытия пустой области, оставленной шапкой Primesieve.org (10 * 2 ^ 32 числа).

Вот тут-то и появляется идея bigint Уилла Несса. Работу сита можно проверить до 1 000 000 000 000, используя справочные данные из нескольких независимых источников. Переключение переменных индекса с 32-разрядных на 64-разрядные устраняет большинство граничных случаев, которые могут привести к ошибкам в коде в более высоких областях, оставляя лишь очень мало мест, где даже uint64_t приближается к своим пределам. После того, как эти места были тщательно проверены и щедро покрыты тестовыми примерами, полученными в результате проекта Baillie-PSW, мы можем иметь достаточно высокую уверенность в том, что просеивающий код хорош. Добавьте обстоятельную проверку на Primesieve.org в диапазоне от 10^12 до его предела, и этого должно быть достаточно, чтобы считать реализацию sieve заслуживающей доверия.

Когда сито запущено и работает, можно легко покрыть произвольные диапазоны объемными данными. Или с помощью дайджестов в качестве готовых/сжатых средств проверки которые могут удовлетворить потребности любого размера и формы. Это то, что я использую в демо .cpp, о котором я упоминал ранее, хотя мой реальный код использует смесь оптимизированного дайджеста реализация для общей работы и специальная 128-битная контрольная сумма необработанной памяти для быстрой самопроверки растровых изображений факторного сита.

ОБЗОР

  • до 1 000 000 000 000 проверок на primos.mat.br или аналогичном
  • до 2^64 - 10 * 2^32 проверки на primesieve.org
  • остальное до 2^64-1: проверка стратегически выбранных сегментов с использованием Baillie-PSW (например, gp/PARI )
person DarthGizka    schedule 11.11.2014
comment
BPSW был проверен на 2 ^ 64, как и решение MR с 7 основаниями и решение MR с хэшированием с 3 основаниями, с использованием тех же методов проверки. Для вашего сита вы можете использовать Pari/GP или теорию Perl n, чтобы сгенерировать свой кусок простых чисел либо с простыми числами (a, b), либо с простыми числами. Они производят идентичные контрольные суммы для диапазона 100M ниже 2^64, при этом Pari/GP работает со скоростью около 2M/с, а ntheory — со скоростью 13M/с. Оба они также работают с диапазонами, охватывающими 2^64. Выполнение контрольных сумм для диапазона должно быть довольно простым как с Pari/GP, так и с Perl/ntheory. - person DanaJ; 15.11.2014