Симметричные кортежи из последовательных простых чисел

[Dmitriy40]

Тоже поясню остальным.

Yadryara в сообщении #1662067 писал(а):

А если ожидаем 7.4 штуки, то найдутся 0-15 кортежей.

Это совсем грубо, для тех кто не понимает зачем нужны сигмы и вероятности в зависимости от них. Но в общем да, именно так.
И когда мы говорим что в 71# ожидается 11 кортежей, это значит что могут найтись и 25 и ни одного. Маловероятно, но возможно.
Как пример, в SPT-боинк три 19-ки нашлись буквально кучей, повезло, а потом почти столько же времени (интервалов) больше нет ни одной. Так что распределение кортежей сильно не равномерное, по крайней мере пока их не сотни и тысячи (а лучше да, миллионы).

Yadryara в сообщении #1662067 писал(а):

Тут же ещё одна задача как была так и остаётся: не просто найти 19-252, а найти минимальную. Скучно, но придётся считать все группы.

Пока Демис так хорошо помогает проще действительно просто досчитать кусок.
Если вообще ставить и решать эту задачу.
Если считать окажется долго, то можно будет переделать разбиение на 61# (или даже 59#) и идти мелкими шажками по 61# (59#) до обнаруженной, ну конечно если она не окажется почти в конце куска 67#.

[Dmitriy40]

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

[Yadryara]

Dmitriy40 в сообщении #1662029 писал(а):

Распределить юниты между нами предлагаю так:
группы G19,G20,G21, 800 из G22 Антону, 4+120+1132+800=2056 юнита, на 5 дней;

Против самых чистых групп я конечно не возражаю.

Dmitriy40 в сообщении #1662029 писал(а):

Для сокращения размеров логов цепочки с valids<15 выводить в лог не буду, они не интересны.

Длина, я так понимаю, будет прежняя — 17? А может стоит её уменьшить до 15? Или выводить только чистые короткие, то есть 15/15 и 16/16, ну и 17+/17+. Их ведь тоже не будет сильно много. Тем более ведь повыше забираемся в горы.

[Dmitriy40]

Yadryara в сообщении #1662159 писал(а):

Длина, я так понимаю, будет прежняя — 17? А может стоит её уменьшить до 15?

Так и сделано, выводятся len от 15, ведь бывают комбинации len=15, valids=15. Увеличивать длину до 17 теперь нет нужды, и так в среднем по одной цепочке на юнит, valids>14 хорошо фильтрует, цель же была уменьшить размер логов, ограничение на valids её решает, ну и valids важнее длины.
Цепочки в логах нужны не (только) для статистики, а для немного более корректного распознавания какой юнит действительно посчитан до конца, а какой сглючил. Пока это не реализовано, да собственно и не нужно было, столь страшных ошибок (когда портятся исключительно цепочки, оставляя служебные поля корректными) не было, но по мере свободного времени доделаю нормальный контроль.


На основном компе у меня счёт 71# пошёл, 8 юнитов в конце G22 посчитано, в среднем чуть быстрее 11 минут на юнит (всего 4 потока ж), допроверка в PARI и вывод лога занимает две секунды.
На сервере счёт 12ххх закончится к ночи, тоже запущу 71# (ту же G22).
Запустил, по 1м55с на юнит, даже чуть быстрее расчётных 2м.
Да, можете считать пользуюсь "правом первой ночи" и кидать тапки.

[Yadryara]

Dmitriy40 в сообщении #1662172 писал(а):

Так и сделано, выводятся len от 15, ведь бывают комбинации len=15, valids=15.

Вот и хорошо. Потому что когда я считал стату для нынешнего счёта, было некомфортно, что 16/17 есть, а 16/16 нету. Иными словами старый счёт был

0+/17+, а новый будет 15+/15+.

[Yadryara]

Dmitriy40 в сообщении #1662172 писал(а):

На основном компе у меня счёт 71# пошёл,

А точно это счёт по 71# пошёл ? То есть кэф фильтрации увеличен в 1.365 раза? Мы же вроде договорились, что будем считать 2-й период 67# с прежним кэфом фильтрации. А вот разбиение другое, да.

[Yadryara]

Табличка для паттерна 19-252:

Prime  RazrOst            Kandidatov          KoefFilt

    2        1                     1              2
    3        2                     2              3
    5        2                     4              7.5
    7        2                     8             26.25
   11        2                    16            144.37
   13        2                    32            938.44
   17        2                    64           7976.7
   19        6                   384          25259
   23        6                  2304          96829
   29       12                 27648         234002
   31       12                331776         604506
   37       20               6635520        1118336
   41       24             159252480        1910490
   43       24            3822059520        3422961
   47       28          107017666560        5745685
   53       34         3638600663040        8956509
   59       40       145544026521600       13210850
   61       42      6112849113907200       19187187
   67       48    293416757467545600       26782116
   71       52  15257671388312371200       36567889

То есть в новом поиске по-прежнему проверяются 293 квадрика с кэфом 26 миллионов, а вовсе не 15257 квадриков с кэфом 36 миллионов, как первоначально предполагалось?

Тогда это поиск во втором периоде 67#, а не поиск в первом периоде 71#.

Кстати, интересно увидеть стату по новому поиску.

[Dmitriy40]

Yadryara в сообщении #1662225 писал(а):

А точно это счёт по 71# пошёл ? То есть кэф фильтрации увеличен в 1.365 раза? Мы же вроде договорились, что будем считать 2-й период 67# с прежним кэфом фильтрации. А вот разбиение другое, да.

Счёт пошёл по второму куску (периоду) 67# внутри 71#, который дальше первого, что досчитывается. Новой программой с новым разбиением.

Yadryara в сообщении #1662230 писал(а):

То есть в новом поиске по-прежнему проверяются 293 квадрика с кэфом 26 миллионов, а вовсе не 15257 квадриков с кэфом 36 миллионов, как первоначально предполагалось?
Тогда это поиск во втором периоде 67#, а не поиск в первом периоде 71#.

Да.

Yadryara в сообщении #1662230 писал(а):

Кстати, интересно увидеть стату по новому поиску.

Рановато, посчитано всего полтыщи юнитов, найдено всего 5шт valids=17 (и те же примерно полтыщи штук с меньшим).