интерактивный курс: введение в программирование на PARI/GP

[Dmitriy40]

iifat
Да, действительно, как-то не обратил внимания на фразу "The output is normalized so that an ≠ 1 (unless we also have n = 0).", значит и правда усекает (нормализует). Спасибо. Этот вопрос будем считать разъяснился. Тогда округление ни при чём, я боялся из-за него ошибается при разложении.

Про периодичность разложения помню, но не вижу чем может помочь.

[iifat]

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

не вижу чем может помочь

Ну, если использовать PARI/GP или чего-нить вроде, наверное, ничем; если взять общецелевой язык программирования, можно вычислить период и клепать подходящие до необходимой точности.

[Dmitriy40]

А, вот чем ... Ну там пока для всех проверенных чисел достаточно 12 членов цепной дроби, периоды же корней часто намного больше, потому заметного выигрыша не будет. Но здесь в теме хотелось бы в контексте PARI/GP что-нибудь.

[wrest]

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

Но здесь в теме хотелось бы в контексте PARI/GP что-нибудь.

Может вам заглянуть в исходный код функций?

[Dmitriy40]

wrest в сообщении #1490383 писал(а):

Может вам заглянуть в исходный код функций?

А толку? Ну заглянул, там классика, алгоритм Евклида для разложения в цепную дробь и рекуррентная формула Эйлера для получения подходящий дробей. На С я и сам могу написать, надеялся есть что-то встроенное готовое или трюк какой.

[Dmitriy40]

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

[wrest]

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

И что с этим делать?

Я бы посоветовал спросить напрямую в pari-users (см. https://pari.math.u-bordeaux.fr/lists.html ), разработчики отзывчивые.

(Оффтоп)

Не примите за троллинг, но может попробовать
- компилировать и запускать в linux subsystem for windows
- устанавливать из репозиториев готовое в linux subsystem for windows
Это лучше тем, что в пакете для windows что-то сильно сломано в работе readline/ncurses (у меня по крайней мере) - редактировать ранее введенные команды просто мучение какое-то.
К тому же, может у вас попутно починится и проблема с производительностью 64-бит версии.

[wrest]

Dmitriy40
P.S. К тому же, в linux subsytem for windows, pari/gp работает многопоточно.
Например команда v=pareval(vector(200,i,()->factor(2^i+1)[1,1])); (не знаю что она делает и зачем :) ) грузит все 4 ядра/8 потоков ноутбучного i7-8565U на 100%.

v=eval(vector(200,i,()->factor(2^i+1)[1,1])); выполняется 12 секунд, загрузка CPU 30%
v=pareval(vector(200,i,()->factor(2^i+1)[1,1])); выполняется 4 секунды, загрузка CPU 100%

Встроенный таймер (##) в обоих случаях показывает 12 секунд, кстати.

[Dmitriy40]

Отмечу что с версий 2.11.1 стали собирать вариант gppthread64-readline-2-xx-x с поддержкой указанной многопоточности под x64 виндой без всяких сторонних библиотек, сразу "из коробки".
Но меня не впечатлило, ускорение менее чем вчетверо (я видел втрое при 100% загрузке всех 4-х ядер), и далеко не везде, и надо специально дорабатывать код. Так что для себя решил что скорее баловство, что-то по быстрому посчитать и так достаточно, а иначе напишу на нормальном языке. Но кому-то будет полезно.
Ваш пример:

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

C:\>gppthread64-readline-2-13-0.exe
Reading GPRC: gprc.txt
GPRC Done.

                                                                         GP/PARI CALCULATOR Version 2.13.0 (released)
                                                                 amd64 running mingw (x86-64/GMP-6.1.2 kernel) 64-bit version
                                                                 compiled: Oct 19 2020, gcc version 8.3-posix 20190406 (GCC)
                                                                                  threading engine: pthread
                                                                        (readline v8.0 enabled, extended help enabled)

                                                                            Copyright (C) 2000-2020 The PARI Group

PARI/GP is free software, covered by the GNU General Public License, and comes WITHOUT ANY WARRANTY WHATSOEVER.

Type ? for help, \q to quit.
Type ?17 for how to get moral (and possibly technical) support.

parisize = 8000000, primelimit = 51000000, nbthreads = 4
? v=pareval(vector(200,i,()->factor(2^i+1)[1,1]));
cpu time = 8,782 ms, real time = 2,997 ms.
? v=eval(vector(200,i,()->factor(2^i+1)[1,1]));
cpu time = 8,753 ms, real time = 8,788 ms.
? \q
Goodbye!

Ускорение снова менее трёх раз, на 4-х ядрах.
Для сравнения та же процедура на gp32 и gp64:

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

                                                                         GP/PARI CALCULATOR Version 2.13.0 (released)
                                                                  i686 running mingw (ix86/GMP-6.0.0 kernel) 32-bit version
? v=pareval(vector(200,i,()->factor(2^i+1)[1,1]));
time = 6,396 ms.
? v=eval(vector(200,i,()->factor(2^i+1)[1,1]));
time = 6,458 ms.

                                                                         GP/PARI CALCULATOR Version 2.13.0 (released)
                                                                 amd64 running mingw (x86-64/GMP-6.1.2 kernel) 64-bit version
? v=pareval(vector(200,i,()->factor(2^i+1)[1,1]));
time = 6,833 ms.
? v=eval(vector(200,i,()->factor(2^i+1)[1,1]));
time = 6,771 ms.

Видно что параллельная версия в одном потоке на треть тормознее обычной, что впрочем понятно, но неприятно.

-- 19.11.2020, 20:14 --

На самом деле проблема шире чем я думал: скачанная с сайта версия 2.11.2, бит-в-бит одинаковая с имеющейся у меня, даже переименованная и скопированная в тот же каталог, требует разрешения, а моя не требует. Замена моего файла на скачанный ничего не меняет, всё равно появляется запрос разрешений. Возможно дело вовсе не в PARI/GP ... Ненавижу эту чрезмерно умную винду!

[dmd]

Dmitriy40
Странно, у себя такого не наблюдаю. В любой версии. И для бинарника из полного пакета Pari64-2-13-0.exe, и для голого бинарника, который у них каждый день новый пересобирается. При этом контроль учетных записей у меня не отключен (ползунок в стандартном положении). Подозреваю, что дело в операционке и правах пользователя. У меня админ в вин7про.

На счет параллельного кода. Из моих экспериментов понял, что не корректно запускать параллельные процедуры на всех ядрах, особенно если надолго, на много часов/суток допустим. Нужно запускать на -1 ядрах. Т.е. на 3-х из четырех имеющихся, если четыре ядра всего. Иначе не только программа начинает глючить, но и система.

[Dmitriy40]

Нашёл как решить проблему, вдруг кому ещё пригодится: надо после скачивания файла открыть его свойства в Проводнике и там под кнопкой атрибутов будет кнопка Разблокировать — она и уберёт запрос разрешения запуска. Даже если файл переименовать или перенести в другую папку/диск.
С чего кто-то (ОС/браузер) ставит флаг на скачанные исполняемые файлы непонятно (вероятно когда-то сдвинул защиту в максимум и забыл). Но хорошо что вопрос не в PARI/GP. Извиняюсь за ложную тревогу.

[dmd]

Dmitriy40
Прикольно, не вижу у себя такой кнопки. А система какая?

[Dmitriy40]

Очень похоже что флаг (кнопка) появляется только если поставить защиту в максимум (в Изменение параметров контроля учётных записей). Win7Pro x64.

-- 19.11.2020, 20:49 --

dmd в сообщении #1493311 писал(а):

На счет параллельного кода. Из моих экспериментов понял, что не корректно запускать параллельные процедуры на всех ядрах, особенно если надолго, на много часов/суток допустим. Нужно запускать на -1 ядрах. Т.е. на 3-х из четырех имеющихся, если четыре ядра всего. Иначе не только программа начинает глючить, но и система.

Не согласен, тут смотря как программа написана, у меня программы на дельфи и асме работают годами непрерывно на всех ядрах, разумеется с idle приоритетом, причём в них когда 4 потока, когда 5 (4 вычислительных и сервисный), на 4-х ядрах.
Тормоза бывают когда программа активно работает с памятью, что вымывает все другие приложения (вместе с ОС) из кэшей и вот тогда да, вах, лучше бы оставлять ядро свободным для всех остальных. Для нетребовательных к памяти программ можно смело загружать все ядра (разумеется ставя idle приоритет, это как бы подразумевается, без него страшные тормоза гарантированы).

-- 19.11.2020, 20:53 --

wrest
Зацените выше Ваш пример на разных вариантах одной версии. Параллельный вариант фактически лишь вдвое быстрее однопоточного, но грузит все 4 ядра на 100%.
Но это неудачный код для оценки скорости. Потому что другая моя программа из недавней темы выдаёт времена 11с, 35с, 53с для соответственно x32, x64, parallel x64 в один поток.

[wrest]

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

Зацените выше Ваш пример на разных вариантах одной версии. Параллельный вариант фактически лишь вдвое быстрее однопоточного, но грузит все 4 ядра на 100%.

Если это ноутбук (ограниченный термопакет), то норм, в среднем коэффициент многоядерности для 4 ядер 2.5...3. У меня одно загруженное ядро работает на 4ГГц, а когда все 4 загружены, то только на 2ГГц.

-- 19.11.2020, 21:17 --

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

Зацените выше Ваш пример на разных вариантах одной версии.

Я не понял почему у вас многопоточная версия медленнее выполняет однопоточные функции, мне это ни разу не очевидно.

[StaticZero]

(Оффтоп)

dmd в сообщении #1493311 писал(а):

Из моих экспериментов понял, что не корректно запускать параллельные процедуры на всех ядрах, особенно если надолго, на много часов/суток допустим. Нужно запускать на -1 ядрах. Т.е. на 3-х из четырех имеющихся, если четыре ядра всего. Иначе не только программа начинает глючить, но и система.

"У меня такая же нога и не болит". В смысле, что я гоняю на своих машинах все доступные ядра. И ещё на посёрфить остаётся.

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

Параллельный вариант фактически лишь вдвое быстрее однопоточного, но грузит все 4 ядра на 100%.

Amdahl?