В общем, проход по большой таблице, типа 21x10^5 себя не оправдывает.
Скорость прохода включая создание таблицы, заполнение, и определение отбрасываемых цепочек, составила ~336 тыс/сек, что близко к интегральной скорости при последовательной проверке каждой цепочки (с терапевтикой, табличным отсевом и финальными numdiv-ами) . При этом отсев только 62% (т.е. в 38% переполнения не случилось - это при простых до 2^20) и дальше копать смысла нет. Главная проблема - векторы векторов и матрицы это длинные числа, их нельзя или я не понял как, объявить как small в gp2c.
Сам проход по ткблице при этом около ~1млн/сек, но её подготовка и главное последующий анализ, портят скорость. Я делал вычитание единицы для каждого простого на которое разделилось, из предзаполненного ожидаемого количества множителей, раньше называлось nu, например тут:
post1711535.html#p1711535nu=[3, 2, 3, 3, 3, 3, 3, 2, 4, 3, 4, 3, 3, 3, 3, 2, 3, 3, 3, 3, 3];
\\Сколько разных простых делителей должно быть в каждой позицииТак что после окончания прохода по таблице смотрел чтобы vecmin по цепочке был неотрицательный (такие фильтр прошли и надо крякать их ispseudoprime-ом и далее по списку).
Можно ещё заранее думать что если множителей набралось сколько надо, то ос этавшееся частное точно составное, но цепочка D(48,21) таких чисел, где частное простое, имеет более одного.
-- 30.03.2026, 21:05 --Значит есть разница в типах между PARI/GP и gp2c и тогда говорите точнее про что имеете в виду.
Ну так мы ж тут на скорость пишем :)
Поэтому после proof of cocept, в итоге всё заканчивается трансляцией в gp2c
Жаль конечно что в pari/gp не завезли Сишные массивы двумерные.
30.03.2026, 20:16 