|
Последний раз редактировалось wrest 20.05.2026, 12:15, всего редактировалось 1 раз.
А сейчас я взял даже не 1000, а ещё в 10 раз меньше, то есть 100 и это самый лучший результат по скорости. Это для маленьких чисел, чем меньше делитель тем меньше нужно B1. Я вам писал так: Брать надо не так :) Надо брать возрастающие B1, из этой последовательности: [500,520,560,620,700,800,900,1000,1150,1300,1450,1600,1800,2000,2200,2450,2700,2950,3250,3600,4000,4400,4850,5300,5800,6400] Если мало, могу добавить. И делать по 1..3 заходам (rounds). Так мне думается будет оптимальнее. Для тех 270 которые вы уже вычеркнули как ненужные, я бы начинал с B1=800. И это было в контексте факторизации "270 чисел". Для справки, вот вам две таблицы из исходного кода pari/gp
static const ulong TB1[] = {
142,172,208,252,305,370,450,545,661,801,972,1180,1430,
1735,2100,2550,3090,3745,4540,5505,6675,8090,9810,11900,
14420,17490,21200,25700,31160,37780UL,45810UL,55550UL,67350UL,
81660UL,99010UL,120050UL,145550UL,176475UL,213970UL,259430UL,
314550UL,381380UL,462415UL,560660UL,679780UL,824220UL,999340UL,
1211670UL,1469110UL,1781250UL,2159700UL,2618600UL,3175000UL,
3849600UL,4667500UL,5659200UL,6861600UL,8319500UL,10087100UL,
12230300UL,14828900UL,17979600UL,21799700UL,26431500UL,
32047300UL,38856400UL, /* 110 times that still fits into 32bits */
#ifdef LONG_IS_64BIT
47112200UL,57122100UL,69258800UL,83974200UL,101816200UL,
123449000UL,149678200UL,181480300UL,220039400UL,266791100UL,
323476100UL,392204900UL,475536500UL,576573500UL,699077800UL,
847610500UL,1027701900UL,1246057200UL,1510806400UL,1831806700UL,
2221009800UL,2692906700UL,3265067200UL,3958794400UL,4799917500UL
#endif
};
static const ulong TB1_for_stage[] = {
/* Start below the optimal B1 for finding factors which would just have been
* missed by pollardbrent(), and escalate, changing curves to give good
* coverage of the small factor ranges. Entries grow faster than what would
* be optimal but a table instead of a 2D array keeps the code simple */
500,520,560,620,700,800,900,1000,1150,1300,1450,1600,1800,2000,
2200,2450,2700,2950,3250,3600,4000,4400,4850,5300,5800,6400,
7100,7850,8700,9600,10600,11700,12900,14200,15700,17300,
19000,21000,23200,25500,28000,31000,34500UL,38500UL,43000UL,
48000UL,53800UL,60400UL,67750UL,76000UL,85300UL,95700UL,
107400UL,120500UL,135400UL,152000UL,170800UL,191800UL,215400UL,
241800UL,271400UL,304500UL,341500UL,383100UL,429700UL,481900UL,
540400UL,606000UL,679500UL,761800UL,854100UL,957500UL,1073500UL
};
Первая, TB1, используется для "обычного" ECM. Вторая, TB1_for_stage используется для "предварительного" ECM, а там он запускается если не справился Поллард-Брент. Это возрастающий ряд, и в коде определяется с какого B1 начать. Но в коде pari/gp B1 определяется не по величине ожидаемого делителя, а по величине факторизуемого числа. Если вы заменяете Полларда (в версии авторства Квена) на ECM, то надо тестировать, конечно, какие пары rounds и B1 подойдут лучше всего. Этотбудет зависеть и от условий: если вы постепенно повышаете B1, то начинать с небольших. Если запускаете ECM только один раз, то B1 брать |несколько больше, чтобы захватить и множители подбольше.
|