Лучший алгоритм факторизации чисел

[wrest]

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

Вот кстати да, PARI/GP же, у меня на компе за 61с.

factorint(n,4+2) - побыстрее немного будет.

[Dmitriy40]

Да, так за 53с.
И похоже делители находит не ECM, а MPQS (разновидность QS, квадратичного решета, которое само разновидность метода Ферма) - если его запретить, то за 4 минуты не может разложить, а с запрещённым ECM (8+4+2) раскладывает за те же 53с.
Да, в режиме отладки прямо видно что разложило именно MPQS.

-- 25.11.2025, 23:48 --

Skipper
Ну вот, а Вы ECM лучший, ECM ...

[Skipper]

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

Ну вот, а Вы ECM лучший, ECM

Ну так это известно, что ECM лучший, если у числа не два делителя примерно одинаковой длины. А хотя бы до кубического корня..

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

[Skipper]

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

Хороший вот этот: https://www.alpertron.com.ar/ECM.HTM - ввести число (или несколько), нажать кнопку Factor

Ну вот ввёл 256-битное полупростое число, 78 цифр в десятичной записи, делители 39-значные.
Что он делает методом эллиптических кривых? Гоняет по порядку, с такими $B_1 $ и $B_2 $,
что судя по надписям "15-digit level" , "16-digit level" , "17-digit level" , и т.д.,
пытается найти короткие делители.
Дойдя до "25-digit level" , гоняет уже целый час эллиптические кривые, уже 192-я,
судя по надписи
"Curve 192 using bounds B1=50000 and B2=5000000".

А какой смысл гонять их 192 элл.кривых подряд, если 25-значный делитель он всё равно не найдёт?

Нужно сразу выбрать режим, с такими $B_1 $ и $B_2 $,
чтобы сразу и искать до 39-значных делителей,
а не тратить время на попытки найти все менее короткие?

Выходит, что время тратит впустую, или я тут что-то недопонимаю, в этих записях?

PS Не дойдя до поиска "26-digit level" , переключился на метод SIQS , разновидность
квадратичного решета. Выходит не проблема в алгоритме ECM, а проблема
что он впустую неправильно его использует? Если сразу выбрать бОльшие
B1 и B2 и искать вплоть до 39-значных делителей, тогда и был бы смысл сравнивать
ECM с SIQS .

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

Ну вот, а Вы ECM лучший, ECM ...

Так что, возможно, не совсем корректно тут сравнивать ECM с SIQS .
Этот алгоритм ищет до корня кубического примерно, а надо сразу до квадратного.
И это впустую идёт, почему выбрал порядка ~200 эллиптических кривых, тоже неясно.

[Dmitriy40]

Skipper в сообщении #1711701 писал(а):

Выходит, что время тратит впустую, или я тут что-то недопонимаю, в этих записях?

А откуда ему знать что число полупростое? Вдруг там больше двух простых делителей? Вот он и пытается их найти более быстрым методом. Или Вам так жалко потратить лишние 5%-10% времени?

Skipper в сообщении #1711701 писал(а):

Нужно сразу выбрать режим, с такими $B_1 $ и $B_2 $, чтобы сразу и искать до 39-значных делителей, а не тратить время на попытки найти все менее короткие?

Это будет сильно дольше чем с меньшими B1 и B2. Сравните скорость перебора кривых с разными В1,В2. А если не полупростое, то выгоднее попытаться найти меньший делитель.

Skipper в сообщении #1711701 писал(а):

Этот алгоритм ищет до корня кубического примерно, а надо сразу до квадратного.

До квадратного ECM будет искать на порядок дольше QS. Т.е. Вам жалко десяток процентов времени на предварительный ECM в надежде что число не полупростое, но не жалко потратить в десятки раз больше времени на ECM до квадратного корня?! Вы уж определитесь чего Вам больше жалко.

Или пользуйтесь программами, позволяющими пропустить ECM предпроверки (и работать многопоточно), например YAFU.

[Skipper]

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

Это будет сильно дольше чем с меньшими B1 и B2. Сравните скорость перебора кривых с разными В1,В2. А если не полупростое, то выгоднее попытаться найти меньший делитель.

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

Вам жалко десяток процентов времени на предварительный ECM в надежде что число не полупростое, но не жалко потратить в десятки раз больше времени на ECM до квадратного корня

Интересных 2 вопроса..

Может быть там и не десяток процентов. Потому что, если бы он сразу выбрал нужные B1 и B2,
в надежде найти 39-значный делитель, то нашёл бы его с первой (или допустим, со второй, третьей, но небольшим количеством) эллиптических кривых, а 25-значный делитель он ищёт, гоняя аж примерно 200 эллиптических кривых.

1) Неужели 200 кривых - это десяток процентов, а одна или две такие кривые, с большими B1 и B2, это 90 процентов времени?

И вообще, откуда это 200 взялось?
2) Какова вероятность того, что взяв произвольную эллиптическую кривую,
и нужные B1 и B2, для нахождения делителя произвольной длины N, если таковой имеется,
вероятность того, что мы найдём на этой произвольной эллиптической кривой, этот делитель?
Если он гоняет 200 кривых, то что получается, вероятность эта может доходить до 0,5% ?

Вот нигде, во всех описаниях алгоритма методом эллиптических кривых, я не встречал данных,
именно о вероятности найти делитель взяв произвольную эллиптическую кривую!
А ведь это важнейший вопрос. Я конечно, когда реализую свой алгоритм, то проведу всевозможный
статистический анализ. Но было бы неплохо, чтобы о таких вероятностях писали в учебниках и
статьях.

Есть оптимальные B1 и B2, для длины делителя, который мы хотим найти, допустим это 39-значный
в десятичной системе, делитель. Брать больше этих оптимальных B1 и B2, допустим, нет смысла,
потому что неоправданно больше растёт время поиска, при незначительном увеличении вероятности.
И вот, какова вероятность найти, если взяли оптимальные B1 и B2 ?

И подозреваю, что параметры эллиптической кривой, если выбирать не совсем рандомно, а
по каким-то критериям, в зависимости от раскладываемого числа, то эту вероятность можно
существенно увеличить!
Таким образом мы бы существенно оптимизировали этот метод эллиптических кривых,
выбирая сразу правильные параметры этой кривой, был бы улучшенный, или другими словами,
"обобщенный метод эллиптических кривых", (Generalized Elliptic Curve Method), GECM,
с трудоёмкостью алгоритма, меньшей чем у QS, квадратичного решета.
И это был бы универсальный и самый лучший алгоритм.

Что думаете по этому поводу?
А чтобы выбирать сразу хорошие параметры для эллиптической кривой, нужно будет провести
другие статистические анализы, например реализовав и прогнав часть расчётов по другим алгоритмам,
может для такого статистического анализа, придётся частично тот же QS провести,

-- Пт дек 05, 2025 14:51:31 --

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

Ещё два алгоритма Полларда (Р и Р-1), они могут находить делители намного быстрее ECM.

Видимо, имелись в виду, 1) Ро-алгоритм Полларда, и 2) (P-1) алгоритм Полларда.
Однако, 1) Ро-алгоритм Полларда, работает быстрее чем ECM, только в случае, если есть делители,
совсем уж небольшие по размеру.
2) (P-1) алгоритм Полларда, так же как и (P+1) метод Вильямса, работают быстрее, только в случае,
если есть делители, которые не сильно простые числа, то есть такие что рядом лежащие числа
(p-1 ,и p+1) не имеют больших простых чисел в разложении (достаточно "гладкие").

Если взять большое рандомное простое число, то вероятность того что оно будет сильно простым,
я так понимаю, будет мала, потому что "среднестатистические" максимальные делители рядом
лежащих чисел, будут расти с ростом этого рандомного простого числа.
Хочу в будущем, провести такой статистический анализ, чтобы это доказать.

Потому, все эти методы, , 1) Ро-алгоритм Полларда, и 2) (P-1) алгоритм Полларда, 3) (P+1) метод Вильямса,
могут работать быстрее чем ECM только на очень небольшом наборе чисел,
да и то, вряд ли намного быстрее, потому ECM я и считаю, одним из лучших, универсальных алгоритмов.

Можно ещё привести пример алгоритма Ферма- тот вообще находит быстро, только если делители,
ненамного отличаются друг от друга, почти как "числа-близнецы", с разностью как у Итан Чжана,
в 70 миллионов, к примеру.
(не совсем корректно их называть близнецами, т.к. по определению, близнецы, должны иметь разность 2).
Ну, вероятность просто ничтожна, если мы возьмем рандомное число, что у него
окажутся настолько близко друг от друга делители.
Итак, все эти методы, почти никогда не сработают, если мы возьмем рандомные большие числа,
где ECM - сработает, и будет быстрейшим алгоритмом.

[Dmitriy40]

Skipper в сообщении #1711741 писал(а):

Что думаете по этому поводу?

Я думаю что это всё уже обсуждалось. Правда не помню в какой теме.
И ещё думаю что читать удобнее без лишних разбивок на строки.

Skipper в сообщении #1711741 писал(а):

Потому что, если бы он сразу выбрал нужные B1 и B2,
в надежде найти 39-значный делитель, то нашёл бы его с первой (или допустим, со второй, третьей, но небольшим количеством) эллиптических кривых,

С чего бы? Он что, реально нашёл буквально с 1-2-3-й кривой для 40-значных делителей? А если нет, то на чём основана ваша уверенность что нашёл бы?

Skipper в сообщении #1711741 писал(а):

1) Неужели 200 кривых - это десяток процентов, а одна или две такие кривые, с большими B1 и B2, это 90 процентов?

А взять секундомер и замерить вам конечно религия мешает? Я вот помню что каждая смена B1,B2 замедляет перебор кривых раза в 3-4, т.е. разница между 25-значными и 40-значными будет раз в 30-60. Да ещё и кривых станет больше примерно вдвое на каждый шаг, т.е. раз в 7-10. Суммарно скорость упадёт раз в 200-500. Это очень "на глаз", не замерял.

Skipper в сообщении #1711741 писал(а):

И вообще, откуда это 200 взялось?

Отсюда (цитата по readme к одной из программ ECM):

Используется синтаксис Text

The ECM method is a probabilistic method, and can be viewed in some sense
as a generalization of the P-1 and P+1 method, where we only require that
P+t+1 is smooth, where t depends on the curve we use and satisfies
|t| <= 2*P^(1/2) (Hasse's theorem). The optimal B1 and B2 bounds have
to be chosen according to the (usually unknown) size of P. The following
table gives a set of nearly optimal B1 and B2 pairs, with the corresponding
expected number of curves to find a factor of given size (column "-power 1"
does not take into account the extra factors found by Brent-Suyama's exten-
sion, whereas column "default poly" takes them into account, with the poly-
nomial used by default: D(n) means Dickson's polynomial of degree n):

       digits D  optimal B1   default B2           expected curves
                                                       N(B1,B2,D)
                                              -power 1         default poly
          20       11e3         1.9e6             74               74 [x^1]
          25        5e4         1.3e7            221              214 [x^2]
          30       25e4         1.3e8            453              430 [D(3)]
          35        1e6         1.0e9            984              904 [D(6)]
          40        3e6         5.7e9           2541             2350 [D(6)]
          45       11e6        3.5e10           4949             4480 [D(12)]
          50       43e6        2.4e11           8266             7553 [D(12)]
          55       11e7        7.8e11          20158            17769 [D(30)]
          60       26e7        3.2e12          47173            42017 [D(30)]
          65       85e7        1.6e13          77666            69408 [D(30)]

          Table 1: optimal B1 and expected number of curves to find a
          factor of D digits with GMP-ECM.

After performing the expected number of curves from Table 1, the
probability that a factor of D digits was missed is exp(-1), i.e.,
about 37%. After twice the expected number of curves, it is exp(-2),
i.e., about 14%, and so on.

Example: after performing 8266 curves with B1=43e6 and B2=2.4e11
(or 7553 curves with -dickson 12), the probability to miss a 50-digit
factor is about 37%.

Skipper в сообщении #1711741 писал(а):

2) Какова вероятность того, что взяв произвольную эллиптическую кривую,
и нужные B1 и B2, для нахождения делителя произвольной длины N, если таковой имеется,
вероятность того, что мы найдём на этой произвольной эллиптической кривой, этот делитель?

Есть в цитате выше.

Skipper в сообщении #1711741 писал(а):

Есть оптимальные B1 и B2, для длины делителя, который мы хотим найти, допустим это 39-значный в десятичной системе, делитель. Брать больше этих оптимальных B1 и B2, допустим, нет смысла,
потому что неоправданно больше растёт время поиска, при незначительном увеличении вероятности.
И вот, какова вероятность найти, если взяли оптимальные B1 и B2 ?

Тоже есть в цитате выше.

Skipper в сообщении #1711741 писал(а):

И подозреваю, что параметры эллиптической кривой, если выбирать не совсем рандомно, а
по каким-то критериям, в зависимости от раскладываемого числа, то это вероятность можно
существенно увеличить!

Насколько я понимаю зависимости нет или она выводима не проще прямого вычисления точек на кривой, но Вы конечно подозревайте дальше.

Skipper в сообщении #1711741 писал(а):

И это был бы универсальный и самый лучший алгоритм.

Мечтать говорят не вредно.
Попробуйте сделать. Универсально (для любых чисел).
Думаете зря умные люди разработали другие более быстрые алгоритмы?
"Самого лучшего" алгоритма видимо вообще не существует: под разные задачи оптимальными будут разные алгоритмы. Как не существует лучшего алгоритма умножения двух чисел или двух матриц, или деления двух чисел, или извлечения квадратного корня, или проверки числа на простоту, или даже сложения двух чисел (я знаю минимум один не банальный алгоритм в нескольких вариациях, который имеет свою область применения, например он позволил втрое ускорить сложение очень длинных чисел (сотни миллионов знаков) в одной из задач, это офигенно много когда счёт занимает годы).
И да, задача "разложить полупростое число" сильно отличается от задачи "разложить произвольное число" и решаться они могут разными методами.

[Skipper]

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

Я вот помню что каждая смена B1,B2 замедляет перебор кривых раза в 3-4, т.е. разница между 25-значными и 40-значными будет раз в 30-60. Да ещё и кривых станет больше примерно вдвое на каждый шаг, т.е. раз в 7-10. Суммарно скорость упадёт раз в 200-500.

Значит, в среднем если делители есть 25-значные в десятичной системе, по сравнению с поиском 40-значных делителей, скорость упадёт в среднем в 300 раз. Если ищет для 25-значных, (мой чудо-браузер mozilla) 1 час (при факторизуемом числе длиной в 256 бит), то для того чтобы найти 40-значные делители, то есть разложить примерно 256-битное полупростое число, с двумя делителями, примерно одинаковой длины в 40 десятичных цифр, потребуется около 300 часов, то есть 12 суток времени на процессоре с одним ядром в 3 гигагерца?

PS И это одним из лучших алгоритмов, https://www.alpertron.com.ar/ECM.HTM (надеюсь, мой будет не хуже). Ну тогда да, ECM метод существенно медленнее чем SIQS (разновидность квадратичного решета с Self-Initializing стретегией, то есть Self-Initializing Quadratic Sieve), для полупростых чисел, где делители имеют порядок около корня квадратного, то есть в 2 раза меньшей длины в записи, от факторизукмого числа. С другой стороны, если есть делитель порядка корня кубического, то есть в 3 раза меньшей длины в записи, или ещё меньше, (а это очень много случаев если выбираем рандомное большое число), то ECM будет быстрее чем SIQS..

В моём примере, с 256-битным полупростым числом, которое имело 78 цифр в десятичной записи и 39 цифр у каждого простого делителя, если бы были 25-значные делители, что как раз и есть величины порядка корня кубического, он бы нашёл такой делитель примерно за 1 час, но такое же время он позже, отказавшись дальше раскладывать методом ECM, раскладывал тот же 1 час методом SIQS.

-- Пт дек 05, 2025 16:17:01 --

Цитата:

Какие там он ещё алгоритмы копал, не знаю, но разложил на множители он это число только почти за 14 минут.

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

Странно, слишком медленный у Вас комп, у меня справился за 10с на ECM и 43с на SIQS.

Вот тут странно, то число которое я приводил выше, 70-значное с делителями порядка корня квадратного,
по той же логике, SIQS должен был бы у вас разложить быстрее, но быстрее разложил ECM.
Удачную элл.кривую быстро нашёл?
У меня же ECM крутился не 14 минут (позже работал SIQS), но минут 5-7 там точно было у ECM.
Не могу понять, почему такая пропасть с вашими 10 секундами, притом что у меня нормальный процессор,
3 гигагерца, Phenom II 945. Если что-то с браузером,
то мой ECM алгоритм (который я сейчас хочу реализовать) 35-значные делители для 70-значного факторизуемого, должен тоже за 10 секунд находить.
Тогда не всё так плохо- и 78-значное с 39-значными делителями, мой ECM найдёт не за 12 суток,
а за минуты-часы.

-- Пт дек 05, 2025 16:28:54 --

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

это точно не нормально. Может что-то с браузером ...

Да, такой разницы быть не может, точно что-то с браузером. Алгоритм написан на C,
https://www.alpertron.com.ar/ECM.HTM
и браузер его выполняет скомпилировав в asm.js и WebAssembly, может чего то не хватает
для браузера, что можно установить, и тогда работал бы быстрее,

-- Пт дек 05, 2025 16:40:20 --

Недавно смотрел видео, в котором Теренс Тао, спрогнозоровал, что в ближайшие 10 лет,
проблема простых чисел-близнецов, будет частично решена, или будет "продвижение" в этой области.
Там сейчас некий "барьер чётности" мешает продвинуться.
Интересно, верна ли гипотеза Харди-Литтвуда о том, что и вовсе всех нетривиальных плотных
кортежей любой длины, бесконечное количество.
Это доказать скорее всего ещё на порядок труднее..

[Dmitriy40]

Skipper в сообщении #1711748 писал(а):

то для того чтобы найти 40-значные делители, то есть разложить примерно 256-битное полупростое число, с двумя делителями, примерно одинаковой длины в 40 десятичных цифр, потребуется около 300 часов, то есть 12 суток времени на процессоре с одним ядром в 3 гигагерца?

Ну я же очень примерно прикинул, не замерял же, может и в несколько раз меньше.
Замеряйте сами, сколько кривых в каждом диапазоне известно, там можно нажать кнопку More и ввести прямо номер кривой - замерьте секундомером скорость перебора кривых для 25 цифр и для 40 цифр, умножьте на количество и получите более адекватную оценку требуемого времени.
Кроме того, почитайте внимательнее цитату про вероятностность теста ECM, т.е. он делитель может и не найти даже перебрав все кривые в соответствующем диапазоне. А QS и GNFS - найдут гарантированно (правда там тоже есть случаи когда вычисленной матрицы предсказанного размера не хватает и её приходится расширять, но обычно на расширение уходит немного времени, в разы меньше).

Skipper в сообщении #1711748 писал(а):

Ну тогда да, ECM метод существенно медленнее чем SIQS

В вики про QS сказано что для чисел до $10^{19}$ он самый быстрый. Для полупростых видимо ECM всегда хуже QS, хотя для чисел $10^{20\ldots50}$ стоит это аккуратно перепроверить.

Skipper в сообщении #1711748 писал(а):

С другой стороны, если есть делитель порядка корня кубического, то есть в 3 раза меньшей длины в записи, или ещё меньше, (а это очень много случаев если выбираем рандомное большое число), то ECM будет быстрее чем SIQS..

Опять же, зависит от величины чисел, до $10^{19}$ QS быстрее ECM. Возможно для x64 архитектур преимущество QS сохранится до $10^{38}$ (используются числа до корня квадратного, а они влезают в регистры и медленная длинная арифметика не нужна).

Skipper в сообщении #1711748 писал(а):

Если ищет для 25-значных, 1 час (при факторизуемом числе длиной в 256 бит),

Как-то слишком долго вроде, 1ч на 25-digits. У меня комп примерно такой же, 3.5ГГц, так число 88 знаков остатка из $2^{188}-1$ (первое попавшееся) он 25-digit собрался перебирать минут 12 (за 5м перебрал около половины и переключился на QS).

[Skipper]

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

Насколько я понимаю зависимости нет или она выводима не проще прямого вычисления точек на кривой,

Почему так думаете?
В руководстве написано,
"The ECM method is a probabilistic method, and can be viewed in some sense
as a generalization of the P-1 and P+1 method, where we only require that
P+t+1 is smooth, where t depends on the curve we use and satisfies
|t| <= 2*P^(1/2) (Hasse's theorem)"

значит параметры эллиптической кривой зависят от этого t, и нужно найти его таким, чтобы число
$P+t+1$ было достаточно гладким. Может быть есть какие то признаки, и зная
полупростое, из которого путём разложения будет получен делитель $P$ ..

[Dmitriy40]

Skipper в сообщении #1711748 писал(а):

Вот тут странно, то число которое я приводил выше, 70-значное с делителями порядка корня квадратного,
по той же логике, SIQS должен был бы у вас разложить быстрее, но быстрее разложил ECM.
Удачную элл.кривую быстро нашёл?

ECM не разложил, потратил 10с и передал возжи QS, который и разложил.

Skipper в сообщении #1711748 писал(а):

Да, такой разницы быть не может, точно что-то с браузером.

Я уже предлагал взять YAFU и проверить в компе ли дело. Скачать один файл и запустить из командной строки проблемы не вижу.

-- 05.12.2025, 17:51 --

Skipper в сообщении #1711757 писал(а):

Почему так думаете?

Потому и думаю, что ещё никто не сделал. Давало бы большой выигрыш - сделали бы.
Это уже математика, которую я обсуждать не готов (ибо не понимаю).

[Skipper]

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

Как-то слишком долго вроде, 1ч на 25-digits. У меня комп примерно такой же, 3.5ГГц, так число 88 знаков остатка из $2^{188}-1$ (первое попавшееся) он 25-digit собрался перебирать минут 12

Ну так вот я и говорю, что за браузер у меня такой странный.. Ума не приложу.
Пропасть какая то с производительностью вашего браузера

Цитата:

Я уже предлагал взять YAFU и проверить в компе ли дело. Скачать один файл и запустить из командной строки

Да, так и надо сделать,
По вашей ссылке https://download.mersenne.ca/YAFU/v3.00 нельзя скопировать, для процессоров AMD- пишет
"Not found. Please browse from the top."
Может ещё где-то можно найти этот YAFU ? Или другую программу, которая использовала бы
ECM запуская exe, а не в браузере?

-- Пт дек 05, 2025 16:56:57 --

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

Потому и думаю, что ещё никто не сделал.

Ну это не показатель. Уже давно не изобретались алгоритмы лучше чем те что были изобретены 30 лет назад.
Если по такой логике думать, "никто не сделал, значит и не сделают", то не будет прогресса.
Когда то в 1980-х думали, что квадратичное решето- лучший, а как видим, изобрели ещё более быстрый метод GNFS .
То же может случиться и с улучшением ECM, (мой любимый метод, и хочу чтобы его существенно улучшили!)
Чтобы уж точно был не хуже квадратичного решета,

[Dmitriy40]

Skipper в сообщении #1711760 писал(а):

Ну это не показатель. Уже давно не изобретались алгоритмы лучше чем те что были изобретены 30 лет назад.

Как раз это это не показатель - существующие алгоритмы продолжают исследовать и улучшать.
Например про кривые Эдвардса в ECM пишут в 2013.
В архив.орг наверняка есть публикации и последних пары лет ...
Но если Вы изобретёте кардинальное улучшение ECM - превосходно!!
Просто я не верю что трудные задачи можно решить так "с наскока", "пришёл, увидел, победил выдал рабочую (!!) мегаидею". Исключения бывают, но это именно исключения.

[Skipper]

Скачал yafu-2.09-202208111421-win64.exe положил в папку скачанную отсюда
yafu-2.08_2022-03-14.zip
Отсюда https://download.mersenne.ca/YAFU/v2.0x
и у меня windows x64 - exe запускается, и тут же вылетает.
Чего ему надо, непонятно, можно же было в командной строке написать..

[Dmitriy40]

Skipper
Я же писал где взять и более новую версию и как потом запускать:

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

Skipper в сообщении #1710534 писал(а):

Или программу, устанавливаемую на обычный домашний компьютер под Windows.

Процитирую недавнее:

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

Я кстати пару дней назад обнаружил (не могу сказать "нашёл" так как и не искал, но наткнулся) более новую версию YAFU, 3.00 вместо 1.34, у неё два существенных для меня плюса: 1) умеет ECM многопоточно, 2) показывает ETA (оставшееся время) для NFS.
Вам не предложил так как для NFS (а это более 95-100 цифр, меньше справляется SIQS) она всё равно требует внешних файлов типа gnfs-lasieve4I11e.exe, с чем у Вас тогда и не получилось. Впрочем ссылку указал, можете снова попробовать (файлы для NFS брать отсюда, не знаю какая версия запустится).

Подробнее и как запускать с примерами написано там же двумя сообщениями ниже, тоже обязательно посмотрите.
Её можно заставить не использовать ECM (ключ -noecm) или не переключаться на QS/GNFS и долбить ECM до упора (не помню как, будет нужно поищу). Отключить предпроверки перед ECM у меня сегодня не получилось.

Или Вы не видите ссылок под словами "более новую версию YAFU" и "отсюда" и "написано там же двумя сообщениями ниже"?

-- 05.12.2025, 18:52 --

У меня не вылетает даже при запуске из проводника:

Используется синтаксис Text

warning: could not open yafu.ini, no options parsed


YAFU Version 3.0
Built with Microsoft Visual Studio 1934 and Intel Compiler 2021
Using GMP-ECM 7.0.6-dev, Powered by MPIR 3.0.0
Detected Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz
Detected L1 = 32768 bytes, L2 = 6291456 bytes, CL = 64 bytes
CPU features enabled: SSE41 AVX2 BMI2
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991
Could not parse yafu.ini from T:\YAFU

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
=======             [e-mail]                   =======
=======     Type help at any time, or quit to quit      =======
===============================================================

>>

И там курсор мигает, можно вводить команды (выход - exit), например factor(2^188-1), раскладывает за 0.2с, хотя альпетрон трудился не меньше 5 минут только ECM, плюс запустил и QS.