кортежи последовательных простых. ключ к 19-252

[Yadryara]

На всякий случай. Просто люди часто не признаются что им не всё понятно.

Вопрос: какой код чаще встречается 101 или 111? Иными словами, среднее число n кортежа 0, b, 12 чаще симметрично (стоит строго в центре, b=6) или смещено к одному из краёв (b<>6)?

Ответ: чаще смещено, стало быть код 101 встречается чаще.

Вопрос: а насколько чаще встречается код 101?

gp > (vecsum(cc)-cc[3])/cc[3]*1.0

= 2.50000

Ответ: в среднем в 2.5 раза чаще чем код 111.

Вопрос: а на практике это проверено?

gp > (vecsum(c)-c[3])/c[3]*1.0

= 2.57177

Ответ: в данном случае кортежей с таким кодом нашлось в 2.57 раза больше.

[Yadryara]

До чего дошёл прогресс: не могу даже процитировать собственный пост с предыдущей страницы.

Вроде нет специальной темы посвящённой спектру центральной 15-ки, но список из 152-х не найденных кодов нашёл.

Посмотрел подробнее: аж целых 4 кода с valids=10.

Number                  Binary code                Valids   Decimal code
     6    [0, 1, 1, 0, 1, 1, 0, 1, 1, 0, 1, 1, 0]      10           3510
    11    [0, 1, 1, 1, 0, 0, 1, 0, 0, 1, 1, 1, 1]      10           3663
    13    [0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 1, 1, 0]      10           3758
    70    [1, 1, 1, 0, 0, 1, 0, 1, 1, 0, 1, 1, 0]      10           7350

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

[Dmitriy40]

Про какие коды речь?
Год назад мною были найдены и опубликованы:
689084518557829: [0, 4, 30, 60, 64, 84, 108, 118, 120, 144, 162, 168, 198, 220, 228], num13=3510, valids=10
494721977839153: [0, 10, 30, 60, 78, 100, 106, 114, 130, 148, 150, 168, 198, 210, 228], num13=3663, valids=10
165726599366491: [0, 10, 30, 60, 78, 106, 108, 118, 120, 148, 150, 168, 198, 226, 228], num13=3758, valids=10
1267717529628383: [0, 18, 30, 60, 96, 98, 108, 116, 120, 144, 164, 168, 198, 224, 228], num13=7350, valids=10
Эти коды найдены все, все 8192шт, причём все они - минимальные.
В том же марте были найдены и:
29457644031203: [0,26,48,50,66,84,110,114,120,134,150,156,188,204,216,224,240], num15=3510, valids=10
14687104186043: [0,24,56,60,66,84,90,98,116,126,146,158,174,204,216,234,240], num15=3663, valids=10
14450337614533: [0,58,60,64,66,84,90,108,120,148,150,160,174,204,216,226,240], num15=3758, valids=10
79720222199243: [0,20,30,36,66,84,96,98,120,134,150,156,170,204,216,218,240], num15=7350, valids=10
595383036948991: [0,12,30,48,70,88,90,96,100,126,132,142,162,180,186,222,240,250,252], num17=3510, valids=10
500681492491471: [0,16,18,22,40,58,90,96,120,130,142,156,172,208,210,222,240,246,252], num17=3663, valids=10

[Yadryara]

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

Про какие коды речь?

Вот здесь они.

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

Эти коды найдены все, все 8192шт,

И это было опубликовано? То есть этот спектр давным-давно заполнен полностью?

Ну вот, говорил же, что кое-кто невнимательно читает наш форум. И впс тут тоже не на высоте. То ли прозевал, то ли забыл.

[Dmitriy40]

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

И это было опубликовано? То есть этот спектр давным-давно заполнен полностью?

Да, 19.05.2024:

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

gris
Досчитал все 100% таблицы num13, положил в тот же архив в облаке что и остальные.

И тогда же выложены в облако https://cloud.mail.ru/public/cXJz/js19fzTi7 в архиве d252-num17.zip файл d252-num13.txt.

-- 04.07.2025, 23:19 --

А если Макарова хочет снова всё пересчитывать потому что не читает (или не понимает) что делают другие - это лично её проблемы. Предлагаю не вестись на её глупости.

[Yadryara]

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

А если Макарова хочет снова всё пересчитывать потому что не читает (или не понимает) что делают другие - это лично её проблемы. Предлагаю не вестись на её глупости.

Это очень правильное предложение.
Но... чтобы не вестись, тогда нужно самим быть в курсе. Вот я вроде в курсе и понимаю что num13 это на самом деле про 15-ки, а не про 13-ки, потому что gris, которому это адресовано, зафиксировал, то бишь обязал два крайних простых быть родными. Остальные 13 из 15 могут быть и чужими.

Да, от Вас было вот это сообщение, но адресовано оно было не мне, так что по ссылке я не ходил. Но сам gris-то тоже не ходил что ли? Мог бы написать, мол, да я проверил и дать внятное объявление: так называемый спектр приближений к центральной 15-ке заполнен полностью.

И получается что месяц за месяцем вводила в заблуждение своих читателей?? Сознательно это делалось или нет, тут по-любому надо публично извиняться.

И не выяснили это пока я не начал предметно разбираться, а как же так, почему даже коды c низкими валидс (всего лишь valids=10), которые и на PARI считаются весьма быстро, до сих пор не найдены?

Правильно понимаю, что Вы на PARI весь этот спектр заполнили?

[Dmitriy40]

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

Правильно понимаю, что Вы на PARI весь этот спектр заполнили?

Нет конечно:

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

Плюс полностью (т.е. 100% всех кодов!) посчитал все меньшие num11,9,7,5,3,1, буквально за день (c num7 и менее вообще прямо на PARI),

Num9 и длиннее считал начальную часть (до сколько-то e14, точной границы не сохранилось) своим генератором простых (решето Эратосфена) плюс фильтрация по новым кодам, остатки поиском по паттернам.

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

почему даже коды c низкими валидс (всего лишь valids=10), которые и на PARI считаются весьма быстро, до сих пор не найдены?

Valids тут не показатель, например не найдено более 160шт минимальных (а не абы каких!) кодов num15 с valids=10 и даже 5шт минимальных кодов num17 с valids=8 всего лишь!

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

Вот я вроде в курсе и понимаю что num13 это на самом деле про 15-ки, а не про 13-ки, потому что gris, которому это адресовано, зафиксировал, то бишь обязал два крайних простых быть родными. Остальные 13 из 15 могут быть и чужими.

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

[Yadryara]

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

Valids тут не показатель,

А вот я попробую с этим не согласиться и попробую поискать именно на PARI одно из 4-х приближений с valids=10, показанных выше. Возьму самое первое, оно единственное симметричное, красивое: пары единичек чётко обрамляются нулями по одному:

Number                  Binary code                Valids   Decimal code
     6    [0, 1, 1, 0, 1, 1, 0, 1, 1, 0, 1, 1, 0]      10           3510

Теперь распишу все возможные варианты паттернов для этого кода:

  0  18  30  60  78  84 108 114 120 144 150 168 198 210 228
      0   1   1   0   1   1   0   1   1   0   1   1   0
     13          10           4          10          13

Итого $13\cdot10\cdot4\cdot10\cdot13 = 67600$ потенциальных паттернов. И, забегая вперёд, скажу что допустимых из них намного меньше — $1930$.

Сначала считал для периода $47\#$, но потом всё-таки переключился пониже:

43#
min formul   3247695000
max formul  47210397696   47210397696 
                  17265         63398

17265   [0, 8, 30, 60, 68, 84, 108, 110, 120, 144, 164, 168, 198, 200, 228]

Видим что количество формул для разных паттернов ощутимо различается — в 14.5 раз.

Возьму один из двух паттернов для максимального количества формул, тот который под номером 17265 в общем списке, и попробую поискать по нему на периоде $0-43\#$.

[Dmitriy40]

Минимальное решение на 6.89e14, это 5% от 43# и 226% от 41# и 9286% от 37#. Очевидно выгоднее считать три периода 41# или 93 периода 37#, чем один 43#. А на PARI скорее всего выгоднее даже 3436 периода 31#. Потому что для 43# и 41# много времени будет занимать вычисление КТО, а по периодам можно идти линейно, что намного быстрее.

Плюс, паттерн длиной 10 имеет 1.666e12 формул в 43#, а все ваши 1930 паттернов имеют суммарно не менее 3247695000*1930=6.268e12 формул в 43#, минимум вчетверо больше. Т.е. если проверять их все, то выгоднее (в разы, а скорее на порядок-полтора) искать прямо нужный паттерн длиной 10, без этих вот извращений с загрязнениями. И ведь это я уже сколько раз проверял ...

Ну и оценим требуемое время. PARI проверяет все 60.3млн формул в 31# за 310с, примерно 200К формул в секунду (это уже с оптимизацией проверки кортежа), рекомендую запомнить эту цифру для любых будущих оценок (это скорость оптимизированной проверки формулы с КТО в PARI). Оценка времени для 3436 периодов 31# даёт величину 77ч (или 6.4ч в 12 ваших потоков), скорость вчетверо выше за счёт более редкого (в 3436 раз!) выполнения КТО, т.е. это скорость самой проверки кортежа, примерно 750К/с.
Проверять все 1930 паттернов ещё в разы медленнее ...

[Yadryara]

Я специально не смотрел, где найден кортеж 10\15 с этим кодом. Но уже конечно быстро понял, что надо снижать период.

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

Т.е. если проверять их все, то выгоднее (в разы, а скорее на порядок-полтора) искать прямо нужный паттерн длиной 10, без этих вот извращений с загрязнениями. И ведь это я уже сколько раз проверял ...

Да, я уже изрядно подзабыл как искать самостоятельно на PARI. Вроде с января не искал, с тех пор как нашёл кортеж для Evgeniy101, который он не мог найти.

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

[Yadryara]

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

Оценка времени для 3436 периодов 31# даёт величину 77ч (или 6.4ч в 12 ваших потоков), скорость вчетверо выше за счёт более редкого (в 3436 раз!) выполнения КТО,

Имеете в виду, что все добавки для 31# можно записать в память, а не на лету считать? А точно хватит памяти? И на несколько потоков? Или Map надо как-то применять?

Я пока не стал пробовать для 31#, а для 29# записал все добавки в память и время счёта в три раза уменьшилось. Оценил время счёта с нуля и до первого приближения — 89 часов в один поток.

Для убедительного подтверждения метода решил повыше поискать второе приближение с тем же кодом.

[Dmitriy40]

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

Имеете в виду, что все добавки для 31# можно записать в память, а не на лету считать? А точно хватит памяти? И на несколько потоков? Или Map надо как-то применять?

Нет, я взял доработанный код НМ (его было быстрее найти) с вычислением добавок на лету и потом перебором периодов.
Памяти хватит, 60млн добавок в 31# по 8 байт (в vectorsmall, не Map) это всего полгига памяти.
Поток один. 77ч вместо 300ч потому что перебор периодов это просто цикл со сложением, что намного быстрее КТО.
Map применять невыгодно, оно требует по 128 байтов на элемент вместо 32 у vector и 8 у vectorsmall.

[Yadryara]

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

Map применять невыгодно, оно требует по 128 байтов на элемент вместо 32 у vector и 8 у vectorsmall.

Вроде не знал этого. Да, 60328800 формул. Действительно, 256 МБ не хватило, а полгига хватило.

1-й период   3min, 24,213 ms  счёт + КТО
2-й период   4min, 24,394 ms  счёт
3-й период   5min, 24,596 ms  счёт
4-й период   6min, 24,643 ms  счёт

Ускорение в 3.4 раза: теперь чётко по минуте на период 31#. Очень удобно стало считать время: 58 часов счёта в один поток.

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

перебор периодов это просто цикл со сложением, что намного быстрее КТО.

Этого пока не догоняю. То есть можно ещё ускорить?

[Dmitriy40]

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

Этого пока не догоняю. То есть можно ещё ускорить?

Не думаю.
Кажется есть три разных варианта порядка вычислений (подразумеваю что цикл по периодам линейный, всё остальное в КТО):
1. Цикл по периодам, потом цикл по добавкам/КТО.
2. Вычисление всех добавок/КТО в вектор, потом два цикла (по периодам и по добавкам) в любом порядке.
3. Цикл по добавкам/КТО, потом цикл по периодам (так у НМ в коде для боинка).
Если считаем один период, то разницы между вариантами практически нет.
Если считаем больше одного периода, то вариант 1 самый медленный (линейно от количества периодов) так как перевычисляет много раз каждую добавку, 3 самый быстрый, 2 по идее немного медленнее 3 из-за доступа к большому вектору добавок.
Если считается буквально несколько периодов, то 3 вариант можно ещё чуточку ускорить: сохранить КТО без последних 1-2 циклов/простых и довычислять на лету только их, это по идее проще чем КТО по всем простым. Если считаются десятки и более периодов, то смысла в таком улучшении нет, оно даст не более единиц (или долей) процентов скорости.
Насколько понял у Вас используется 2 вариант. Я для теста использовал 3. Его преимущество - не нужно памяти под добавки, они вычисляются и сразу используются ровно один раз. Его недостаток - решения разбросаны по всем проверяемым периодам. В отличие от 2 варианта, где можно сделать цикл по периодам внешним и так сгруппировать решения по периодам (а отсортировав вектор добавок можно получить решения и строго по возрастанию), в этом его преимущество, но цена за него - память.

[Yadryara]

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

Насколько понял у Вас используется 2 вариант.

Да, с внешним циклом по периодам.

А 3-й вариант, как понимаю, это как поиск по лучам, то есть вычислил одну добавку, прогнал её по периодам, потом вычислил другую, снова прогнал, то есть внешний цикл по добавкам.

Тут ещё вроде есть возможность ускорить проверку кандидатов, ведь числа в кортеже разные: 10 точных (родных) и 5 приблизительных. Так вот надо сначала вроде как точные проверять и отбрасывать, а потом уже приблизительные. И всё забываю что быстрее работает ispseudorprime или nextprime.