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

[Dmitriy40]

Интересное наблюдение по поводу вероятных и невероятных событий.
Как известно Врублёвским была найдена КПППЧ18 с минимальным диаметром 82, НМ её проверила и оказалось она расширяется до КПППЧ20 тоже с минимальным диаметром 94, а теперь внимание: мат.ожидание КПППЧ20d94 в диапазоне 0-8.25e23 (в конце которого и была найдена) по HL1 составляет $0.02\pm0.14k$, что даёт вероятность её обнаружения в данном диапазоне хуже 7 сигм или менее $1.3\cdot10^{-12}$! Почти одна десятимиллиардная процента! И вот такая ничтожная вероятность реализовалась ...

Кстати на подтверждение их минимальности мне потребуется около 8 (на 18-у) и 25 (на 20-у, их 6 паттернов) дней, вот это пожалуй неплохая задача после 19-252.
На подтверждение минимальности КПППЧ17d240 (любой, наименьшая была найдена Врублёвским по паттерну 17-240-3), нужно часов 10-12 счёта, программу дольше править.
Можно будет наверное и КПППЧ22d106 (с минимальным диаметром, их три паттерна) поискать ... И КПППЧ24d118 (с минимальным диаметром, два паттерна) до кучи ...

[Dmitriy40]

Демису снова везёт, нашёл очередную 17-240-1 (центральную из 19-252) в группе G24:
14451615724941305041645441: [ +0, 6, 12, 30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210, 222, 240, 246, 252], len=18, valids=18
Она же в другом формате:
14451615724941305041645441: [-68, 6, 12, 30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210, 222, 240, 246, 252], valids=18
Всего одно отличие от 19-252 и на самом краю!

Впрочем и мне немного повезло, в группе G23 тоже попалась 17-240-1:
9701757886114895320879541: [ +0, -2, 6, 12, 30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210, 222, 240, 246,+252], len=18, valids=17
Она же в другом формате:
9701757886114895320879541: [2, 6, 12, 30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210, 222, 240, 246, 272], valids=17

[Dmitriy40]

Насчёт методов ускорения программ. Поделюсь ещё одним нетривиальным. Я его применил при расчётах для Hugo и в поисках разных пентадекатлонов (точнее похожих на него цепочек).
Метод ограничен случаем проверки многих чисел (числа кортежа) на некоторое составное условие (например простоту или любое другое достаточно сложное). Для одного-двух чисел и простых условий эффекта не даёт. Применение к последней исходной программе НМ со случайным поиском (другие отличаются непринципиально) даёт около 10% ускорения, да, мало, зато простой в реализации.

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

Пример для проверок кортежей. Обычно (для повышения скорости) выполняется сначала быстрая проверка ispseudoprime на пару-тройку чисел кортежа и лишь если они все её проходят, выполняется полная проверка всего кортежа. Но известно что ispseudoprime выполняет два теста (как составные части BPSW), первый Ферма, второй Люка, причём я бы сказал второй сложнее и медленнее. Потому можно ограничиться лишь тестом Ферма для всех 2-3 чисел и лишь если они все прошли - выполнять точную проверку кортежа (обязательно включая и недопроверенные 2-3 числа). Это реализуется указанием второго параметра 1 в ispseudoprime. К сожалению для неё нельзя указать основание для теста Ферма, только их количество, но даже и так указание одной проверки тестом Ферма с произвольным основанием очень хорошо отфильтровывает составные числа и в то же время быстрее полной проверки обоими тестами.
При этом вся модификация кода сводится к замене строки типа
if(!ispseudoprime(x+0) || !ispseudoprime(x+6), next);
на строку
if(!ispseudoprime(x+0,1) || !ispseudoprime(x+6,1), next);
с добавленными вторыми параметрами функций, всего лишь.
Надо только не забыть что эти числа могут оказаться таки составными (псевдопростыми) и их надо будет ниже тоже допроверить.
В данном случае ускорение невелико, 10%, но метод универсальный, не только для проверки простоты чисел в кортеже.
И особенно эффективен если какие-то проверки (не обязательно первые) в составе полной можно выполнить существенно быстрее полной.

-- 09.12.2024, 22:53 --

Идею метода можно выразить и совсем коротко: проверим всё множество чисел (разумеется до первого нарушения) по быстрому и не слишком точно/аккуратно, быстро отбросим большинство неподходящих вариантов, с малой долей оставшихся будем разбираться подробнее. Размен точности/аккуратности на скорость.

[Yadryara]

$\tikz[scale=.1]{ \fill[black] (0,0) rectangle (0.2,0.2); \fill[black] (1,0) rectangle (2.1,1.1); \fill (3,0) rectangle (6.4,3.4); \fill (7,0) rectangle (14.3,7.3); \fill (15,0) rectangle (28.1,13.1); \fill (29,0) rectangle (47.7,18.7); \fill (49,0) rectangle (71.9,22.9); \fill (73,0) rectangle (95.85,22.85); \fill (97,0) rectangle (115.8,18.8); \fill (117,0) rectangle (129.9,12.9); \fill (131,0) rectangle (137.9,6.9); \fill (139,0) rectangle (141.5,2.5); \node at (10.65,3.65)[white]{\textbf{22}}; \node at (21.55,6.55)[scale=2,white]{\textbf{23}}; \node at (38.35,9.35)[scale=3,white]{\textbf{24}}; \node at (60.45,11.45)[scale=4,white]{\textbf{25}}; \node at (84.425,11.425)[scale=4,white]{\textbf{26}}; \node at (106.4,9.4)[scale=3,white]{\textbf{27}}; \node at (123.45,6.45)[scale=2,white]{\textbf{28}}; \node at (134.45,3.45)[white]{\textbf{29}}; } $

Сравнительные размеры групп нынешнего разбиения. Площади квадратов пропорциональны количеству юнитов. Слева крохотульная 19-я группа. Ещё надо присмотреться чтоб её увидеть — она в 13 тысяч раз меньше чем самые большие. А 20-я — примерно в 440 раз меньше чем 25-я.

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

Насчёт методов ускорения программ. Поделюсь ещё одним нетривиальным.

Благодарю, не знал что у этой псевды ещё и параметры есть.

[Dmitriy40]

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

Сравнительные размеры групп нынешнего разбиения.

Красиво и наглядно!

[Yadryara]

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

Прогноз: 11-ю группу уже никому не обогнать. И она так и останется единственной с трёхзначным показателем после обсчёта всего 2-го периода 67#.

Не сбылся. В хорошем смысле! То есть 11-ю группу обогнала не более грязная 12-я или 13-я, её обогнала 10-я, до этого сидевшая с нулём. Вот стата, полученная пересчётом с нынешних групп с 19-й по 24-ю.

1*67#   15/15   tuplets*10^15/unit  G19-24
                                                                                    
Units(10^13)  0.2    2   12   62  243  745 1781 3349 4960 5782 5286 3770 2085
Group         G10  G11  G12  G13  G14  G15  G16  G17  G18  G19  G20  G21  G22
Tuplets
2497 abs        1    3   10   42  154  255  459  537  479  349  162   40    6

              523  172   84   68   63   34   26   16   10    6    3    1    0

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

И пришлось дробный показатель указать для 10-й группы, в которой всего-то меньше 2-х триллионов вариантов.

Табличка по всем группам отличается от этой только правой частью. Различия начинаются лишь с 16-й группы.

[Dmitriy40]

15ч назад закончили считать 23 группу, статистика найденного в ней:

G23     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  len=23  len=24  average
v15:    1133    2875    3483    2564    1411    562     161     46      7       1       17.23311279915053499959160337
v16:            168     390     489     375     185     63      30      6       1       18.21323960164030462800234329
v17:                    17      43      44      36      19      5               1       19.10303030303030303030303030
v18:                                    2       1       2                               20.00000000000000000000000000

[Yadryara]

Проверил по другой программе стату по G23. Совпала. А вот более полная суммарная по 2-му периоду 67#:

len=          15    16    17    18    19        20   21   22  23 24 25
valids=15   2927  7460  9163  6828  3845      1516  485  126  33  2  1     32386
valids=16          426  1096  1238   971       537  208   72  22  3  1      4574
valids=17                 37    99   119       114   39   21   4  2          435
valids=18                        2     6        12    8    3   1              32
valids=19                                                                      0
________________________________________________________________________________
                                                                           37427

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

Про valids Вы уже скатываетесь в специфичную терминологию, человеку со стороны совершенно не очевидно что найти valids=19 намного труднее чем valids=11. Всего менее чем вдвое больше, делов то, "наверняка же хватит не 2-3 дня, а недели, ну двух".

Ну вот как раз глянем на табличку выше. Итоговый крайне правый столбец. Видно же что цепочек для каждого следующего valids в разы меньше. Причём разы эти увеличиваются: в 7 раз, в 10 раз, в 13 раз...

Допустим находится цепочка с valids=11 раз в сутки. Для простоты допустим также, что уменьшение всё время в 5 раз. Значит для нахождения valids=19 надо в среднем $5^8$ суток. Или тысячу лет.

Люди не такие дураки. Ничего сложного тут нет. А если кому всё-таки непонятно, спросите.

[Dmitriy40]

5 раз на единицу длины маловато, давно ведь прикидывали что реально выходит больше 100 раз на две единицы длины, это больше 10 раз на одну единицу. Во всяком случае для чистых цепочек, не просто valids.
Именно так ведь и оценивал два года назад что 19-252 должна бы найтись чуть далее $10^{23}$ потому что 17-240 нашлась почти точно на $10^{21}$, а 15-228 около $2\cdot10^{18}$, а 13-192 около $2.5\cdot10^{15}$, а 11-168 около $10^{13}$, видите, разница между 17-240 и 11-168 почти ровно 8 порядков или $10^{8/6}=21.5$ раз на единицу длины, и 19-252 ожидалась в $21.5^2=464$ раза дальше 17-240 или около $4.6\cdot10^{23}$ (плюс/минус разброс в пару-тройку раз). Именно такую оценку я где-то выше назвал первым более-менее приличным прогнозом.

-- 13.12.2024, 18:59 --

Досчитал две самые чистые группы для первых 10 периодов 67# (первые два были показаны раньше):

Используется синтаксис Text

2*67#:
G19     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:            1       1       1                                       17.00000000000000000000000000
G20     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:    8       21      21      21      5       2       1       1       17.11250000000000000000000000
v16:            2       4       2       2                               17.40000000000000000000000000
v17:                            1                                       18.00000000000000000000000000
3*67#:
G19     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:                            1       1                               18.50000000000000000000000000
G20     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:    7       11      22      6       4       2                       16.90384615384615384615384615
v16:            2       3       3       3                               17.63636363636363636363636364
4*67#:
G19     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:            1                                                       16.00000000000000000000000000
G20     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:    3       17      12      16      1       3                       17.07692307692307692307692308
v16:                    1       1       3       2                       18.85714285714285714285714286
v17:                                                    1               21.00000000000000000000000000
5*67#:
G19     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:            1                                                       16.00000000000000000000000000
v16:                                    1                               19.00000000000000000000000000
G20     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:    7       23      23      9       5       1                       16.77941176470588235294117647
v16:            1       3       2       2                               17.62500000000000000000000000
6*67#:
G19     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:    1               1                                               16.00000000000000000000000000
G20     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:    14      8       15      7       3                               16.51063829787234042553191489
v16:            3       1       3       1                               17.25000000000000000000000000
v17:                            1                                       18.00000000000000000000000000
7*67#:
G19     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:    1       1                                                       15.50000000000000000000000000
G20     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:    13      27      11      8       4                               16.41269841269841269841269841
v16:            5       2       2               1                       17.00000000000000000000000000
v17:                                            1       1               20.50000000000000000000000000
8*67#:
G19     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:                    1       1                                       17.50000000000000000000000000
G20     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:    9       11      15      12      4                               16.82352941176470588235294118
v16:            1       2       3                                       17.33333333333333333333333333
9*67#:
G19     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:                            1               1                       19.00000000000000000000000000
G20     len=15  len=16  len=17  len=18  len=19  len=20  len=21  len=22  average
v15:    6       18      15      7       4       1       1               16.84615384615384615384615385
v16:            1       2       4               2                       18.00000000000000000000000000
v17:                            1                                       18.00000000000000000000000000

Понятно что ничего интересного не нашлось, слишком маленькие группы.
Покажу найденные valids=17, все в 20 группе:
20217087456772847004793811: [ 0, 6, 12, 30, 42, -68, 72, 90, 96, 120, 126, 132,+156, 162, 180, 210,+222, 240, 246, 252], len=18, valids=17
36890750805686245182869521: [ 0, +6, 12, -28, 30, 42, -52, 72, -78, +90, 96, 120, 126, 132, 156, 162, 180, 210,-220, 222, 240, 246, 252], len=21, valids=17
52510529172052943045223551: [ 0, +6, 12, 30, 42, 72, 90, -92, 96, 120, 126, 132, 156, 162,+180, 210, 222, 240, 246, 252], len=18, valids=17
57594733512289100810838977: [ 0, 6, 12, -24, -26, 30, 42, +72, 90, 96, 120,+126, 132,-134, 156, 162, 180, 210, 222,-224, 240, 246, 252], len=21, valids=17
58750144848412373000759041: [ 0, 6, 12, 30, -36, 42, -58, 72, 90, 96, 120, 126, 132, 156, 162, 180,-202, 210,+222, 240,+246, 252], len=20, valids=17
76462270062495348298127227: [ 0, 6, 12, 30, +42, 72, 90, 96,-112, 120, 126, 132, 156, 162,+180, 210, 222, 240, 246, 252], len=18, valids=17

[Yadryara]

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

5 раз на единицу длины маловато

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

Ну что же, теперь посчитаю 426 цепочек 16/16:

1*67#   16/16   tuplets*10^16/unit  G19-30
                                                                                    
Units(10^13)   2   12   62  243  745 1781 3349 4960 5782 5286 3770 2085  888  290   72
Group        G11  G12  G13  G14  G15  G16  G17  G18  G19  G20  G21  G22  G23  G24  G25
Tuplets
426 abs        1    1    9   19   52   82   91   83   48   24   12    1    2    0    1

             572   84  146   78   70   46   27   17    8    5    3    0    2    0   14

Здесь не так красиво чистый край задирается, как с 15/15. Потому что недобор в 12-й группе. Снова пожалел, что мы в первом периоде 67# не считали 16/16. Если посчитать, может ситуация выправится. А так уже вряд ли. Разве что на других периодах 67#.

-- 13.12.2024, 19:11 --

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

Понятно что ничего интересного не нашлось,

А, отлично что досчитали. А вот мы как раз и посмотрим нашлось интересное или нет. Я имею в виду как раз 16/16. Покажите пожалуйста все цепочки для периодов 3-10.

[Yadryara]

Спасибо, посмотрел. Хотя в 12-й группе ни одной 16/16 и не нашлось, в остальном статистика отличная, особенно по 15-кам:

2-9 *67#   15/15   tuplets*10^16/unit  G19-20

Units(10^13)    2   12   62  243  745 1781 3349 4960 5782
Group         G11  G12  G13  G14  G15  G16  G17  G18  G19
Tuplets
69 abs          2    5    8   19   15   13    4    2    1 

             1144  419  130   78   20    7    1    0    0



2-9 *67#   16/16   tuplets*10^16/unit  G19-20

Units(10^13)    2   12   62  243  745 1781 3349 4960 5782
Group         G11  G12  G13  G14  G15  G16  G17  G18  G19
Tuplets
15 abs                    3    4    5    2    0    1

                         49   16    7    1    0    0

Теперь осталось понять, почему же мы не можем быстро перебирать по этому разбиению. Буду обстоятельно Вас расспрашивать.

[Dmitriy40]

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

Теперь осталось понять, почему же мы не можем быстро перебирать по этому разбиению. Буду обстоятельно Вас расспрашивать.

Так ведь уже говорил: кроме самой проверки кандидата есть ещё дополнительные действия по вычислению кандидата (начального числа, остатков по простым), которые часто можно сделать "оптом", сразу для многих кандидатов, что повышает скорость. И разумеется хотелось чтобы эти дополнительные расходы были поменьше (в процентном соотношении). А это требует увеличения размера "опта". Можно возить каждую бутылку воды пятитонным грузовиком, но эффективнее загрузить в него сразу 5т бутылок и перевезти за раз, особенно если не на соседнюю улицу. Заметьте, время загрузки-выгрузки тоже растёт, но обычно медленнее чем время в дороге, потому "опт" выгоднее.
А так да, можно каждый кандидат получать по полной КТО (chinese) по всем остаткам и потом его проверять. Только это долго, лучше сразу сформировать "опт" в виде таблицы 37# (или лучше побольше) и исключить медленную операцию КТО из самого внутреннего цикла перебора кандидатов. А для уменьшения накладных расходов количество итераций этого цикла надо делать побольше. Принятые у меня 10-20 тысяч - маловато, лучше бы больше на порядок, но тут упираемся в ограничения аппаратуры, большие размеры считаются заметно медленнее (даже однопоточно, а многопоточно медленнее в квадрате).
Впрочем расспрашивайте, вдруг появится ещё идея ускорения счёта.

[Yadryara]

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

Впрочем расспрашивайте, вдруг появится ещё идея ускорения счёта.

У меня ещё есть такая довольно смутная идея. Делать подготовительную работу не на одном компе, а на нескольких. Скажем, если не хватает оперативки, как-то разделить...

Именно что смутная. Я перечитывал старые посты. Примерно запомнил про матрицу за 300млн — $11520\times 3400$. Ещё периодически возвращаюсь к старой идее об использовании симметрии и чтоб плясать не от начального числа кортежа, а от центрального.

[Dmitriy40]

Yadryara
Вместо матрицы 11520х3491 (это для программы в нулевом периоде, сейчас разбиение 17280х3491) можно оставить матрицу 11520х99, но скорость падает в 1.5 раза примерно.
Кстати, в этой матрицы только левые 35 столбцов (из 3491) занимают по байту, все остальные 3491-35=3456 столбцов занимают по два байта.
А число 3491 выбрано как все простые до $2^{15}$ за вычетом простых до $2^8$ и усечённое на блок из 16 штук - для проверки делимости на AVX2.
Проверка по простым $2^{15}\ldots2^{17}$ матрицы не требует, выполняется медленными делениями начального числа, на скорость оно уже практически не влияет.

Оперативки как раз хватает за глаза (даже с такой большой матрицей программе хватает примерно 80-100МБ памяти), не хватает размера кэша L2 процессора. Ну или скорости (не размера!) кэша L3, особенно в многопоточном режиме.

В идеале конечно лучше бы иметь все эти 293.4e15 чисел по 11-16 байтов каждое, причём сразу в форме той самой матрицы 293e15х3491. Но это простите 2e21 байтов или 2 миллиарда терабайт! На каждый период 67#. Столько ни хранить негде, ни передать по сетям, ни даже просто считать с диска (даже SSD). И гораздо проще вычислить. Вот смотрите, мой старый 4-х ядерный комп вычисляет 2e9 строк этой матрицы в секунду, это примерно 2e9*3500*2=1.4e13 байтов в секунду надо читать откуда-то или 14ТБ/с. Даже не гигабайт. Где Вы видели такие скорости дешевле миллионов долларов?! А вычислить удаётся на компе за 10000р если не меньше.
На самом деле меньше, всю матрицу никогда читать не надо, надо лишь 12 левых столбцов плюс 1/16 часть следующих 23 столбцов, плюс 1/197 следующих 16 столбцов, плюс ещё совсем мелочь дальше. Суммарно на моём компе выходит 14 байтов на 5e8 итераций/с в одном потоке на 4 потока = 28ГБ/с. Что кстати уже чуть выше скорости моей памяти 25ГБ/с. Но и это далеко за пределами скоростей и сетей и дисков.
А у Вас все цифры скорости умножайте на три, до 84ГБ/с.

И ещё про "опт". Под ним ведь подразумеваются не только подготовительные действия, но и то что одной командой обрабатываются сразу 32 числа из матрицы. Не одно! Это для левых 35 столбцов, что по байту, для остальных обрабатываются сразу по 16 чисел/ячеек (по два байта). За счёт этого первая проверка, на простые до $2^7$, это левые 12 столбцов матрицы, занимает всего 48 тактов на все 32 числа, или 1.5 такта на строку (кандидата), и это на 12 итераций, т.е. 8 чисел за один такт. А ведь проверка состоит из более десятка команд, но они все укладываются в 4 такта и более того, за эти 4 такта проверяют сразу 32 числа.

-- 14.12.2024, 18:00 --

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

Как сюда прикрутить симметрию начальных (или конечных или центральных, без разницы) чисел я не понимаю, ведь они будут иметь разные остатки по малым простым, а только они и нужны, во всяком случае для проверок по простым до $2^{15}$, что занимает 99% времени. Да, вероятно остатки по малым простым тоже будут как-то симметричны, но по каждому по своему и вычислить их не делая операций вычитания (по модулям простых!) не получится. А это не быстрее и так применяемого сложения по модулю. Не вижу заметного выигрыша в скорости (удвоение размера 11520 сильно скорости не добавляет).

[Yadryara]

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

это для программы в нулевом периоде

Кстати, мне не нравится эта путаница. Называть период нулевым только из-за того, что имеется множитель 0 при 67# ? Но зачем? Это же неестественно. Вот сейчас идёт 21-й век. Мы же не называем его 20-м, хотя все его годы кроме одного начинаются с 20. И про нулевой век тоже не говорят, а говорят про первый. И нулевых этажей у нас нет. И хоккейный матч начинается с первого периода, а не с нулевого. И в первый раз в первый класс мы идём. А какой период 67# будет последним в периоде 71# ? 71-й же, а не 70-й.

Кстати, если кому-то непонятно. Я говорил, что в периоде $0-67\#$ полным-полно кортежей 17-240-1, порядка 2-х сотен. Неужто не очевидно, что в периоде $0-71\#$ их гораздо больше, порядка 3-х тысяч. И уже 10 из них известны.