А как заработает?
Сперва надо определиться вставлять ли новую функцию в ядро или делать в стороне и подключать через паришный install
Затем выяснять как устроена сигнализация в pari/gp чтобы в неё беспроблемно встроиться.
Ну и потом приступать к реализации задуманного.
Т.е. нужно провести R&D :) Для чего нужен специалист, ну или долгое общение с ИИ.
Я спрашивал у Qwen, вот отрывки из его ответа
Цитата:
Поскольку ваша цель — **прерывание долгих вычислений** (например, факторизация, вычисление L-функций и т.д.), вам критически важно, чтобы таймер работал **асинхронно**. То есть он должен прервать вычисление даже внутри встроенных функций ядра PARI, которые не проверяют время в циклах GP.
Подтверждаю предыдущий ответ: **при помощи только `gp2c` это сделать невозможно**. `gp2c` компилирует логику скрипта, но не имеет доступа к системным вызовам установки таймеров с точностью ниже секунды.
Единственный рабочий способ — написать **минимальный C-модуль**, который вызывает системный `setitimer`, и подключить его к GP. Это стандартная практика для расширения функциональности PARI/GP.
Вот готовое решение для Unix-систем (Linux/macOS).
Цитата:
### Почему это работает для прерывания вычислений?
1. **Сигналы:** `setitimer` работает на уровне ядра ОС. Когда время истекает, ОС посылает процессу сигнал `SIGALRM`.
2. **Обработчик PARI:** При старте `gp` регистрирует свой обработчик сигнала `SIGALRM`. Этот обработчик не выполняет код сразу, а устанавливает внутренний флаг или делает `longjmp`, который приводит к выбросу ошибки `"alarm interrupt"`.
3. **Асинхронность:** Это прервет даже функцию `factor()`, `ellinit()` или любую другую встроенную функцию на языке C, которая выполняется долго. Чистый GP-цикл с проверкой `gettime()` так не сможет.
### Важные нюансы
1. **Один таймер:** Как и стандартный `alarm()`, этот таймер одиночный. Вызов `alarm_usec()` сбрасывает предыдущий таймер.
2. **Отмена:** Чтобы отменить ожидающее прерывание (если вычисление закончилось раньше), обязательно вызовите `alarm_usec(0)`.
3. **Вложенность:** Не рекомендуется вызывать эту функцию рекурсивно или из разных потоков (хотя GP однопоточный).
4. **Точность:** Точность зависит от планировщика ОС. Микросекунды поддерживаются, но реальное срабатывание может иметь задержку в несколько миллисекунд под нагрузкой.
Это единственный надежный способ реализовать субсекундный таймаут для прерывания тяжелых вычислений в экосистеме PARI/GP.
Ну как по мне, написано логично.
Промпт:
Цитата:
Можно ли при помощи gp2c создать пользовательскую функцию alarm_usec() в pari/gp которая будет аналогична встроенной alarm() но в качестве аргумента принимать не целые секунды а доли, например микросекунды или миллисекунды? Функция нужна для прерывания долгих вычислений.
-- 06.03.2026, 13:58 --Сейчас ситуация такая, что прогресс в такой проверке может стать очень важным, потому что есть хорошая серия с нулевым количеством простых и полупростых. Шаг в 100 с лишним раз меньше.
То есть, вы уверены, что уменьшение порога прерывания "долгой факторизации" с 1с до 0,1с заметно ускорит вычисления?
04.03.2026, 20:30 
Число 15 является делителем, но не является [простым] множителем числа 12345
Заметно ускорит, конечно. Особенно для длинных цепочек.