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

Бери петон, профилируй, критичные куски переписывай на цэ.

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

У меня сейчас такой период, что быстрее накатать любое поделие на сях, чем изучать что то более подходящее. Вообще смотри по себе. Главное не зацикливаться.

Пиши на Python, запускай на PyPy.

Если есть готовый модуль для py который всё нужное посчитает, то можно взять питон. В противном случае будет очень медленно и крайне неудобно кодить, так что лучще брать с++...

Дал прогу на c++ одному, от так и не смог его осилить

если, конечно, умеешь кодить на плюсах.

У меня сейчас такой период, что быстрее накатать любое поделие на сях

Синдром утёнка?

Пхытон можно только для одноразовой работы. Типа "один раз — не передаст". И то, если не нужна мощная числодробилка.

C в любом случае выгодней.

Всякие жабко-пхытоны нужны лишь быдлокодерам, у которых зарплата не от качества, а от количества зависит. Набыдлокодил 100 полудохлых скриптов на пхытоне — получи конфетку...

Если стоит выбор между C++ и Python - тогда золотой срединой будет Rust.

Можно питон с numba, оно даже умеет параллельные вычистления cuda

При всём моём уважении к Rust'у — Go всё-таки гораздо ближе к Python'у.

много циклов

Питон для этого не подойдёт. Там где много циклов, фортран нужно использовать. Обёртку можно на питоне.

Сложный вопрос.

Ужос!

Go — это ж вообще финиш! Это даже не пхытон. Это просто ДНО!

Странно что еще никто R не посоветовал.

https://www.scipy.org/

Тебе скорость там сильно вперлась? Если да, то C бери. А вообще посмотри на библиотеку numpy.

Обрати внимание на вот эту прелесть http://jupyter.org . Я последнее время на нем все алкоритмы накидываю.

медленнее плюсов

Тебе скорости не хватает?

после c++ трудно переключится, кое-что по-другому (структуры, switch)

Ты только C++ знаешь, что ли?

я его гораздо хуже знаю

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

Скорей лень нормально изучать другой язык. И сишку я знаю лучше других языков.

Интересуют одноразовые расчеты вроде Mathcad? Или нужно реализовать какой-то алгоритм и, условно, использовать его в продакшене?

Для первого случая, когда нужно «набросать на коленке» некий прототип, понять будет ли вообще алгоритм работать или сделать красивый отчет с графиками и листингами сам использую python + jupyter notebook + scipy/pandas/numpy/nltk/scikit-learn. Вообще суперская связка, особенно если внутри IDE с родными хоткеями. Лучше черновика не придумать.

А смотря для каких расчётов. Может быть, можно взять NumPy, Theano или Tensorflow?

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

много циклов

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

медленнее плюсов

при грамотном использовании (см. выше) это не так.

после c++ трудно переключится, кое-что по-другому (структуры, switch)

я его гораздо хуже знаю

научишься. c++ немного портит моск, но не необратимо.

Петон в своих самых «тугих» местах минимум раз в сто медленнее чем С. Петон со всякими ухишрениями в виде кусков математики на С все равно медленнее чем просто С раз в пять.

Так что если тебе посчитать на один раз и время расчёта вообще не критично... А лучше С!

c++ немного портит моск, но не необратимо.

А вот пхытон портит необратимо. Человек становится умственным инвалидом.

Обычно, есть два этапа написания кода расчётов:

• Разработка алгоритма;
• Реализация быстрой версии

Первую часть делать на плюсах будет очень долго. Для этого используют Matlab, Mathematica, R, Python.

Для второго куска (если он вообще оказывается необходим) используют либо биндинги к быстрым либам из перечисленного выше, либо переписывают на крестах с использованием OpenMP\CUDA.

А фортран уже не в моде стал?

а чем вы там занимаетесь? вот мне интересно я бы осилил или нет? )

Посмотри Theano, может подойдёт. Библиотечка генерит код на плюсах/куде для определённых, с помощью неё, функций.

http://deeplearning.net/software/theano/tutorial/index.html

Python с его numpy вообще не плохо подходить для всяких математических штук. В однопотоке вообще он плох, собственно затем там GIL и нужен, а вот многопоточность его слабое место. Ну и да, возможность переписывать куски на Cи вообще годнота

Python активно используется как обёртка, пример, https://fenicsproject.org/

Его numpy/scipy ядро для многих численных пакетов

Общий смысл: основные расчёты внутри Си/... библиотек, а используются эти библиотеки из Python, где лаконичнее выглядит код, плюс достаточно средств для черновой визуализации.

Есть такая штука ipython/jupyter notebook (пример: http://nbviewer.jupyter.org/github/ipython/ipython/blob/4.0.x/examples/IPytho...) с которой очень удобно проводить черновые расчёты.

а с чего это код на питоне будет медленнее сишного, если ты numpy юзать будешь? Сам так делаю, брат жив.

Если не надо гонять программу сотни раз на кластере, и расчеты укладываются в NumPy - да, можно.

Петон со всякими ухишрениями в виде кусков математики на С все равно медленнее чем просто С раз в пять.

4.2

Возвращайся как померяешь поверенным средством измерения.

Отвечу сразу всем в одном посте:

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

Первую часть делать на плюсах будет очень долго. Для этого используют Matlab, Mathematica, R, Python.

Вот поэтому я и задумался о питоне. А так много работал с Mathematica, но как язык он мне не нравится.

Странно что еще никто R не посоветовал.

R как мне кажется немного для других вещей.

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

В силу особенности задачи много вложенных циклов, т.к. необходимо пробежатся по тысячам объектов, у которого есть несколько точек, в каждой из них надо что-то просуммировать. И все это для 3-х мерной области и на каждом шаге))

Там где много циклов, фортран нужно использовать. Обёртку можно на питоне.

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

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

Почему не чистый си - т.к. не хватает большей абстракции, и вещи типа vector<SomeClass *> и итераторы итп.

Тебе скорости не хватает?

На плюсах впринципе хватает, т.к. я использую lapack. В основном в задаче у меня все упирается в решение СЛАУ - очень большие матрицы.

Если не надо гонять программу сотни раз на кластере, и расчеты укладываются в NumPy - да, можно.

Я тут недавно услышал, что одна фирма для научных расчетов написала код на си + питон как обертка. Причем они расчитывают на кластерах с очень большим количеством данных. Вот я поэтому и призадумался.

Еще в numpy нет проблемы с матрицами как в библиотеке lapack, в lapack матрицы располагаются по столбцам как в фортране.

Еще можно легко подрубить cuda, разреженные матрицы, mpi

Возвращайся как померяешь поверенным средством измерения.

Проверено на реальной задаче (численное решение модели плотности распределения растительности).

А пока что голословен лишь ты.

Сишку невозможно знать. Все UB не запомнишь.

Проверено на реальной задаче

Лул: https://github.com/RazrFalcon/svgcleaner#cleaning-time (svgcleaner - Rust, svgo - JS, scour - Python).

У меня есть код написанный на c++.

R как мне кажется немного для других вещей.

R как раз для встраивания первого во второе оптимален. Скорость разработки из-за хорошей готовой инфраструктуры будет весьма высокой.

https://cran.r-project.org/web/packages/Rcpp/index.html

(но судя по всему навыков использования R у тебя нет)

На плюсах впринципе хватает, т.к. я использую lapack. В основном в задаче у меня все упирается в решение СЛАУ - очень большие матрицы.

Ну это тебе вообще повезло (если много компов в доступе). Можешь перемалывать любого размера за разумное (практически константа) время.

https://cran.r-project.org/web/packages/pbdSLAP/index.html https://cran.r-project.org/web/packages/pbdBASE/index.html https://cran.r-project.org/web/packages/pbdDMAT/index.html https://cran.r-project.org/web/packages/pbdNCDF4/index.html https://cran.r-project.org/web/packages/pbdPROF/index.html

https://cran.r-project.org/web/packages/pbdDEMO/index.html

Ну а на нвидия картах считают прозрачно просто делая ldpreload для бласа от куды.

octave же-ж или сразу mathlab

OpenFEM

В силу особенности задачи много вложенных циклов, т.к. необходимо пробежатся по тысячам объектов, у которого есть несколько точек, в каждой из них надо что-то просуммировать. И все это для 3-х мерной области и на каждом шаге))

при правильном использовании numpy/scipy не надо будет никаких циклов городить для этого.

квантовый транспорт в полупроводниковых гетероструктурах. (расписывать лень).
с++ на порядки быстрее и точнее питона [при грамотном использовании].
наверное ты просто не осилил, и зациклился на одном только языке.
по описанию ТС, ему плюсы подходят [eсли он это все сможет написать на с++]. но пусть попробует разное и потом сам определится.
p.s. а еще советую comsol для метода конечных элементов.

а почему ты так боишься циклов?

в lapack матрицы располагаются по столбцам как в фортране

Какими проблемами это грозит? В фортране в циклах просто левый индекс используют в самом внутреннем цикле и т.д.

Есть ли смысл использовать для численных расчетов python (методы конечных элементов, математические расчеты, много циклов, большие данные)?

Нет. Получится говно.

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

А на пистоне писать быстро. Хренак, хренак и готово. Потом только долго надо будет еще дольше соображать, почему так все некрасиво получилось. Чем быстрее разработка, тем хуже продукт.

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

Никто не мешает делать красиво, как и не может запретить делать криво.

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