Зачем же паттерн, который рассчитан на длину ровно 11 дополнять до длины 15 ?
Я же дважды сказал зачем: компилятор ускорителей Yadryara6.gen.gp по неизвестной причине считает что в паттернах без 9 на краю для 3 допустимы
два остатка и потому не берёт шаг в 6 раз больше вычисленного, а лишь вдвое. Это или глюк в нём, или я неправильно понимаю когда остатки недопустимы (или и то и другое). Попробуйте сами скомпилить и посмотреть на список остатков и на получаемое ускорение (оно же выводится в строке "Blocks=") с 9 на краю и без неё. Работать будет и так и так, но с разной скоростью.
А не будет ли существенной потери по скорости из-за работы с более длинным массивом?
Существенной не будет. Несущественной скорее всего тоже. Торможение будет только в момент вывода в лог, где будут считаться numdiv от всего массива и не раньше, а это происходит даже не каждую минуту, что ниже случайных флуктуаций. В остальных местах длина массива ни на что не влияет (хоть сколько нибудь заметно).
Асм-код под 15-шку заточен и для укорачивания до 11-ти без его переписывания теперь уже не обойтись?
Не асм код, а компилятор на PARI таблиц для него. И не под 15-ку, а под 6-ти кратное ускорение вместо двухкратного. Работать будет по любому, просто медленнее. Повторю, может это даже и не глюк а лишь моё непонимания что так и должно быть ...
Придётся искать этот Ваш запрет.
Пока это несложно, всего лишь 140-я страница темы.
То есть из 13-ти паттернов, Вы считаете допустимыми 11? Или меньше?
Да, вроде бы для остальных 11-ти штук не вижу запретов. Впрочем детально не проверял, не вижу даже принципа по которому они могут запрещаться (по модулям же проходят).
А вот и расширенная схема. Одинаковые остатки стоят вплотную.
Все от
и больше мною запрещены или проверены, на той самой 140-й странице темы. Меньшие тоже, но там остаются некоторые сомнения из-за использования вольфрамальфа.
Тестировать-то надо.
Для этого достаточно пары-тройки паттернов.
Предлагааю пока не запускать новых расчетов, пока не будет готова система паттернов.
Иначе потом запутаемся, где считать, где не считать, а где была рыба завернута.
Да, и поэтому тоже не тороплюсь компилировать выложенные паттерны. Тем более независимого их подтверждения пока нет, только по 6-ти паттернам с пятёрками. Хотелось бы всё же согласия что да, всё верно, а не каждый сам себе по списочку.
А вот с остальными расположениями
у меня продолжаются сложности с вопросом - различать паттерны при "сдвиге окна" или не различать
Если сдвиг проверяемых мест не вылазит за 15-ку, то не различать, потому что проще проверять именно сразу все 15 чисел (точнее центральные 7-9) и при нахождении кандидата (непрерывного центрального куска) расширять цепочку куда расширится. Но надо аккуратно выделить центральный кусок, чтобы он перекрывал все допустимые паттерны со сдвигами. Для центральных 7-ми чисел можно даже не выделять "11-с-краю", они включаются в общую картину и будут расширены правильно, но так слишком мало проверяемых мест в них остаётся, что нехорошо.
Скажите, пожалуйста, правильно ли понимаю, что если в ускорителях не проходит проверку хотя бы одно проверяемое число, то дальнейшая проверка останавливается и кандидат "выкидывается"?
Да, разумеется. Зачем проверять дальше точно не подходящую цепочку. На этом принципе и основана высокая скорость ускорителей.
Если да, то - можно ли переделать так, чтобы
а) кандидат выкидывался, только если не проходят определенные проверяемые числа,
б) а если не прохордят другие проверяемые (в ускорителях) числа, то это бы запоминалось, но дальнейшая проверка продолжалась бы.?
Не знаю. Можно наверное, но это приведёт как минимум к страшной потере скорости, ведь вместо быстрого отбрасывания 99% цепочек (уже по первым десяткам проверок буквально за несколько тактов CPU) они будут проходить дальше и их придётся каждую проверять дольше. Это если даже не вспоминать что это всё ещё надо придумать как сделать и отладить код (чем мне откровенно не хочется заниматься). Сейчас мне интереснее реализовать подход Hugo к перебору паттернов: добавить лишнее простое в квадрате и за счёт уменьшения шага перебрать быстрее, оценка выше 180ч вместо года впечатлила. Правда для длинных цепочек выигрыш похоже будет меньше, но до них мы пока и не добрались.
Только огромная просьба адаптировать формат изображения паттернов под привычный для нас. Вот три примера:
Только не надо заменять умножение на точку! Есть знак "*", его достаточно. А точка для пустых позиций. Смешивать и и другое под одним символом - неудобно!
Но в каком виде Вам предоставить информацию, чтобы Вы аккуратно перебрали
и
?
Я долго пытался ответить на это, раз 5, но каждый раз погружался в такие дебри, что казалось проще самому сваять программу полного перебора допустимых паттернов, но и там каждый раз возникали трудности (или повторы, или сложно проверить запрет по модулям, или паттерны множились из-за смещения окна).
Самое удобное конечно это сразу дать все v[] длиной ровно 15 и правильно заполненные (даже на "лишних" местах). Но вот как пометить лишние места остаётся вопрос, надо или сразу готовый z[] той же длины, или явно в v[] помечать неиспользуемые места (например сделать коэффициент там отрицательным, но правильным по модулю). А это всё равно ручная работа, только уже Вам. Автоматом у меня пока так и не получается преобразовать v[] к нужному виду и получить из него правильный z[]. Т.е. это очевидно можно, вопрос как это попроще сделать (чтобы среди кучи текста не забыть какие-то редкие варианты).
-- 02.11.2022, 15:05 --Добавлю насчёт вероятности опечаток и ошибок.
Вчера запускал посчитаться два похожих паттерна, выложенных выше 2-4BBBBB и 2-55555, да, даже без 11, и там и там
, но вот оба числа вокруг 32p в первом паттерне встречаются исключительно редко (всего несколько раз на 5e21, разумеется при всех правильных проверяемых местах), а во втором сыпятся десятками в минуту (точно не помню, не сохранил лог, но типа десятки цепочек до 1e19). И это подозрительно! Очень сильная разница для первого паттерна даже между местами 32p-1 и 32p+1, первое во много раз чаще, хотя и там и там малое простое в первой степени, откуда огромная разница то. То ли я где-то ошибся (хотя программа одна и та же, отличаются только паттерны), то ли так и должно быть (ведь в первом 5 проверяемых мест, а во втором 4).
Вот примерно так же и с длиной v[], не вполне уверен глюк это в моем компиляторе (к чему более склоняюсь) или так и должно быть.