2014 dxdy logo

Научный форум dxdy

Математика, Физика, Computer Science, Machine Learning, LaTeX, Механика и Техника, Химия,
Биология и Медицина, Экономика и Финансовая Математика, Гуманитарные науки




Начать новую тему Ответить на тему На страницу Пред.  1 ... 31, 32, 33, 34, 35, 36, 37 ... 72  След.
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение11.05.2024, 16:40 
Заслуженный участник


20/08/14
11775
Россия, Москва
gris в сообщении #1638755 писал(а):
Я только вчера начал искать все 184 паттерна для валидс14.
Скорее всего это не слишком разумно в плане скорости поиска: 14 паттернов будут перебираться быстрее чем 184 даже на 1 более длинных (вряд ли во всех паттернах длиной 15 будет суммарно в 13 раз меньше формул). Хотя в каждом конкретном случае лучше проверить.
Вот сравним указанный: для 37# 93млн против 22млн, менее 5 раз, а паттернов с произвольным числом на месте 154 10шт (кроме одного правильного 150), т.е. при их переборе надо сделать вдвое больше проверок цепочек, т.е. вдвое медленнее. Для 43#=13e15 (решение найдётся в нём) отношение практически тоже, 73e9 vs 16e9, ну никак не 10 раз. Более того, если даже просуммировать количество формул для 43# для всех этих 10 паттернов, получим 148e9, при том что для паттерна длиной 14 достаточно 73e9, практически вдвое меньше (и соответственно быстрее).
Разумеется это грубая оценка, реально надо взять и перебрать все эти 184 паттерна на каком-то периоде (типа 23#-29#-31#) и на нём же перебрать все 14 реальных паттернов и сравнить общие времена того и другого. Вангую перебор 14 заметно выгоднее (вдвое-втрое).

PS. Прежде чем запускать счёт более чем на год (270e3 раз по 148e9/15.8e9 итераций, суммарно 2.5млн итераций по 18.2с) стоит оценить реальную скорость разных вариантов и не вестись на безосновательные заявления разных лиц. А то применив утверждение "более короткие паттерны ищутся быстрее" несколько раз можно дойти до того что выгоднее всего проверять паттерны длиной 1 - просто все простые числа! Что разумеется абсурд. Быстрее перебираются (но медленнее находятся) более длинные паттерны, вопрос лишь насколько именно быстрее и какой эффект пересилит - ускорение за счёт удлинения (а не укорочения!) паттернов или увеличение их количества. И тут уже универсального ответа нет, надо проверять конкретные варианты, если длинных паттернов становится не сильно больше, а перебираются заметно быстрее - будет выгодно. Но по моим наблюдениям это редкость.

-- 11.05.2024, 16:50 --

Yadryara в сообщении #1638760 писал(а):
Вы же видели программу:
Я не стал смотреть в каком именно цикле сидит вычисление g2[], Ваша нелюбовь к оформлению кода (хотя бы правильные отступы чтобы было видно что в каком цикле/условии сидит) снижает желание смотреть подробнее, ведь придётся самому всё правильно оформить и только потом разбираться. Как же Вы будете на Питоне писать-то, ведь там без отступов никуда. Я в следующий раз выкачу свою программу вообще в одну строку, PARI же всё равно.

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение11.05.2024, 19:39 
Заслуженный участник
Аватара пользователя


13/08/08
14495
Dmitriy40
1. Отчитаюсь о своей любви к отступам :-)
Код:
for( ip=1,nw,
   ...
); \\ for ip
forvec(v=vector(#wd...
  foreach(vp,bpp,
     if( ispseudoprime(bpt) && 
       ...
     );\\ if  ispseudo
  );\\ foreach
);\\ forvec

даже помечаю конец циклов/блоков
да, в аккуратном оформлении есть и эстетика, и польза.

2. Кортежи с валидс14 я искал совместно один раз с чтением из файла с паттернами. Это нужно было для знакомства с количеством формул.
Потом я запускал запуск по одному выбранному паттерну. Но у меня нет возможности вести поиск больше часа (в среднем) в день. Интересовали некоторые особенности. Мне кажется, что искать однородные паттерны с одинаковым количеством формул одинаково затратно.

3. Насчёт "скорости" нахождения реализации паттернов разной длины у меня есть своё мнение. У авторитетов возникла какая-то терминологическая путаница. Если стоит задача найти первую реализацию паттерна в некотором диапазоне, то паттерн [0] реализуется моментально (главное — сразу остановиться).
10^21 number from
10^21 number to
[0]
patterns length 1
200560490130 period
search in 20... (2.0 E32) - 20... (2.0 E32) L=2.01 E11
prove by 31#
[0] 30656102400 formulae
200560490130000000000122924171371:[0]
time = 15 ms.

аналогичный поиск для 15-ки немножко затянется с отрицательным результатом
10^21 number from
10^21 number to
[0,18,30,60,78,84,108,114,120,144,154,168,198,210,228]
patterns length 15
200560490130 period
search in 20... (2.0 E32) - 20... (2.0 E32) L=2.01 E11
prove by 31#.
[0, 18, 30, 60, 78, 84, 108, 114, 120, 144, 154, 168, 198, 210, 228] 942480 formulae
time = 35,788 ms.

получается, что поиск кортежа с паттерном [0] в две тыщи раз быстрее поиска 15-228 :?:
А вот немного поменяем задачу: найти все реализации на данном диапазоне. Для 15-ки те же 35 секунд, а вот для [0]... Я не дождался.
Количество формул и частота появления тянут в разные стороны. Терминологическую путаницу надо своевременно устранять :-)
+++ Так Вы же написали уже то же самое :oops: Я не заметил, честно. Потом посмотрел внимательнее :facepalm: Но я же правильно написал :?:

4. Некоторый паттерн реализуется 200 раз в диапазоне (3, E16). Есть вектор начальных элементов pn(200). Можно ли с помощью аппроксимации указать достаточно маленький диапазон для поиска pn[201]?

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение11.05.2024, 21:49 
Заслуженный участник


20/08/14
11775
Россия, Москва
gris
Вообще говоря у нас с Вами особых разногласий по терминологии и нет. Или даже вообще нет. А что там видит между строк НМ - её личные проблемы.

gris в сообщении #1638790 писал(а):
получается, что поиск кортежа с паттерном [0] в две тыщи раз быстрее поиска 15-228 :?:
Нет, это некорректное сравнение скорости: а если бы и 15-ка нашлась буквально с первого же проверенного числа - скорости стали бы равными? Вы возьмите одинаковые условия: или оба паттерна не находятся, или наоборот находятся в одном и том же месте. Фактически речь не про время до первого нахождения цепочки (оно может быть любым от нуля если просто угадать), а про скорость перебора заданного диапазона чисел (для паттерна [0] можно взять интервал нужной длины только из составных чисел). Независимо есть там искомая цепочка или нет (но удобнее брать где её нет, иначе будет измеряться какая-то другая скорость).

Вообще задач можно ставить много разных, например:
а) Найти конкретную цепочку, хотя бы 19-252.
б) Найти любую цепочку длиной 19 (или 21).
в) Найти все цепочки 19-252 (или любых других, но строго одну) в заданном интервале/диапазоне.
г) Найти все цепочки заданной длины в заданном диапазоне.
д) Найти любые симметричные цепочки в заданном диапазоне.
е) Найти любые цепочки из близнецов в заданном интервале.
ж) Найти цепочки из ещё более экзотических типов чисел (я лет 10 назад этим занимался и даже что-то нашёл).
з) И так далее, задач ещё море разных.
В контексте поиска 19-252 интересует лишь задача а).

Значит надо перебрать все возможные варианты до первой такой цепочки (которая неизвестно где, но для примера возьмём что перебрать надо до 67#=7.86e24). Это можно сделать разными путями:
а1) Искать паттерн 19-252. Тогда перебрать надо 3e17 вариантов (именно столько "формул" по 67#).
а2) Искать центральную 17-240 и проверять не расширяется ли она до 19-252. Перебрать надо 2e18 вариантов, в 7 раз больше! На PARI без разницы цепочку какой длины проверять (при правильно организованной проверке), потому разница в количестве вариантов равна разнице в скорости. Именно это я и имел в виду что так (через поиск 17-240) искать 19-252 дольше чем прямо по паттерну 19-252. А отдельной задачи найти 17-240 (хоть все, хоть любую, хоть какую) вообще не стоит.
а3) Искать центральную 15-228 и проверять не расширится ли она до 19-252. Проверить надо 4.7e18 вариантов, уже в 16 раз больше (и дольше если на PARI).
а4) Искать ещё меньшие цепочки (вплоть до абсурда из одного простого числа) и проверять не расширятся ли до 19-252. Ещё больший маразм.
а5) Искать несколько паттернов длиной 21, полученных из 19-252 добавлением внутрь лишних простых (ради уменьшения количества вариантов). Если удачно добавить, возможно будет и улучшение, надо проверять, во сколько раз уменьшится количество вариантов суммарно во всех паттернах и во сколько раз станет больше паттернов. Я сомневаюсь что будет выигрыш, но не проверял. Займитесь проверкой, это считается быстро, тут работа только с паттернами (тот самый переход 14->184 что Вы и так уже сделали для других паттернов), цепочки искать чёрти где не нужно, только сравнить количество паттернов и суммарное количество вариантов в них (и оценить какую часть из всех 3e17 вариантов покрыли чтобы прикинуть во сколько раз дальше 67# придётся проверять).
а6) Искать паттерн(ы) длиной 21 (и более), полученные расширением 19-252 в стороны. Они тоже будут быстрее проходить интервал, но 99.99% что несколько первых цепочек будут намного-намного дальше первой 19-252 (например первая 17-240 найдена в 1e21, а первая 15-228 всего лишь в 2e18, перебирать 17-240 до 1e21 раз в 100 дольше перебора 15-228 до 2e18 - если бы искали 15-228) и это нивелирует (и думаю на порядки!) ускорение прохода интервала.
а7) Искать решетом. Проверить надо 1.3e23 варианта (столько простых до 7.86e24). Как бы быстро не проверять наличие цепочки, основным тормозом будет генерация простых решетом. Решето перебирает пусть даже 3e12 чисел за час (примерно так работает текущее приложение боинка), до 7.86e24 надо 2.6e12 часов или 300 миллионов лет в один поток, чтобы справиться за год надо десятки миллионов компов в боинке, столько нет и не предвидится.
а8) Угадать и ткнуть пальцем. Мгновенно. Удачи желающим!
Как видно пока самым быстрым реальным остаётся способ а1). Что бы там не вещали отдельные неадекватные личности. Тесты - наше всё, проверяйте сами!
Способ а5) на скорость не исследовался.

Впрочем проверить один самый простой вариант по способу а5) могу: добавим числа 2 и 4 в паттерн и посмотрим сколько будет суммарно вариантов в двух таких паттернах длиной 20: 77.4e15+30.6e15=108e15, почти втрое меньше родного. Если это лишнее простое вообще не проверять на простоту, то фактически мы выбросили из общего количества вариантов 2/3 - и значит в общем-то с такой же вероятностью пропустим цепочку 19-252, т.е. в среднем считать придётся втрое дальше, то на то и выходит. А если лишнее простое тоже проверять на простоту, то цепочку 19-252 вообще не найдём - потому что реально цепочки станут 20-252. Не вижу смысла так усложнять.

gris в сообщении #1638790 писал(а):
4. Некоторый паттерн реализуется 200 раз в диапазоне (3, E16). Есть вектор начальных элементов pn(200). Можно ли с помощью аппроксимации указать достаточно маленький диапазон для поиска pn[201]?
Ну и кто мешает это проверить? Насколько я понимаю там банальная линейная зависимость, подбираете коэффициенты по МНК по первым 190 точкам (а лучше даже ещё и выкинуть несколько десятков первых, там слишком выбросов много) и вперёд, сравнивать последние 10 чтобы оценить качество экстраполяции. Считать коэффициенты и Эксель умеет (и продолжать дальше тоже, линия тренда вроде бы называется), и онлайн куча сайтов есть, дерзайте. Математика на уровне школьной (хотя напрямую в школе кажется и не проходят). Наверняка кстати и PARI умеет, надо только найти функции.
Только я сомневаюсь что получите точность лучше единиц процентов, а большая погрешность не приведёт к существенному ускорению проверок. И кстати можно заранее оценить требуемую точность для достижения заданного эффекта ускорения, а не брать её с потолка. А судя по аномально рано найденным в боинке 19-ам я сомневаюсь что такая экстраполяция вообще имеет смысл (стат.выбросы её перекроют с огромным запасом, на порядки). Впрочем, я могу и ошибаться, как с 19-ми в боинке.

-- 11.05.2024, 21:58 --

Я не зря выше постоянно оговаривался что именно на PARI количество вариантов (или "формул") равно затраченному времени (обратной скорости). Потому что на других языках вступают в силу эффекты второго порядка (но не малости) и для моей программы бывает выгоднее сделать меньше формул и соответственно длиннее перебор, зато таблицы займут меньше памяти и обработаются быстрее. А если многопоточно - то появляются эффекты третьего порядка (и тоже не малости, могут превысить все предыдущие) и иногда вместо 4-х потоков реально считают 1-2, а уменьшение количества формул загрузит все потоки и в итоге ускорит счёт.

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение12.05.2024, 06:28 
Аватара пользователя


29/04/13
8118
Богородский
Dmitriy40 в сообщении #1638770 писал(а):
Как же Вы будете на Питоне писать-то, ведь там без отступов никуда.

А зачем на Питоне?

Dmitriy40 в сообщении #1638770 писал(а):
Я в следующий раз выкачу свою программу вообще в одну строку, PARI же всё равно.

:-) Да, это страшная месть готовится. Хорошо хоть, что gp не всё равно :-)

Dmitriy40 в сообщении #1638803 писал(а):
В контексте поиска 19-252 интересует лишь задача а).

Значит надо перебрать все возможные варианты до первой такой цепочки (которая неизвестно где, но для примера возьмём что перебрать надо до 67#=7.86e24). Это можно сделать разными путями:
а1) Искать паттерн 19-252. Тогда перебрать надо 3e17 вариантов (именно столько "формул" по 67#).
а2) Искать центральную 17-240 и проверять не расширяется ли она до 19-252. Перебрать надо 2e18 вариантов, в 7 раз больше! На PARI без разницы цепочку какой длины проверять (при правильно организованной проверке), потому разница в количестве вариантов равна разнице в скорости. Именно это я и имел в виду что так (через поиск 17-240) искать 19-252 дольше чем прямо по паттерну 19-252. А отдельной задачи найти 17-240 (хоть все, хоть любую, хоть какую) вообще не стоит.

Немного дополню, вдруг кто опять не понял.

Известны 8 центральных 17-240. 6 нашёл Jarek и ещё две попутно нашёл Dmitriy40:

Yadryara в сообщении #1598167 писал(а):
Jarek нашёл шесть таких 17-к:

$  1006882292528806742267$

$  3954328349097827424397$

$  4896552110116770789773$

$  6751407944109046348063$

$  7768326730875185894807$

$ 19252814175273852997757$

Dmitriy40 в сообщении #1624329 писал(а):
С центральной 17-кой:
154787380396512840656501: [ +0, 6, 12, 30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210, 222, 240, 246, 252], len=18, valids=18
901985248981556228168761: [ 0, 6, 12, 30, 42, 72, 90, 96, 120, 126, 132, 156, 162, 180, 210, 222, 240, 246,+252], len=18, valids=18

Перенумеруем 3 наибольших:

$6.\quad\;\, 19252814175273852997757$

$7. \quad 154787380396512840656501$

$8. \quad 901985248981556228168761$

Можно ли найти ещё такие кортежи между 6-м и 7-м и между 7-м и 8-м?

Да, почти наверняка.

Может ли такой найденный новый кортеж быть расширен до симметричной 19-ки?

Теоретически, да.

Может ли такой найденный новый кортеж быть расширен именно до 19-252 ?

Нет. Потому что запреты по модулям здесь проверены.

Есть конечно малюсенький шанс, что Dmitriy40 ошибся при поиске. Но программы перепроверялись многократно.

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение12.05.2024, 14:18 
Заслуженный участник


20/08/14
11775
Россия, Москва
Yadryara в сообщении #1638827 писал(а):
Может ли такой найденный новый кортеж быть расширен именно до 19-252 ?
Нет. Потому что запреты по модулям здесь проверены.
Скорее потому что тогда такой кортеж был бы найден поиском 19-252.

Dmitriy40 в сообщении #1638803 писал(а):
а6) Искать паттерн(ы) длиной 21 (и более), полученные расширением 19-252 в стороны. Они тоже будут быстрее проходить интервал, но 99.99% что несколько первых цепочек будут намного-намного дальше первой 19-252 (например первая 17-240 найдена в 1e21, а первая 15-228 всего лишь в 2e18, перебирать 17-240 до 1e21 раз в 100 дольше перебора 15-228 до 2e18 - если бы искали 15-228) и это нивелирует (и думаю на порядки!) ускорение прохода интервала.
Ради интереса проверил этот путь. Поиск 21-360 (расширение 19-252 симметрично в обе стороны) всего вдвое быстрее поиска 19-252 (хотя количество вариантов по 67# меньше втрое, а по используемой таблице 37# меньше в полтора раза, вот как раз эффект второго порядка в моей программе). Казалось бы вдвое тоже прекрасно, однако как показывает опыт с 17-240 так будет найдена далеко не первая 19-252 (все первые 6шт 17-240 моим поиском 19-252 найдены не были и не могли быть), а первая найденная мной 17-240 аж в 150 раз дальше наименьшей 17-240! Т.е. так придётся проверить в сотню (или сотни) раз больше пути а1) и всего лишь вдвое больше скорость тут ничем не поможет.
Для более длинных расширений проигрыш ещё сильно больше (например кортеж 15-228 ещё в 500 раз ближе, а скорость всего в разы, не в десятки тысяч).
Так что самым быстрым из надёжных остаётся путь а1). Именно по реальным тестам скорости, а не фантазиям.

(Про ошибки в программах)

Ошибки в программах всё же бывают, от этого никуда не деться. К счастью последняя обнаруженная в рабочей программе ошибка не уменьшала список найденных цепочек, а увеличивала, т.е. выдавала и те цепочки, что по идее не должна была. К пропускам цепочек это гарантировано не приводило.

Кроме того, каждая новая версия программы обязательно сверяется со старой, принимаемой за образец. И так цепочка сверок тянется вплоть до тупой программы на PARI (и кстати не только на нём) просто последовательного перебора всех простых. Да, иногда ошибки столь редки что не попадают в диапазон сверок, потому полностью исключить возможность пропуска цепочки нельзя. Но вероятность этого очень и очень низка, фактически как 1/длину_сверки, что сильно меньше $10^{-6}$, так что пусть и не первая, но вторая-третья цепочка обязательно найдутся, не могут они все попасть ровно в ошибку (если оная вообще осталась в коде), это ещё на много порядков менее вероятно. А решения попрут валом после первого, все примеры других цепочек говорят об этом.

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

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение14.05.2024, 13:51 
Заслуженный участник


20/08/14
11775
Россия, Москва
gris
Ещё одна редкая цепочка Вам в таблицы:
175301483404392739: [0, 18, 30, 60, 64, 84, 108, 114, 120, 144, 150, 168, 198, 210, 228], num13=7679, valids=14
Их (valids=14) осталось 7шт не найденных.

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение14.05.2024, 14:55 
Заслуженный участник


20/08/14
11775
Россия, Москва
gris в сообщении #1638790 писал(а):
4. Некоторый паттерн реализуется 200 раз в диапазоне (3, E16). Есть вектор начальных элементов pn(200). Можно ли с помощью аппроксимации указать достаточно маленький диапазон для поиска pn[201]?
Так как речь скорее всего про 13-192, то взял их начиная с 5e18 (меньше есть пропуски, а в самом начале возможны и стат.выбросы) и посмотрел какую собственно точность прогноза надо иметь чтобы предсказать все 80+ цепочек. Среди всех вижу пару 5651655407449942001 и 5651665747048195117, отличающихся всего на 1.83ppm (1.83e-6), так что если хотим предсказывать цепочки без пропусков, надо иметь точность не хуже этой, т.е. 1ppm (1e-6 или 0.0001% или минимум 6 верных знаков). Но без знания точной физической/математической модели цепочек такая точность недостижима в принципе. А известно что появление простых чисел достаточно случайно (в том смысле что без решета нельзя предсказать где будет следующее, хотя можно намного более уверенно предсказать где его точно не будет), т.е. модели простых чисел с требуемой точность точно нет. Соответственно и предсказание цепочек с такой точностью невозможно.
Повторю, это если ставить задачу предсказывать цепочки без пропусков, тотально все.
Если достаточно находить лишь некоторые цепочки, причём быстрее полного перебора, то такое в общем возможно: среднее расстояние между выбранными цепочками составляет (9633607413909975061-5177865449056250347)/82=5.434e16 или 0.564% от величины максимальной, значит предсказывая новую (но не обязательно следующую!) цепочку с точностью не хуже ±0.1% наверное будем попадать недалеко от реальной цепочки, что и позволит перебирать интервал меньше полного. Как именно предсказывать с такой точностью - вопрос для исследований.

К сожалению поиску 19-252 это никак не поможет: может оказаться что как раз пропущенная 13-192 и расширяется до первой 19-252, а искать следующую 19-252 придётся в разы дальше (например вторая 17-240 аж вчетверо дальше первой). А если и вторая пропустится ... Если бы перебор одинакового диапазона при поиске 13-192 был более чем вчетверо (а лучше вдесятеро) быстрее перебора того же диапазона при поиске сразу 19-252 - было бы выгоднее. Однако на практике ситуация сильно обратная: перебор диапазона поиском 19-252 примерно в 80 раз быстрее перебора поиском 13-192, т.е. вместо ускорения поиска получим замедление в сотню раз. И чтобы его нивелировать надо предсказывать ещё точнее, чтобы перебирать ещё меньше, т.е. уже не ±0.2%, а ±0.001% или 20ppm (и это лишь граница окупаемости, для заметного выигрыша надо ещё меньше). Не говоря уж про возможные пропуски и соответственно вероятное увеличение объёма перебора до нахождения 19-252.. В такую точность предсказания практически случайного процесса я не верю (тогда надо не цепочки искать, а в рулетку играть, выиграешь миллионы вообще не напрягаясь).

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение15.05.2024, 11:23 
Аватара пользователя


29/04/13
8118
Богородский
Dmitriy40 в сообщении #1638868 писал(а):
Скорее потому что тогда такой кортеж был бы найден поиском 19-252.

Это уже говорилось. И я специально сказал о том же самом другими словами.

После отдыха вернулся к задаче. Решил перепроверить и по-новому вычислить 11-144. Объединил все вычисления в одну программу

(PARI)

Код:
allocatemem(2^26);

{print(); tz0=getwalltime();

v0=[0, 12, 30, 42, 54, 72, 90, 102, 114, 132, 144];

vco = [0, 0, 0, 0, 0, 0, 10, 396, 6868, 69358, 387838, 1378512, 3278384, 5495890, 6620352, 5617466, 3288286, 1227208, 252110, 24342, 980, 0];

forprime(pfin=31,precprime(v0[#v0]/2),

tz1=getwalltime();

\\print();
\\print(pfin,"   ", v0[#v0]);

pn=nextprime(pfin+1); \\37*2 = 74

cg=vector(#vco);

v=[0, 12, 30, 42, 54, 72, 2*pn, 90, 102, 114, 132, 144];

o=1;
while(v0[o]+2*pn < v0[#v0],

\\print();
\\print(v0[o]+2*pn,"   ", v0[#v0]);

v[7]=v[o]+2*pn;

a=setminus(vector(v[#v]/2,i,i*2),Set(v));

\\a=a[1..60];

ww=vector(v[#v]/2+3-#v,i,Map()); mapput(ww[#ww],2^#a-1,1);


\\print(#a," a = ",a);
\\print();

forprime(p=2, pfin,

m=setminus(vector(p,i,i-1),Set(-v%p));
am=vecextract(vector(p-1,i,fromdigits(Vecrev(apply(t->(t+i)%p>0,a)),2)),m);

   for(k=1,#ww,
      rr=Map();
      foreach(ww[k],m,
         b=m[1][1]; qq=m[1][2]; qn=0;
         foreach(am,x,
            y=bitand(x,b);
            if(y==b, qn+=qq; next);
            hy=hammingweight(y)+1; nn=0;
            if(mapisdefined(ww[hy],y,&nn), nn+=qq , nn=qq);
            mapput(ww[hy],y,nn);
         );
         if(qn>0, mapput(rr,b,qn); );
      );
      ww[k]=rr;
   );
   vc=vector(#ww); for(k=1,#ww, foreach(ww[k],x, vc[k]+=x[1][2]; ); );
   vcmax=#vc; while(vcmax>1&&vc[vcmax]==0, vcmax--);

\\print();print("vcmax = ",vcmax);print();

if(p==pfin,   print("o = ",o,"  --> ",nextprime(p+1),"# : ",strjoin(2*vc[1..vcmax],", "),", sum = ",2*vecsum(vc),", time cg : ",strtime(getwalltime()-tz1));
);
);

for(ll=1,#cg-1,cg[ll+1]+=2*vc[ll]);
print();print();
o++;);
print();print(#cg,"  cg = ",cg, "    ",vecsum(cg));
print();
print("time: ",strtime(getwalltime()-tz1));
print();print();





print(); tz2=getwalltime();

\\pfin=31; pn=nextprime(pfin+1); \\37*2 = 74

g2=vector(#vco+1);

\\ 2-76 ... 14-88 18-92 ... 26-100 32-106 34-108 \\ 36-110

\\do=[2,4,6,8,10,14,18,20,22,24,26,32,34];

do=setminus(vector((v0[#v0]-2-2*pn)/4,i,i*2),Set(v0));
do=setminus(Set(do),Set(vector(11,i,v0[12-i]-2*pn)));

print();
print(#do,"  do = ",do);
\\print(#ddo," ddo = ",ddo);
print();

for(o=1,#do,

v=[0, 12, 30, 42, 54, 72, 90, 102, 114, 132, 144, 2, 2+2*pn];

v[12]=do[o];
v[13]=do[o]+2*pn;

a=setminus(vector(v[#v-2]/2,i,i*2),Set(v));

\\a=a[1..60];

ww=vector(v[#v-2]/2+3-#v+2,i,Map()); mapput(ww[#ww],2^#a-1,1);

\\print(#a," a = ",a);
\\print();

forprime(p=2, pfin,

m=setminus(vector(p,i,i-1),Set(-v%p));
am=vecextract(vector(p-1,i,fromdigits(Vecrev(apply(t->(t+i)%p>0,a)),2)),m);

   for(k=1,#ww,
      rr=Map();
      foreach(ww[k],m,
         b=m[1][1]; qq=m[1][2]; qn=0;
         foreach(am,x,
            y=bitand(x,b);
            if(y==b, qn+=qq; next);
            hy=hammingweight(y)+1; nn=0;
            if(mapisdefined(ww[hy],y,&nn), nn+=qq , nn=qq);
            mapput(ww[hy],y,nn);
         );
         if(qn>0, mapput(rr,b,qn); );
      );
      ww[k]=rr;
   );
   vc=vector(#ww); for(k=1,#ww, foreach(ww[k],x, vc[k]+=x[1][2]; ); );
   vcmax=#vc; while(vcmax>1&&vc[vcmax]==0, vcmax--);

\\print();print("vcmax = ",vcmax);print();

if(p==pfin,   print("o = ",o,"  --> ",nextprime(p+1),"# : ",strjoin(2*vc[1..vcmax],", "),", sum = ",2*vecsum(vc)", time g2: ",strtime(getwalltime()-tz2));
);
);

for(ll=1,#g2-2,g2[ll+2]+=2*vc[ll]);
print();print();
);


print();print(#g2,"  g2 = ",g2, "    ",vecsum(g2));
print();
print("time: ",strtime(getwalltime()-tz2));
print();


\\ sum = 27648000

\\print();
\\print(#vco," ",vco);
\\print();

rp = pn-#v0+1;

for(i=1,#vco-1,

vc[i] =

(rp-i)*vco[i] + i*vco[i+1]
+       cg[i] -    cg[i+1]
+       g2[i] - 2* g2[i+1] + g2[i+2]);

vc  = vc[1..#vco];
vco = vc;

print();
print("vc  -->  ",pn,"# : ",vc,"      ",vecsum(vc));
print();
print();
print("time: ",strtime(getwalltime()-tz0));
print();
print();
);
print();

}quit;

Да, демонстративно мало памяти взял. И, тем не менее считается всё, а не только 8 правых, как тогда.

У меня считалась 5 часов 22 минуты от 31# до 71#. Предлагаю Вам запустить и сравнить времена со старыми:

Dmitriy40 в сообщении #1638057 писал(а):
31#: 15,624 ms
37#: 1min, 50,439 ms
41#: 6min, 36,976 ms
43#: 15min, 24,531 ms
47#: 24min, 4,339 ms
53#: 30min, 33,017 ms
59#: 34min, 37,949 ms
61#: 35min, 28,376 ms
67#: 37min, 26,759 ms
71#: 37min, 24,168 ms
73#: 37min, 54,155 ms
Общее время 4ч22м

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

Схема обсчёта только через vc[]. Третья строка сокращена.

Код:
   vc31
2*(vc[+2*37] + vc[+12+2*37] + vc[+30+2*37] + vc[+42+2*37] + vc[+54+2*37])
2*(vc[+4]+vc[+6]+vc[+10]+vc[+18]+vc[+22]+vc[+24]+vc[+13])
=
   vc37
2*(vc[+2*41] + vc[+12+2*41] + vc[+30+2*41] + vc[+42+2*41] + vc[+54+2*41])
2*(vc[+2,+2+2*41]+vc[+14,+14+2*41]+vc[+18,+18+2*41])
=
   vc41
2*(vc[+2*43] + vc[+12+2*43] + vc[+30+2*43] + vc[+42+2*43] + vc[+54+2*43])
2*(vc[+6,+6+2*43]+vc[+10,+10+2*43]+vc[+24,+24+2*43])
=
   vc43
2*(vc[+2*47] + vc[+12+2*47] + vc[+30+2*47] + vc[+42+2*47])
2*(vc[+2,+2+2*47]+vc[+6,+6+2*47]+vc[+14,+14+2*47]+vc[+18,+18+2*47]+vc[+24,+24+2*47])
=
   vc47
2*(vc[+2*53] + vc[+12+2*53] + vc[+30+2*53])
2*(vc[+2,+2+2*53]+vc[+6,+6+2*53])
=
   vc53
2*(vc[+2*59] + vc[+12+2*59])
2*(vc[+2,+2+2*59]+vc[+6,+6+2*59])
=
   vc59
2*(vc[+2*61] + vc[+12+2*61])
2* vc[+4,4+2*61]
=
   vc61
2* vc[+2*67]
2* vc[+4,4+2*67]
=
   vc67
2* vc[+2*71]
2*0
=
   vc71
2*0
2*0
=
   vc73 OK

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение15.05.2024, 12:44 
Заслуженный участник


20/08/14
11775
Россия, Москва
Yadryara в сообщении #1639206 писал(а):
Да, демонстративно мало памяти взял.
Могли вообще не брать: все массивы короткие, а на Map() ограничение не распространяется.

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение15.05.2024, 14:56 
Заслуженный участник


20/08/14
11775
Россия, Москва
Мне кажется в программе делается много повторных вычислений. Например посмотрим на do[] для 37# и 41#:
13 do = [2, 4, 6, 8, 10, 14, 18, 20, 22, 24, 26, 32, 34]
11 do = [2, 4, 6, 10, 14, 16, 18, 22, 24, 26, 28]
При том что каждый раз всё считается с 2 и до 31 или 37, очевидно что для 37 можно частично пользоваться уже посчитанными ww[] для 31 и не считать их заново с 2 по 31, из 11-ти штук с начала надо считать лишь два новых значения [16,28], остальные все уже насчитаны до 31.

А если вдруг do=[8,20,32,34] больше ни для каких простых не встретятся (не проверял, но вдруг), то и считать ww[] для 31 не нужно, ведь сами ww[] нам не нужны, нужен vc[], а его легко получить из предыдущего ww[] (для меньшего простого, в данном случае 29). Это сэкономит больше память чем скорость.

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение15.05.2024, 15:22 
Аватара пользователя


29/04/13
8118
Богородский
Я как раз и не сумлевался :-) , что Вы найдёте как улучшить.

Dmitriy40 в сообщении #1639210 писал(а):
Могли вообще не брать: все массивы короткие, а на Map() ограничение не распространяется.

Ах, да... Среда. Из той же песни.

Yadryara в сообщении #1639206 писал(а):
2*(vc[+4]+vc[+6]+vc[+10]+vc[+18]+vc[+22]+vc[+24]+vc[+13])

Опечатка. В конце +vc[+34]

В программе этой ошибки нет, кстати. Так что последняя версия (которую выложил) отработала и быстрее (4 часа 47 минут) и точнее.

Код:
   vc47
2*(vc[+2*53] + vc[+12+2*53] + vc[+30+2*53])
2*(vc[+2,+2+2*53]+vc[+6,+6+2*53])
=
   vc53


Вот эта запись означает, что для того чтобы посчитать vc[] для 53#, зная vc[] для 47#, нужно добавить в паттерн 11-144 ещё одно число равное $2\cdot53$. Затем посчитать для нового паттерна vc[] для 53#,
Снова добавить в паттерн 11-144 ещё одно число равное $12+2\cdot53$. Затем посчитать уже для этого нового паттерна vc[] для 53#.
Снова добавить в паттерн 11-144 ещё одно число равное $30+2\cdot53$. Затем посчитать уже для этого нового паттерна vc[] для 53#.

И по эти трём vc-шкам вычислить cg для паттерна 11-144 для 53# :

Код:
cg_53 = 2*(vc[+2*53] + vc[+12+2*53] + vc[+30+2*53])

Для третьей строки аналогично, только в паттерн 11-144 добавляем не одно число, а два. И по другим двум vc-шкам вычисляем g2 для паттерна 11-144 для 53# :

Код:
g2_53 = 2*(vc[+2,+2+2*53]+vc[+6,+6+2*53])

Теперь имеем:

Код:
   vc_47
   cg_53
   g2_53

Ну и дальше по формуле, где значения стоят в тех же строках

Код:
for(i=1,#vco-1,

vc[i] =

(rp-i)*vco[i] + i*vco[i+1]
+       cg[i] -    cg[i+1]
+       g2[i] - 2* g2[i+1] + g2[i+2]);

Получаем искомый vc[] для 53#.

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение15.05.2024, 15:24 
Заслуженный участник


20/08/14
11775
Россия, Москва
Программу запустил (исходную вашу, без коррекций кроме косметических), пока времена следующие (каждое отдельно, не с самого начала):
37#: 18,167 ms
41#: 2min, 42,333 ms
43#: 7min, 48,500 ms
47#: 16min, 35,253 ms
53#: 17min, 8,220 ms
Пока ускорение раза в 1.5-2.

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение15.05.2024, 17:17 
Аватара пользователя


29/04/13
8118
Богородский
Как же здорово! А я уже почти смирился, что выигрыша по скорости не будет, а будет только по памяти.

Дальше надо будет либо дозатачивать прогу под $\frac16$ диаметра, либо пытаться считать от четверти диаметра тот же 19-252. Ведь vc-шки есть и для 61# и для 67#. То есть удлинять ещё больше паттерны и смотреть будут ли работать какие-нибудь формулы.

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение15.05.2024, 17:55 
Заслуженный участник


20/08/14
11775
Россия, Москва
Прога досчитала до 71 и вылетела по ошибке в do=setminus(...), там размер vector стал отрицательным. Хотя наверное g2[] для 73# уже и не нужен и считать не надо ...
Времена:
37#: 18,167 ms
41#: 2min, 42,333 ms
43#: 7min, 48,500 ms
47#: 16min, 35,253 ms
53#: 17min, 8,220 ms
59#: 34min, 49,300 ms
61#: 24min, 26,304 ms
67#: 28min, 28,202 ms
71#: 36min, 1,116 ms
Итого 2ч48м. Вместо 3ч44м. На треть быстрее.
Экономия памяти где-то на порядок (точнее не измерял).

 Профиль  
                  
 
 Re: кортежи последовательных простых. ключ к 19-252
Сообщение15.05.2024, 18:28 
Аватара пользователя


29/04/13
8118
Богородский
Dmitriy40 в сообщении #1639216 писал(а):
Мне кажется в программе делается много повторных вычислений. Например посмотрим на do[] для 37# и 41#:
13 do = [2, 4, 6, 8, 10, 14, 18, 20, 22, 24, 26, 32, 34]
11 do = [2, 4, 6, 10, 14, 16, 18, 22, 24, 26, 28]
При том что каждый раз всё считается с 2 и до 31 или 37, очевидно что для 37 можно частично пользоваться уже посчитанными ww[] для 31 и не считать их заново с 2 по 31, из 11-ти штук с начала надо считать лишь два новых значения [16,28], остальные все уже насчитаны до 31.

Погодите, но ведь все паттерны-то разные. do-шки как раз и определяют ДОполнение к основному паттерну. А разные паттерны — разные ww[]. Разве нет?

Dmitriy40 в сообщении #1639242 писал(а):
Прога досчитала до 71 и вылетела по ошибке в do=setminus(...), там размер vector стал отрицательным. Хотя наверное g2[] для 73# уже и не нужен и считать не надо ...

g2[] для 71# уже не нужен, он уже нулевой. А для 73# и cg[] и g2[] оба нулевые и не нужны. И я ведь вроде задал окончание счёта на 71#:

forprime(pfin=31,precprime(v0[#v0]/2),

А, понял, надо было ещё на шаг раньше тормозить, когда pfin=67, а pn=71.

Dmitriy40 в сообщении #1639242 писал(а):
Итого 2ч48м. Вместо 3ч44м. На треть быстрее.
Экономия памяти где-то на порядок (точнее не измерял).

Здорово.

 Профиль  
                  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 1076 ]  На страницу Пред.  1 ... 31, 32, 33, 34, 35, 36, 37 ... 72  След.

Модераторы: Модераторы Математики, Супермодераторы



Кто сейчас на конференции

Сейчас этот форум просматривают: YandexBot [bot]


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group