Вычисление гиперболических функций на С.

Попробуй функции гетероскедастичных временных рядов в вакуумном пространстве

А по существу?

Выбери более гладкие функции, раз выбор произволен. Яму можно смоделировать без тахакиусов и его друзей.

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

у меня качественная модель с ODE первого порядка.

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

Неявная схема для решения ОДУ должна помогать в таких случаях. Несколько итераций, и решение сходится. Если не сходится, уменьшаешь шаг.

Попробуй функции гетероскедастичных временных рядов в вакуумном пространстве

Работает только в частном случае equus sphaerica.

Так дело же не в схеме, мне всё равно, насколько она хороша. Дело-то в том, что у меня входные параметры для граничных условий сильно прыгают, от этого результат скачет. В целом мне всё равно, какой результат, просто не устраивает такая нестабильность. Не хочется в один прекрасный момент получить NaN или Inf.

Только не говори, что ты явные схемы используешь.

well, у меня выбора нет. но дело же тут не в схеме.

у меня выбора нет

Это как вообще? Какой-то готовый софт использует явные схемы? Это жесть.

но дело же тут не в схеме

Тут два варианта. Либо ты всё понимаешь, ты прав, но не договариваешь каких-то важных деталей. Либо ты всё «понимаешь», даже не прочитав начало какого-нибудь учебника по численным методам.

что простая смена операций при вычислениях даёт большую разницу

Что такое смена операций при вычислениях? Ты имеешь в виду смену порядка вычислений, навроде перемены порядка множителей? Просто я с таким сталкивался как раз.

Только не говори, что ты явные схемы используешь.

Эх, если бы везде можно было использовать неявные схемы, жизнь бы заиграла воистину новыми красками

Это как вообще? Какой-то готовый софт использует явные схемы? Это жесть.

Это не готовый софт (хотя я был бы рад). Всё было написано грубыми мужскими руками.

Тут два варианта. Либо ты всё понимаешь, ты прав, но не договариваешь каких-то важных деталей. Либо ты всё «понимаешь», даже не прочитав начало какого-нибудь учебника по численным методам.

find a man who can do both

с ode я уже со времён универа не работал, это правда. Но тут проблема следующего характера: нужны граничные условия, весьма локализованные. Всё равно, как они выглядят, результат только качественный. Однако при вычислении расстояния до границы аргумент может быть большим + он скейлится, в результате получаются выражения вроде cosh(100) или 1/cosh(100), которые не упрощаются. Результат вполне себе конечный и в разумных пределах, но промежуточные значения просто чудовищные (либо малые). Вот и вопрос: как работать с величинами, различающимися на порядки, чтобы конечный ответ не сильно отличался от реальности.

Да, оно самое.

Вы за границей работаете/живете/учились, что используете ode вместо ОДУ или просто хотите выделиться как хипстер?

Вы за границей работаете/живете/учились

всё сразу

Попробуй для начала перегруппировать множители, то есть перейди условно говоря от (a*b*c)/(d*e*f) к (a/d)*(b/e)*(c/f). Следи, чтобы ни на одной стадии вычисления выражения промежуточные результаты не вылетали из допустимого диапазона float (или double). Часто мне этого удавалось добиться как раз такой перегруппировкой.

На изменение результата от казалось бы тождественного преобразования могут ещё влиять оптимизации. Например с -Ofast я на это постоянно напарывался, а с -O3 такого нет. Хотя у той же CUDA и на -O3 такие фокусы могут быть.

Однако при вычислении расстояния до границы аргумент может быть большим + он скейлится, в результате получаются выражения вроде cosh(100) или 1/cosh(100), которые не упрощаются. Результат вполне себе конечный и в разумных пределах, но промежуточные значения просто чудовищные (либо малые)

Нужно посмотреть на точную формулу, что-нибудь придумаем. В конце концов можно cosh и по определению выписать, если потребуется.

А у Вас там рили принято на английском или просто знания русского слабые? Просто в РФ я ode не встречал ни в одной книжке и не слышал ни от одного препода. Если бы не читал одну книжку по численным методам на английском на втором курсе, то даже не знал бы что это такое.

По теме — tanh+tanh это сумма двух гиперболических тангенсов? Кстати, в РФ тоже не все сразу поймут что это, тут принято th писать.

А теперь по теме — у вас 3 варианта:

• Если значения действительно очень сильно большие или маленькие на выходе и так и должно быть, то числа с длинной арифметикой, может даже не просто long а специальные библиотеки которые работают с числами очень большой разрядности
• Если это ошибка метода (отсутствие сходимости) приводит к таким результатам то менять метод расчета повышением порядка точности
• Если можно упростить исходное уравнение или заменить его более простым, то лучше так и сделать

Ну вот первый потенциал

tanh(A * sqrt(x^2 + y^2) - B) + tanh(-A * sqrt(x^2 + y^2) - B)

И второй:

tanh(A * x - B) + tanh(-A * x - B)

где A = 20 и B~100-200 (опытным путём подбирал).

Со вторым проще: там только одна ненулевая производная. У первого вылазит x/sqrt(x^2 + y^2) и y/sqrt(x^2 + y^2) как сомножители, уже группировка их отдельно меняет результат после определённого количества итераций.

Видел подобный сдвиг терминологии у тех, кто матлабом пользовался. Там в названиях функций — ode и tanh.

Ничего не понятно из твоих объяснений.

Если не хватает точности double, заюзай более точные представления.

А у Вас там рили принято на английском или просто знания русского слабые?

И кому же мне в Великобритании рассказывать про ОДУ?

Просто в РФ я ode не встречал ни в одной книжке и не слышал ни от одного препода.

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

Если бы не читал одну книжку по численным методам на английском на втором курсе, то даже не знал бы что это такое.

Я книги по диффурам на русском в последний раз читал лет 8 назад, кроме вержбицкого и не назову никого.

Если можно упростить исходное уравнение или заменить его более простым, то лучше так и сделать

Внимание, вопрос: как это сделать?

В профиле у Вас указан Минск, с каких пор это Великобритания?

Внимание, вопрос: как это сделать?

Зависит от задачи и конкретного уравнения.

А почему я должен обновлять место жительства по требованию? Это же не военный комиссариат.

P.S. Задачу я привёл выше.

Прочитал ОП, тред, но так и не понял, в чем твоя проблема. Что такое смена операций? Разница в чем? Решение неустойчиво к семантически тождественному изменению вида исходных функций или что?

Решение неустойчиво к семантически тождественному изменению вида исходных функций или что?

Не решение, а результат вычисления, но суть ты уловил верно.

Например, ты переставил множители в исходном выражении и результат поменялся?

Yep. Я слышал о подобных проблемах, но никогда на практике не сталкивался, к своему стыду и сожалению.

В общем, единственный вариант, который выглядит удовлетворительно, это ручками делать, отдельно рассматривать диапазоны координат и значений. Или скейлить (что тоже люди в MD делают), но это боль в заднице.

Я думал, что GSL в этом плане хорош, некоторые базовые функции у них самописные, но у них просто дополнительные проверки выполняются ( и есть возможность выводить код ошибки), но внутри тот же exp, только в три раза медленнее (!) даже с -О3.

А то!

Вот классический пример:

1000-sqrt(1000^2-1) = 5.00000125043698e-04
1/(1000+sqrt(1000^2-1)) = 5.00000125000063e-04

первый ответ неверен, начиная с ...4369. Если что, это меньший из корней квадратного уравнения x² - 2000x + 1 =0.

И как ты борешься с такими проблемами?

Ну, в этом конкретном случае (корни квадратного уравнения) есть, если мне не изменяет память, 6 различных случаев, для которых существуют «правильные» формулы, позволяющие вычислять корни без потери точности, ну примерно как тут: вместо корня b/2a - sqrt(b²/4 - ac)/a вычисляется c/(b/2 + sqrt(b²/4 - ac)), что дает ответ без потери точности при b²/4 >> ac.

А в целом, нужно применять «правильные» алгоритмы или их варианты с учетом конечной разрядности чисел с плавающей точкой на компе. Или, если оных нет, использовать арифметику без округлений или с вариабельным округлением, вроде работы с рациональными приближениями или числами произвольной точности. Последнее существует во многих инкарнациях, например в виде библиотеки GNU MP.

Только пойми правильно: я не аргументирую в пользу MP, это такая тяжелая артиллерия на случай, когда ничего не сработало.

Ну это не так страшно, как пример Румпа :)

нда, печально, радует только то, что мне не нужна такая точность.

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

Весь тред не читал. При чем тут гиперболический тангенс к гипергеометрической функции?

Сплю плохо, стресса много, вот и заменяю слова похожими.