Пентадекатлон мечты

[DemISdx]

EUgeneUS в сообщении #1717240 писал(а):

DemISdx в сообщении #1717230 писал(а):

cat coul.c |grep "_GMP_"

wrest в сообщении #1717238 писал(а):

В основном коде pcoul используются типы данных gmplib, ессно, и функции типа mpz_ и gmp_ из gmplib, например mpz_lcm, mpz_add, mpz_mul, mpz_divexact и т.п. Иначе как ещё большими числами манипулировать?

Добавлю, что типы и классы традиционно объявляются в хидерах (.h), а не в .c

Я как бы не много в курсе...

(Оффтоп)

А также в курсе, что написано в 199-ой строке https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.7-4.6/+/02075080d51c371ae87b9898bf84a085e436ee27/include/gmp.h#199

/* For reference, note that the name __mpz_struct gets into C++ mangled
   function names, which means although the "__" suggests an internal, we
   must leave this name for binary compatibility.  */

Равно как и этой переписки:
https://gmplib.org/list-archives/gmp-devel/2013-February/002777.html
Не нужно флеймить...

[Dmitriy40]

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

ну то есть когда мы говорим "ласточка" или "дрофа", вам непонятно про что идёт речь?

Мне непонятно. Но при желании я могу и сам разобраться. А запоминать влом.

wrest в сообщении #1717281 писал(а):

Я когда вижу в теме большое число, то иногда запускаю такой скриптик

Если не принципиален подсчёт непрерывного куска, то так проще (и сразу по всему максимально возможному полю 31):

? n=2531612004888381445507294256137777012314127441; tau=numdiv(n); x=n-n%64+17; print(d=[numdiv(x+t) | t<-[0..30]]); print(strjoin(w=[t==tau | t<-d]),", valids=",vecsum(w));
[24, 24, 24, 24, 24, 48, 24, 24, 24, 24, 24, 24, 24, 48, 24, 24, 24, 24, 24, 24, 8, 128, 16, 640, 16, 256, 4, 12, 8, 64, 8]
1111101111111011111100000000000, valids=18

[DemISdx]

Мне не понятно, что такое "+17", в Вашем коде?

[Dmitriy40]

DemISdx в сообщении #1717311 писал(а):

Мне не понятно, что такое "+17", в Вашем коде?

n-n%32 округляет n к кратному 32 вниз/влево, нам же надо чтобы цепочки начинались так чтобы кратное 32 было центральным в цепочке, т.е. начало цепочки будет -15 от центра или +17 от меньшего кратного 32.
Разумеется это работает только для цепочек содержащих в себе кратное 32 и не на первом месте, но если цепочка длиннее 16, то это обязательно так и есть.
Можно сделать x=n-n%64+17, тогда требования к цепочке снимаются (кратное 64 обязано быть слева от цепочки), выше поправил. Это работает для цепочек с максимально допустимой длиной не более 31.

[VAL]

$M(96) \ge 18$

13790246575748756076466055680810860874988875737505871868

В ближайшее время планирую поискать цепочки D(96,19) и D(192,15).
Последнюю я безуспешно искал полтора года (на одном компе в 8 потоков).
Но это было во времена, когда мы верили в теорию флогистона эфира оптимальности паттернов на 3 простых.

[EUgeneUS]

VAL в сообщении #1717418 писал(а):

$M(96) \ge 18$

Поздравляю!!!
Судя по времени нахождения, за D(96,19) придется поупираться, но оно достижимо.

[VAL]

EUgeneUS в сообщении #1717420 писал(а):

Поздравляю!!!

Спасибо!

Цитата:

Судя по времени нахождения, за D(96,19) придется поупираться, но оно достижимо.

Полагаю и время может быть не особо большим.
Соображения следующие:
1. D(96,18) найдена не сегодня, а позавчера. То есть, поиск был не таким уж долгим.
2. Примерно половина доступных мне мощностей в поиске не участвовала.
3. Надеюсь, мне не лень будет реализовать идею с двумя переставляемыми наборами чисел (квадратов и подпорок). Это должно дать эффект.

[Yadryara]

VAL в сообщении #1717418 писал(а):

$M(96) \ge 18$

Поздравляю.

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

Кстати, из-за усиления фильтрации по ласточкам нынче засуха. Но вот одна довольно маленькая нашлась. Покажу позже.

И ещё одна маленькая. Ласточка с зимою в сени к нам летит...

740942401561348069849929960726625232345849041     111111111 111111 111              18
961607399158799496985689288649014777624669340                11111111  1111111111   18
1642203504195807599593540559942872705604046940       1       1 11111 111111111111   19

[Yadryara]

Несмотря не многочисленные трудности (ещё и многократные отключения света) поиск D(24,20) продолжается.

Самая маленькая февральская ласточка:
177596494016304335013997043853804672478821340

Вообще, если сложить прошлогодние (в основном ноябрьские) результаты с нынешними, то получается, что ласточек в этом поиске найдено уже 40 штук, а дрофа только одна. Все показывать не буду, покажу те, что с valids=19. Добавил и рекордную D(24,19).

Авторство: все цепочки здесь найдены нами с Демисом.

Start                                             Location                      Valids
18852797512788010920723387591494690548010011                1111111111111111111     19
524531731485086461449205914830696861874340441        1    1111111 11111111 111      19
796031949318314104112173209073585585824943441     111 1111111111 11111       1      19
1489265119708421862376048690050340665325013140       111111111111111111 1           19
1642203504195807599593540559942872705604046940       1       1 11111 111111111111   19
1791249667941579437799485051079960469673032540       1       1111111 111111111 11   19
4188700851034666768298148204996412310399205841    11111111 111111 1111       1      19
4477440517844413259847928701924922629052061140       111111 111111111111     1      19
8045937841515011348849027358710575723447005841    111111111111 111111        1      19
8100226559294081664015822020041285976561952340       11111111111 1111 111    1      19
23238807934214952327957108565847744332693370641   1111 1111111111 1111       1      19

Всё ли понятно, где здесь ласточки, а где дротики?

[Yadryara]

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

Самая маленькая февральская ласточка:

Всё-таки похоже что корректировка счёта была сделана в правильном направлении. Нашлась ласточка которая на порядок меньше:

15192635649457330559604641981414830081269340

wrest в сообщении #1716903 писал(а):

Это из-за того что D(48,24) - безнадёжно?

Надёжно D(48,32) — безнадёжно.

DemISdx в сообщении #1717311 писал(а):

Мне не понятно, что такое "+17", в Вашем коде?

Очень рад что Демис решил наконец-то разобраться. Что для кортежей, что для цепочек важнейшим является понимание деления с остатком. Так что отвечу сразу и wrestу и Демису.

Вот недавно я паттерн изображал:

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

            1112222222222333333333344444444
                    56789012345678901234567
   2                 1 2 1 5 1 2 1 3 1 2 1 
   3                5  1  1  2  1  1  2  1 
   5                    1    1    2    1   
   7                    2      1      1    
  11                  1          2         
  13                        1            2 
  17                     2                1
  19                 2                  1  
  61                               2       
___________________________________________
23-59                 2   2 2 2 2   22  2 2
nu                  33333333324333414333323

Если взглянуть на шапку, то можно увидеть два ряда цифр:

1112222222222333333333344444444
        56789012345678901234567

Во втором ряду меньше цифр чем в перовом. Я так сделал, чтобы подчеркнуть крайне правое положение полосы и её ширину.

На самом-то деле цифр одинаковое количество, это же просто числа от 17 до 47, записанные по верикали:

1112222222222333333333344444444
7890123456789012345678901234567

Теперь уберу сердцевину, тогда это будет чётко видно:

1112222222222333333333344444444
7                             7

И это не абы какие числа от 17 до 47, это остатки по модулю 64. То есть непрерывня цепочка чисел имеющих по 48 делителей располагается в этом интервале от 17 до 47, то есть может быть длиной до 31. То же касается и 24 делителей.

Чтобы получше разобраться в этом, надо читать тему. Впрочем, если кому-то лень это делать, я могу начать рассказывать как бы с нуля.

[Yadryara]

Всё-таки поиск-24 заметно отличается от поиска-48. Ещё сегодня поколдовал — повысил качество фильтрации. И вот наконец-то дрофа:

765054111850918869860888735178729905943568540              111111111111111111 1   19

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

А RTX4090 считает 2e22 в день.

А может это надо в тему про быстрые программы. Позже напишу.

[Yadryara]

$\tikz[scale=1.5, transform shape, font=\fontsize{11}\selectfont, black!70!]{ \node at (4.79,10)[shading=ball,ball color=green!70!violet!100!, white] {\color{yellow}\Huge\textbf{D(24, 20)}} }$

$\tikz[scale=.67, transform shape, font=\fontsize{11}\selectfont, black!70!]{ \node at (4.79,10)[shading=ball,ball color=red!70!violet!100!, white] {\color{yellow}\Huge\textbf{1537314354494049610132983416025340335070312540}} }$

Демис !

[EUgeneUS]

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

Демис !

Демису поздравления!!!

[DemISdx]

EUgeneUS в сообщении #1718521 писал(а):

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

Демис !

Демису поздравления!!!

Спасибо, конечно.
Но прошу не забывать, что автором проги, идей направлений поиска и вдохновителем всей этой истории по 24,20 был таки Yadryara.
Равно как и Dmitriy40 приложился.
Да и wrest сколько своих соображений высказывал и они потом применялись.
А сам, только самовары починяю...

[Dmitriy40]

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

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

Я нашёл ту самую цепочку?

Не проверял, но судя по всему - да.

Решил всё же проверить.
Достал программу pcoul от 20251121, записал в лог v19.log строку

305 b0: 3^2 2.19^2 17^2 2^2.3.5 7^2.13 2.23^2 3.61^2 2^3.31^2 5.47^2 2.3^5 11.29^2 2^2.7 3.37^2 2.5^2 53^2 2^5.3 59^2 2.13^2 3^2.5.7 2^2.17 19.41^2 2.3.11^2 43^2: 0 / 168268 (1859268.97s) [32158735928 2687290949 218402477 17161526 1317803 111473 13378 2222 446 95 24 5 0 0 0 1 0 0 0 0 0 0 0]

которая была в логе Макаровой непосредственно перед нужной цепочкой (только прогресс занулил, пусть чуть больше посчитает), запустил счёт командой

pcoul.exe -rv19.log -Lf1 -x1e54 -b0 -p62 48 23

Буквально следующей же строкой в логе через секунду появляется

305 b0: 3^2 2.19^2 17^2 2^2.3.5 7^2.13 2.23^2 3.61^2 2^3.31^2 5.47^2 2.3^5 11.29^2 2^2.7 3.37^2 2.5^2 53^2 2^5.3 59^2 2.13^2 3^2.5.7 2^2.17 19.41^2 2.3.11^2 43^2: 115442 / 168268 (1859273.03s) [32158763772 2687293256 218402671 17161544 1317803 111473 13378 2222 446 95 24 5 0 0 0 2 0 0 0 0 0 0 0]

Дождался появления в логе строки

305 b0: 3^2 2.19^2 17^2 2^2.3.5 7^2.13 2.29^2 3.23^2 2^3.31^2 5.61^2 2.3^5 11.37^2 2^2.7 3.47^2 2.5^2 53^2 2^5.3 59^2 2.13^2 3^2.5.7 2^2.17 19.41^2 2.3.11^2 43^2: 104974 / 168268 (1859620.46s) [32168748451 2688128823 218470616 17166781 1318224 111507 13381 2222 447 95 24 5 0 0 0 2 0 0 0 0 0 0 0]

паттерн которой совпадает со следующей за искомой строкой лога Макаровой.

Как видим у меня программа обнаружила что цепочка не подходит несколько раньше чем valids=19 и никаких других цепочек с большим valids не нашлось.

Также видим что паттерн во второй строке совпадает с первой строкой, т.е. цепочка с большим valids нашлась именно в этом паттерне. Проверим что это именно искомая цепочка запустив pcoul ровно только для неё, оставив в логе снова лишь первую строку:

pcoul.exe -rv19.log -Lf1 -b0 -p62 -x6860e50:6861e50 48 23

В логе появляется строка

305 b0: 3^2 2.19^2 17^2 2^2.3.5 7^2.13 2.23^2 3.61^2 2^3.31^2 5.47^2 2.3^5 11.29^2 2^2.7 3.37^2 2.5^2 53^2 2^5.3 59^2 2.13^2 3^2.5.7 2^2.17 19.41^2 2.3.11^2 43^2: 115442 / 115449 (1859272.07s) [32158735931 2687290949 218402477 17161526 1317803 111473 13378 2222 446 95 24 5 0 0 0 2 0 0 0 0 0 0 0]

Так что цепочка с большим valids нашлась между 6.860e53 и 6.861e53.
Поставил паттерн и пределы в свою программу перебора с облегчёнными условиями отбора и она находит цепочку:
686052022400584314827322765057918194407720939855491537: 48, 24, 24, 48, 48, 48, 48, 48, 48, 48, 48, 24, 48, 48, 48, 48, 48, 24, 48, 48, 48, 48, 48, valids=19, i=230883
i это значение из формулы n=n0+i*lcm(v), он же (только вдвое меньше потому что перебор по i идет с шагом 2) виден и в логе pcoul.

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

Отдельно странно что у меня цепочка отбросилась быстрее, на 3 valids меньше.

-- 18.02.2026, 20:40 --

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

Отдельно странно что у меня цепочка отбросилась быстрее, на 3 valids меньше.

И это повторялось много раз, единицу в 19-й позиции ни разу не видел, всегда двойка в 16-й.
Выходит что проверка мест цепочки в pcoul не полностью детерминирована. Возможно из-за вероятностного алгоритма факторизации (ECM).