Python в научных вычислениях

Несмотря на то что я очень котирую C/C++ - плюсую

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

Однако из этого не следует, что НОВЫЕ проекты стоит начинать на де-факто мёртвом ЯП.

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

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

Синтаксис? Синтаксис?! СИНТАКСИС?! (далее громкий нервозно-гомерический хохот)

Если бы одним синтаксисом ограничивались проблемы матлаба, это был бы идеальный инструмент для «научных вычислений».

Ну как почему, вот я малознакомый с программированием человек, понадобилось мне что-то посчитать, написал «лобовой» код на Python (я же ведь малознаком с программированиям, откуда мне знать где, что, как оптимизировать чтобы быстрее считалось?) и тут выясняется что он медленно работает

В большинстве случаев выяснится, что работает он достаточно быстро и это лучше, чем 2 месяца потратить на C.

«Преждевременная оптимизация — корень всех зол» (с) самизнаетекто

Но в научной среде поголовно пиарится именно питон.

«Научная среда» существует в однородном виде только в головах ораторов на ЛОРе. На самом деле в зависимости от науки используется все: от С c Фортраном, куча закрытой дряни типа Математики и Матлаба, пистон с R и заканчивается все людьми, которым хватает и экселя. Хорошо, если от всего этого парада уродцев останутся C/Fortran для низкоуровнего и Python/R для высокоуровнего анализа - это будет настоящая победа.

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

Смотрю на своих физиков, им как-то пофиг. Они других синтаксисов и не видели.

и хорошо! матлаб - очень прост и удобен...
набор всех нужных(основных) функций(математических) присутствует. что еще нужно?
а главное(субъективно), работает с матрицами.
a Fortran для старичков...

Ты бы предпочел Matlab?

Матлаб (если есть деньги) или октава/R (если их нет). Julia вот вкусно смотрится в перспективе, но пока... Питон смотрится явно лишним, хотя надо признать, что numpy/scipy ряд упрямых личностей доразвивали до вполне достойного состояния. В них только одно плохо: сам питон.

MathCAD?

Удивляюсь, что кто-то всё ещё пользуется этим уродством. Видимо, чисто российская фича — тут я его ни разу не видел и не слышал о нём. Для комп. алгебры — Mathematica/Maple (при наличии денег) или Maxima (при их отсутствии). Кое-что, конечно, неплохо делает sympy, не спорю, но мне почему-то кажется, что это опять-таки не благодаря питону, а вопреки ему.

А Fortran уже отменили?

Фортран как бы не для того. Фортран — это язык конечной реализации, когда алгоритм отлажен. В топике же обсуждаются средства быстрой прототипизации.

Это так кажется

Не, это так оно и есть. Переиспользование идёт разве что на уровне алгоритмов.

По-моему, здесь большая проблема научного сообщества: деньги выделяются только на исследования, поэтому на разработку вменяемого научного тула их никогда нет.

Есть, дают и разрабатывают, но получается, как обычно, нёх. См. ROOT. Поэтому ситуация с R, где разработка идёт кучей народу исключительно под свои личные нужды, гораздо интереснее.

Не навязывают, но и альтернатив не дают, что почти одно и то же.

Не понял? Не дают потому что их нет или что-то скрывают от народа?

Скажу тебе по секрету: профессиональные инструменты требуют времени для изучения, к дурным негодным инструментам подходить не нужно сразу же, а изучать алгоритмы можно и без компьютеров.

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

Тут речь не только про учёбу, особенно с учётом заголовка. И всё равно, даже в Mathcad надо изучать основы и смотреть справочники. Да и лицензия на всё это чудо (тем более на целый класс), будет стоить не мало.

В области ФВЭ/HEP питон используется в основном в качестве клея и обёртки. Тут на его место годится де факто любой стабильный (анализ в несколько лет — это норма) скриптовый язык с батарейками.

Извините за возможно тупой вопрос: Если тут обсуждается применение Python для научных вычислений, возможно ли для подобного класса задач использовать Lua в связке с Си.

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

Просто хотел узнать, вдруг у Lua есть какие-то принципиальные минусы по сравнению с Python.

PS: И с Python и с Lua я знаком весьма поверхностно.

Конкретно для ФВЭ/HEP в качестве клея и обёртки сгодится любой стабильный скриптовый язык с батарейками. Для целей локального эксперимента я длительное время использовал perl, но сейчас де факто его место занимает Python.

Мы тут с товарищем соревновались, решали одно и тоже уравнение одним и тем же методом, я на С, он - на питоне

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

Я выступаю не против питона, а против отсутствия альтернатив.

Я что-то не понял, спецагенты ЗОГ устраняют разработчиков этих самых альтернатив? Или вводят цензуру в СМИ, чтобы о них никто не узнал? Возьми да напиши свою альтернативу.

Просто хотел узнать, вдруг у Lua есть какие-то принципиальные минусы по сравнению с Python.

Принципиальных нет, но есть отсутствие numpy/pandas и ipython notebook.

Так озвучь свои претензии к Python. Пока что ты, хоть и сквозь зубы, признаешь его полезность.

А почему так нужна скриптовость? Если понаделать готовых либ на С вроде numpy то почему нельзя их дёргать из компилируемого языка?

Просто хотел узнать, вдруг у Lua есть какие-то принципиальные минусы по сравнению с Python.

Для питона есть готовые библиотеки типа numpy, scipy и matplotlib. то есть из коробки уже есть базовая математика, операции над матрицами, преобразования фурье и т.д. и графики с диаграммами можно строить. Почти все для чего люди матлаб используют уже есть готовое. А для луа я не видел аналогичных библиотек по полноте и функционалу.

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

Ах, когда я в 2012 году делал лекции в ipython notebook, это ещё было модно, стильно и необычно. А сейчас уже мейнстрим какой-то. Обидно даже.

Вопиющая неграмотность - это не знать, что scilab читается «сайлэб», а не «лыжная лаборатория».

В Mathcad'е есть и встроенная функция fft, и векторы/матрицы. И ни что не мешает реализовать в системе алгоритм fft самостоятельно.

Если после ЦОС-а будет курс ...

Обычно курс ЦОС разбивают на две больших части/курса: теоретическую и практическую. Где на практической части уже занимаются программированием непосредственно сигнальных процессоров или чего-нибудь другого.

Так вот нет ничего плохого, чтобы теоретическую часть вести с использованием Mathcad'а. И сразу садить студентов за сигнальные процессоры ничуть не лучше того, чем за python, numpy и scipy.

Скажу тебе по секрету: профессиональные инструменты требуют времени для изучения

Мне это и без тебя известно.

дурным негодным инструментам подходить не нужно сразу же

Понятное дело, определять, что дурно и негодно, можешь только ты.

а изучать алгоритмы можно и без компьютеров.

Утверждаешь, что ЦОС лучше преподавать вообще без компьютеров, чем использовать Mathcad?

соглашусь, пробовал python для моделирования алгоритмов обработки изображений с использованием библиотеки OpenCV. В итоге пришёл к неожиданному выводу, что проделать эту работу на C++ оказалось удобнее и быстрее. Начиная с того, что питону просто для начала потребовалось доустанавливать несколько дополнительных пакетов помимо самой OpenCV. Так же обнаружил, что некоторые вещи, которые в С++ выполняются легко и достаточно очевидно, в питоне требуют каких-то извращений (например сортировки с лямбдами в многомерных массивах NumPy).

Так вот питон в научных кругах - прежде всего свободная замена матлаба.

по-моему SciLab больше подходит на эту роль

Вопиющая неграмотность - это не знать, что scilab читается «сайлэб», а не «лыжная лаборатория».

Очень радуют наши доморощенные ценители английского языка. Благодаря таким товарищам ГосДеп может сэкономить много денег.

Я почитал про numpy и прочее. Как я понял, там вся основа написана на сях и лицензия открыта и исходники есть.

Теоретически это всё возможно было бы перенести в библиотеки для Lua. Почему тогда этого никто ещё не сделал. Lua ведь не вчера появился.

Ну и ещё, вроде бы есть математические библиотеки для Си, а если такие библиотеки есть, то их можно использовать из Lua.

Меня интересует вдруг есть какие-то чисто принципиальные причины или критические недостатки Lua из за которых никто даже не стал заморачиваться на эту тему? Или просто так «исторически сложилось».

Я недавно начал присматриваться к Lua и он в целом мне показался симпатичным, но я пока не понял почему он сильно уступает в популярности Python-у, который тоже мне показался достаточно интересным.

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

Мне это нужно не для практического применения, а скорее для расширения кругозора.

Я почитал про numpy и прочее. Как я понял, там вся основа написана на сях и лицензия открыта и исходники есть.

Основа, может, и на Си, но половина исходников - Python, а Си завязан на Python API.

Параллельные вычисления не являются сильной стороной Python. Собственно говоря сегодня с параллельным вычислениями плохо везде. Поэтому сейчас спользовать приходится ассемблер OpenCL/Cuda напрямую для всего, что выходит за рамки стандартных библиотек. Возможно в будущем что-то поменяется, но IMHO не в близком.

помню мы тоже с товарищем соревновались. я на руте, она - на питоне.

Бред. Множество людей использующих ROOT делают это в python.

Во-первых, есть класс численных задач где никаких тупых простых действий нет, а скорость счёта критична. Просто исходя из высказываний почитателей Python они его используют исключительно чтобы быстро сделать что-то с кандачка.

Во-вторых, имеются ли какие-нибудь официальные исследования на тему скорости разработки под интерпретируемые и компилируемые языки, а то постоянно все говорят о том что под Python быстрее писать чем под C или C++, но это всего лишь голословные утверждения.

программист без английского - как врач без латыни,мне за вас стыдно, а ещё преподаёте, жесть.

А я и нигде не утверждал, Python - это серебряная пуля для всех случаев жизни, но во многих случаях стабильный скриптов язык с батарейками существенно облегчает жизнь. И да, делается не с кандачка, а то, что необходимо для решения предметной задачи. Это основное.

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

А потоки в C и C++ вам чем не угодили? Если численная задача допускает параллельное выполнение некоторых своих частей то потоки отлично справляются с этим. Или вы хотите писать код и чтобы сам компилятор его анализировал и автоматически распараллеливал где есть возможность?

Замечание: PyROOT весьма и весьма коряво - это собственно говоря ROOT один в один, но действительно для некоторых манипуляций Python весьма полезен, число таких задач ограничено.

сегодня с параллельным вычислениями плохо везде

А зачем тогда интересно нужны суперкомпьютеры, раз с параллельностью везде плохо?

Можно свободно читать и писать по-английски, но в силу привычки или незнания произносить некоторые слова неправильно. Из-за отсутствия большой практики именно в разговорном английском. Например, xerox почти все произносят как ксерокс. И таких примеров масса.

Да даже среди native speaker`ов - https://www.youtube.com/watch?v=emgJtr9tIME в первом комменте срач на тему как произносить char.

боюсь спросить,а причём тут параллельные вычисления?

Или вы хотите писать код и чтобы сам компилятор его анализировал и автоматически распараллеливал где есть возможность?

This! Но я понимаю, что на сегодня это невозможно, поэтому для реального распараллеливания приходится разбираться с CUDA/OpenCL/MPI и т.д.

Сорри, прочитал OpenCL вместо OpenCV. А потом по аналогии понесло, так как параллелизм реально проблема.

ок

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

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

Параллельные вычисления не являются сильной стороной Python. Собственно говоря сегодня с параллельным вычислениями плохо везде.

В java все просто зашибись.

The Parallel Java 2 Library (PJ2) is an API and middleware for parallel programming in 100% Java on multicore parallel computers, cluster parallel computers, and hybrid multicore cluster parallel computers. In addition, PJ2 supports programming GPU accelerated parallel computers, with main programs written in Java and GPU kernels written using Nvidia’s CUDA.

CUDA

This! Остальное пыль и не смешно.

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

Отсутствие numpy для lua

Ещё в луа есть такие весёлые вещи:

• Глобальность переменных по умолчанию.
• undefined переменные и костыли для борьбы с ними http://lua-users.org/wiki/DetectingUndefinedVariables

Что мешает работать.