Есть ли смысл использовать для численных расчетов python?

Только для МКЭ (если я правильно понял слово «элементы») 1000^3 выглядит несколько монструозно, вне зависимости от ЯП. Интересно что именно они делают...

ни о чем не говорят. Волновое уравнение — говоирт. bound — мало о чем говорит. Ты уравнение покажи лучше.

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

может Вы просто будете по-русски общаться, а не своим мунспиком междусобойным?

если не ложится по шерсти линейной алгебры, значит надо ее туда положить.

Скорее тут Вы - воинствующий сторонник линейной алгебры, ссылающийся на свои студенческие поделки и поделки своих однокурсников. Давайте я тогда тоже сошлюсь на задачи решенные моими студентами/аспирантами и на свои 20 лет опыта занятий числодробилками, если это у Вас уже катит за аргументы?;-)

Давайте Вы просто не будете шланговать?

Давайте Вы просто не будете шланговать?

Давайте Вы будете просто читать внимательно? Я сделал два простых утверждения:

1) далеко не все задачи числ.моделирования могут быть удобно записаны в терминах линейной алгебры.

2) даже из тех задач, которые могут быть удобно записаны в терминах линейной алгебры, далеко не для всех реализация через numpy/scipy будет хоть сколько то оптимальна (например - задачи с явными численными схемами и большими сетками).

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

Решают задачу о разрыве пласта в грунте. Точнее пытаются определить место этого разрыва.

А можно ссылку какую нить? Мы тоже этим занимаемся;-)

Вроде эта компания http://www.gradient-geo.com/index.php

Спасибо. Ребята очень нетрадиционно работают, на днях поспрошаю коллег-геофизиков что они об этом думают.

Давайте снова перейдем на ты :)

Обдумал тут, что на ровном месте спорим.

Я в принципе говорил в контексте задачи, данной ТС. То есть достаточно стандартная. Ты кинул такую размерность (2^30), что конечно с трудом пролезет в обычную память. Тогда простой convolve или meshgrid могут не налезть. Что впрочем не отменяет их применения при достаточном количестве памяти и позволят распараллелить вычисления фактически автоматом.

Вот так вот.

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

Ок;-)

Дело не только в памяти (надо сказать что и обычный код на плюсах для волнового уравнения и размерности 2^30 будет не сильно оптимален). Дело в накладных расходах на вызовы всех этих матричных операций из питона.

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

Я уж не говорю что кодить банальную схему крест в терминах линейки через ЕМНИП умножение вектора на разреженную матрицу конечно универсально, но ооочень медленно по сравнению с явным заданием соседей ячейки в обычном цикле.

Резюме - если мы не упираемся в решение СЛАУ связка питон + numpy хороша для прототипирования (быстро на коленке сваять работающую приблуду) или решения задач с маленькой вычислительной сложностью. Но как только сложность (размер задачи) хоть чуть чуть вырастает приходиться переписывать ядро на чем то другом. Так почему сразу это не сделать, тем более что я на плюсах пишу быстрее чем на всяких numpy (в основном в силу опыту и своих узкозаточенных библиотек).

Обычно таких медленных кусков не так много, поэтому можно и потом их на си переписать.

Обычно такой медленный кусок - все что связано с численной схемой, и называется он вычислительное ядро. И пишется на С сразу;-)

В однопотоке вообще он плох, собственно затем там GIL и нужен

В однопотоке он хорош, затем там GIL не убирают, да и в многопоточность он умеет, насколько это необходимо.

Зачем отвечать на случайные сообщения ? Есть ли смысл использовать для численных расчетов python? (комментарий)

?

Используй Pure C. Нафига тебе для расчетов плюсы сдались?

Не известно что за рощёты. Может нужны числа с разрядностью больше чем доступно в базовых типах данных. На C++ можно сделать их как класс и использовать operator overloading. В питоне они тоже есть. А без OOP код превратиться в лапшу.

Тебе double мало?

Ну вот как там дела у питона с нативными тредами?

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

Никто автору не предлагает писать на языке, не изучив его хотя бы на уровне быстрого использования Hyperspec'а.

Или автор может потратить это время на лучше изучение питона и осмысливание задачи. Ты ведь не будешь, как Едди, утверждать, что на питоне принципиально ничего нормального сделать не получится? В любом случае, это всё разговоры ни о чём, тем более, что выбор сделан.

Почему...

Я не хочу быть адвокатом питона.

если можно в векторизацию от numpy, то уже циклы далеко не так проблемны.

Странно, bc еще не предложили. А он поинтереснее Python будет. Да и на C++ писать свое...

ну так что решили, как там с микро уровнем, что лучше в итоге то?

Используйте numpy, scipy, pandas, xgboost и ещё кучу библиотек для python. Numpy написан на C и сильно оптимизирован (не только в смысле по коду, а по матану - писали математики). Вряд ли вы напишите код быстрее на С (в смысле по скорости выполнения, да и написания впрочем тоже). При условии что вы будете пользоваться его структурами данных, то он быстр.

Ну тут как раз вопрос в том, сколько времени займёт чтение мануалов на питоне и оптимизация. Я вон молекулярную динамику так и не осилил.