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

[Dmitriy40]

Длинные наоборот должны падать сильнее, там же экспоненциальная зависимость от длины цепочки.
Пустыню 1107-1126e35 перепроверил, да, так и есть, всё правильно.

-- 27.03.2022, 14:41 --

Моя статистика по низинам (всё выложено в облако):
<1e34: 1x12, 10x11.
<1e35: 1x14, 1x13, 22x12, 68x11.
<1e36: 5x14, 12x13, 132x12, 566x11.
<1e37: 10x14, 126x13, 954x12, 4225x11.
<2e37: 17x14, 230x13, 1726x12, 7712x11.
И я бы не обращал внимания на малые количества, типа меньше 5 штук, это скорее всего аномалии.

[Yadryara]

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

И я бы не обращал внимания на малые количества, типа меньше 5 штук, это скорее всего аномалии.

Да, по крошечным выборкам не стоит всерьёз ориентироваться.

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

<1e37: 10x14, 126x13, 954x12, 4225x11.
<2e37: 17x14, 230x13, 1726x12, 7712x11.

Вот эти два одинаковых диапазона удобно сравнить. Особенно, если использовались одинаковые проги.

Падение по всем фронтам:

$10\to7, 126\to104, 954\to772, 4225\to3487$

[EUgeneUS]

перезапустился согласно плану
Плюс перенес рабочие каталоги на SSD. Надеюсь это снизит накладные расходы.

Статистика по насчитанном:

N2-51_1000e35_1140e35: 11x25, 12x6
S9-45_1000e35_1140e35: 11x24, 12x8
ALL_17300e35_17302e35: 11x21, 12x5
ALL_173300e35_173302e35: 11x7, 12x3

Но в этот раз было закомментировано по две строки с обоих сторон в gp-шном файле

[EUgeneUS]

По скорости
1e34 обернулось по всем паттернам где-то за час-двадцать - час тридцать. То есть ускорения от перехода от SSD заметного не было.
Итого, скорость та же - примерно 1e35 в сутки в каждом потоке.
Значит 9e37 буду считать 100 дней. Это печально.

Кстати, "харвестр по низам" (9e37) сильно отстал от "исследовательских зондов":
ALL_900е35: 11х1
ALL_1730е35: 11х4, 12х1
ALL_17302e35: 11х5, 12х1
ALL_173302e35: 11х3, 12х1, 13х1

Возможно, это из-за плохого начала - три ноля после первой цифры.

[Dmitriy40]

SSD может влиять, но лишь когда памяти мало — т.е. винде не хватает её закэшировать все файлы. На предыдущих версиях программы, когда каждый файл занимал 11М, я видел разницу в скорости между HDD и SSD.

А у меня нашлась первая 14-ка после 2e37:
M12-N2-31-623154: 23750980474327054410858978585509736345: 48, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, valids=14, maxlen=14
Что интересно, первое число проверяемое и потому нет метки ALL, но имеет делитель 4241, лишь немногим больше порога проверки в моей программе, иначе бы не нашлось.
Да и вообще, из 18шт 14-ок 8шт по правильному найтись не должны были (без ALL), почти половина однако.

[EUgeneUS]

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

SSD может влиять, но лишь когда памяти мало — т.е. винде не хватает её закэшировать все файлы.

А памяти мало: её всего 8Гб. А потоки запускались из своих папок со своими экземплярами файлов.
Переделал под запуск из одной папки. Посмотрим, насколько поможет.
Впрочем, лампочкой HDD продолжает мигать.

[EUgeneUS]

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

Кстати, "харвестр по низам" (9e37) сильно отстал от "исследовательских зондов"

"Харвестр" вышел из начальных трех нулей и реабилитировался. Сейчас по общему количеству цепочек тренд ожидаемый - с ростом порядка количество цепочек падает. Может быть раза в два на порядок. Точнее пока сложно сказать.
А вот по длинным цепочкам (12 и 13) пока эта зависимость не видна. Но их пока мало насчиталось.


После перезапуска всех потоков из одной папки проявился интересный эффект. Потоки "синхронизовались" через несколько часов. Сейчас все 4-ре потока считаются в точности по одинаковым паттернам. Как это повлияло на скорость - пока сложно сказать. Как бы не замедлило несколько..

[Yadryara]

Вот эта консольная команда не работает ожидаемым образом:

findstr " 6, "

Кроме нужного, находит и "96," и "=6,". А мне нужно найти именно с пробелом перед 6-кой.

Читал справку по этой команде, но пока не получается.

А ведь обычный блокнотовский поиск отлично справляется.

[Dmitriy40]

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

Вот эта консольная команда не работает ожидаемым образом:

Если в строке встречаются пробелы (и возможно некоторые другие спецсимволы), то надо явно указать что вся строка является текстом для поиска, это делается ключом /C: — findstr /C:" 6, " — так будет искать именно с пробелом перед 6 и после запятой, иначе пробел разделяет разные искомые варианты и в поиске не учитывается. Но с этим ключом нельзя искать сразу несколько вариантов, например findstr /C:"12, 6, 48," попытается найти именно такую подстроку, а не любую из "12,", "6," "48,".
Кстати об этом прямо сказано в хелпе к findstr:

C:\findstr /?
...
Использовать пробелы для разделения нескольких искомых строк, если аргумент не
имеет префикса /C. Например, 'FINDSTR "Привет мир" a.b' ищет "Привет" или
"мир" в файле a.b, а команда 'FINDSTR /C:"Привет мир" a.b' ищет строку
"Привет мир" в  файле a.b.

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

После перезапуска всех потоков из одной папки проявился интересный эффект. Потоки "синхронизовались" через несколько часов. Сейчас все 4-ре потока считаются в точности по одинаковым паттернам. Как это повлияло на скорость - пока сложно сказать. Как бы не замедлило несколько..

Да, забавно. Думаю это связано с временем доступа к файлам, те что уже только что прочитаны в другой поток остаются в кэше и отдаются следующему потоку быстрее. И работать так должно бы чуть быстрее — файлы физически читаются по одному разу и со скоростью наибыстрейшего (в каждый момент времени) потока. Но не думаю что разница будет значительна/заметна. И эта синхронизация может сбиваться при нахождении цепочек (и при любом заметно более долгом действии), при этом выполняется заметно больше операций (numdiv особенно, print, write).

[Yadryara]

Dmitriy40, Благодарю, сработало. В тех хэлпах, которые я видел, этого сразу не заметил, хотя вижу, что да, это было написано. Например https://kztarif.ru/kompjutery/findstr-reguljarnye-vyrazhenija-primery

[Yadryara]

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

Но с этим ключом нельзя искать сразу несколько вариантов, например findstr /C:"12, 6, 48," попытается найти именно такую подстроку, а не любую из "12,", "6," "48,".

Мне это и не надо, а надо найти только варианты, где две и более 6-к. Тоже не хочется в Блокноте искать, ибо глаза утомляются и можно что-то пропустить.

[EUgeneUS]

И снова о статистике.
Определим:
$N_i$ - число цепочек с валидными $i$ числами на неком, рассматриваемом диапазоне.
$a_i = N_i/N_{i-1}$

Гипотеза1: $a_i$ - в среднем на достаточно больших диапазонах являются константами (не зависят от выбранного диапазона), или меняются так слабо, что их можно считать константами.
Гипотеза 2: известную последовательность $a_{12}, a_{13}, a_{14}$ можно продлить до $a_{15}, a_{16}$. При этом $a_{16}$ должно быть или нулем, или отрицательным числом (16 не бывает).

Гипотеза 1. Прекрасно подтверждается для $a_{12}$ и $a_{13}$.
А вот $a_{14}$, похоже, падает с ростом начального числа в диапазоне. И это печально. Но там статистики пока мало.
Если гипотеза 1 верна, а экстраполяция будет логарифмическим трендом. То в оптимистичном случае одну 15-ку следует ожидать на 17-20 тысяч 11-к. И это случится до 10е37.
Если же $a_{14}$ таки падает, то все становится грустно и печально.

-- 28.03.2022, 15:04 --

у меня получилась такая апроксимирующая формула:
$a_i= -\ln(i)+e$
Не знаю откуда она могла бы взяться. Но уж очень красивая
Если она верна, то одну 15-ку следует ожидать на 35462 11-ки

[Dmitriy40]

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

Мне это и не надо, а надо найти только варианты, где две и более 6-к.

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

pat=readstr("Result.txt");\\Из какого файла взять данные
{for(i=1,#pat,
   s=strsplit(strsplit(pat[i],":")[3],",")[1..15];\\Выделяем в вектор только 15 делителей
   for(k=1,15,
      x=eval(s[k]);\\Переводим строки в числа
      if(x==12, s[k]=2;\\И конвертируем число делителей в число простых
      , x==36, s[k]=2;
      , x==6, s[k]=1;
      , x==18, s[k]=1;
      , x==24, s[k]=3;
      , x==48, s[k]=4;
      , x==72, s[k]=4;
      , x==96, s[k]=5;
      , x==144, s[k]=5;
      , x==192, s[k]=6;
      , x==288, s[k]=6;
      , x==384, s[k]=7;
      , x==576, s[k]=7;
      , x==768, s[k]=8;
      , next(2);\\Цепочки с другими делителями пропускаем нафик, убирать нельзя чтобы в векторе не осталось строк, только числа
      );
   );
   if(vecsum(s)==30, print(pat[i]));\\Если ровно 19 простых, то печатаем исходную строку
)}

В ней финальное условие можно и менять, понятное дело.
Имея вектор s[15] с делителями можно уже делать что угодно, не обязательно именно так использовать, это скорее пример как получить из строки список делителей не проводя снова 15 раз numdiv (что тоже вполне реально, но медленнее).

[Yadryara]

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

Я сначала глазками искал двойные шестёрки в списке цепочек с шестёрками вообще, а потом написал программульку на PARI:

Я так и думал. Спасибо, всё получилось. Статистика по всем паттернам до 2е37. Указаны только цепочки с менее чем 20-ю простыми. Второе число справа - сколько различных вариантов возможно, крайнее справа - сколько нашлось.

11-15    1             0
11-17   48             0
11-18   48             1
11-19   48             0
11-19  462            15

12-16    4             0
12-18   78             6
12-19   78             2

13-17    6             1
13-19   44            13

14-18    4             3

15-19    1             0

Впоследствии попробую оценить вероятности.

[Dmitriy40]

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

Гипотеза1: $a_i$ - в среднем на достаточно больших диапазонах являются константами (не зависят от выбранного диапазона), или меняются так слабо, что их можно считать константами.

Собственно так оно и есть, на достаточно больших интервалах должны быть константами, ведь это получится просто отношение вероятностей простоты чисел, а оно зависит лишь от отношения логарифмов величины чисел (диапазонов). Боле того, все $a_i$ по идее должны быть одинаковыми.
Наблюдаемое же уменьшение (или увеличение, без разницы) — это статистическая аномалия, из-за малой выборки.

-- 28.03.2022, 20:04 --

Даже интересно почему реальные отношения $N_i/N_{i-1}$ явно не одинаковы ... Может быть причина в условиях отбора, они существенно отличаются для разных длин. Вот если убрать из PARI все ispseudoprime и мою программу и проверять тотально все числа на numdiv, то думаю зависимости будут более точными. Или опять же отбирать для статистики лишь "ALL" цепочки, но их же всего под пару сотен штук (59x11, 53x12, 43x13, 10x14) и 14-ки явно выбиваются.