LINUX.ORG.RU

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

 , ,


7

6

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

Или лучше использовать c++? Насколько медленнее код получается?

Плюсы питона:

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

Минусы питона:

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

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

Поделитесь историей успеха.

★★★★

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

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

Cactus64k ()
Последнее исправление: Cactus64k (всего исправлений: 1)

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

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

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

mashina ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от Cactus64k

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

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

anonymous ()

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

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

deterok ★★★★★ ()

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

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

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

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

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

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

Esper ()

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

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

Nicholass ★★★ ()

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

Zeta_Gundam ()

много циклов

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

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

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

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

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

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

dikiy ★★★★★ ()

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

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

init_6 ★★★★★ ()

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

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

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

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

Norgat ★★★★★ ()

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

Dred ★★★★★ ()

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

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

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

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

AlexVR ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zodd ★★★★ ()
Ответ на: комментарий от Zodd

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

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

Zodd ★★★★ ()
Ответ на: комментарий от init_6

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

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

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

dikiy ★★★★★ ()
Ответ на: комментарий от Zodd

У меня есть код написанный на 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 для бласа от куды.

psv1967 ★★★★★ ()
Ответ на: комментарий от Zodd

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

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

dikiy ★★★★★ ()
Ответ на: комментарий от dikiy

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

rambler ()
Ответ на: комментарий от Zodd

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

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

grem ★★★★★ ()

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

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

crutch_master ★★★★★ ()
Ответ на: комментарий от Zodd

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

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

crutch_master ★★★★★ ()
Ответ на: комментарий от grem

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

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

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 3)