ЯП делающие это на этапе компиляции - не будут работать медленнее

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

Насчет графиков, не Matplotlib живы единым, есть Gnuplot, MathGL.

Для этих самых телескопов и на фортаранах и сях и хацкелях и специализированных DSL пишут и все недовольны, особенно фортранами :)

Что мешает самому эти батарейки писать/дописывать? Надо изобретать велосипед?

И потом речь идет о прототипировании или когда этих баратеек и производительности достаточно, почему их не использовать?

и ученому ничего, кроме питона, и знать не нужно.

Разве им не надо знать их предметную область и ещё много чего?

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

Ознакомиться на hackage, сами справитесь или за вас ссылки поискать?

Что мешает самому эти батарейки писать/дописывать?

Код и язык программирования для них не самоцель.

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

Можно подумать от пистона сразу все довольны будут. :)

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

Он C++сный один в один — то есть тебе всё равно нужно знать ROOTовский интерфейс во всей его красе.

Интерфейс надо знать в любом случае.

Ограничений в PyROOT нет, кроме скорости — она такая же, как и в случае cint, то есть порядок к скомпилированной программе.

Не надо упоминать про убогий cint с непредсказуемыми результатами. Хорошо что его наконец заменили на cling (https://root.cern.ch/cling).

Не думаю что для фита распределения event by event для миллиона событий вы получите большой выигрыш для скомпилированной программы по сравнению с интерактивным python.

Да, но в октаве масса всякой всячины нужной для матана искаропки. Когда о скорости речь не идёт - на октаве proof of concept для научного матана набросать быстрее.

В питоне матана из коробки не меньше.

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

У тебя какие-то узкие представления об науке. Фортран сейчас в науке используется только в узких областях. Я занимаюсь технической наукой в области электропривода, здесь никакого фортрана нет, используется в 99% случаев матлаб. А питон его неплохо для этих задач заменяет, в numpy/scipy/simpy из коробки есть все что нужно, остается только скриптики писать.

Зачем кому-то питон, если уже знает Си? Питон для лентяев, для которых Си слишком сложен.

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

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

Ну если, в вашей предметной области не нужно решать матричные задачи,с произвольными матрицам, размеры которых превышают ОЗУ узла, то да, форьоан не нужен. Все остальные используют либу на букву s с netlib.org либо мкл, которая её содержит

Легаси развивать смысла нет. Но ты можешь попробовать сделать бэк-порт.

годнота
правильной дорогой идет товарищ

Под 10^6 событий вы подразумеваете 10^6 чисел или именно событий? Это сильно разные вещи. Ну а итоговый фит, если всё хорошо, обычно делается по одномерной гистограмме, который можно сделать интерактивно просто в ROOT, или через cxx-скрипт.

Мои знакомые ученые используют LabVIEW

Мне все равно на 2 ветку. Давно на 3 перешёл.

Мне все равно на 2 ветку. Давно на 3 перешёл.

Всё правильно сделал. Держи симпу.

Чувак, расслабься. iPython notebooks уже сегодня принимают к зачёту в некоторых университетах Северной Америки (как минимум на двух факультетах двух университетов :)). Они удобны и работают практически везде, в том числе удалённо. Их удобно сохранять, ими удобмно обмениваться, в них удобно по быстрому прикинуть что к чему. Мощный инструмент в умелых руках. А для начинающих так вообще бомба. Иногда бывает полезно отложить свои привычки в сторону и попробовать что-то новое. Вот это как раз тот самый случай.

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

В питоне матана из коробки не меньше.

Гораздо меньше. Питон не умеет символически решать уравнения, например. Или там упрощать выражения. И в TeX не умеет вывод печатать, чтоб сразу в статью формулки.

Фортран сейчас в науке используется только в узких областях. Я занимаюсь технической наукой в области электропривода, здесь никакого фортрана нет, используется в 99% случаев матлаб.

Ну значит матлаб.

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

Не, я может чего не знаю и можно запустить интерпретатор питона и сказать что-то типа solve( sin(x)/cos(x) + x * e ^x = 1, x )?

Питон не умеет символически решать уравнения, например

Это разве не оно? http://www.sympy.org/en/features.html

solve( sin(x)/cos(x) + x * e ^x = 1, x )?

http://docs.sympy.org/latest/tutorial/solvers.html именно так оно и выглядит.

И в TeX не умеет вывод печатать, чтоб сразу в статью формулки.

Тоже умеет. http://docs.sympy.org/dev/tutorial/printing.html

Питон рулит и педалит!

Ну не дотягивает оно пока до октавы. Хотя да, прогресс несомненно налицо. :)

Не, я может чего не знаю и можно запустить интерпретатор питона и сказать что-то типа solve( sin(x)/cos(x) + x * e ^x = 1, x )?

Вот именно что не знаешь.

man sympy

https://en.wikipedia.org/wiki/List_of_computer_algebra_systems

Сравни в таблице functionality строки SymPy и MATLAB (Symbolic math toolbox). SymPy умеет намного больше чем матлаб, не говоря уже об октаве, которая тут даже не рассматривается.

На луя есть scilua muneric lua.

что-то оно даже solve(sin(x)-x,x) не умеет.

Опечатка. Numeric lua.

Ты что, хочешь аналитически трансцендентное уравнение решить? Такое уравнение имеет только численное решение, и его легко получить при помощи scipy.

Ну вот, т.е. надо не только питон, но и numpy+sympy+scipy+_ещё_наверно_чего-нибудь_

В том уравнении понятно что x=0 конечно, честно говоря не знаю почему у SymPy затруднения, хотя оно не совсем обычное. А вообще sympy хорошо работает. Конечно, для каждой области нужен свой модуль. Для нейронных сетей например тоже отдельный есть, и так далее. Но это все тот же питон, а не 100500 разных программ.

Можно ли как-нибудь в питоне (наверное ipython notebook) использовать дроби без Rational?

.

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

Нет конечно, фит одномерной гистограммы это простейший случай. Имелся в виду фит событий «event by event» (https://root.cern.ch/roofit). Да, это можно сделать используя «cxx-скрипт», но удобнее делать всё в python.

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

Внезапно питон и делался как клей и у тебя багет от того что язык прекрасно справляется с этой ролью.

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

Пруфец бы не помешал.

Внезапно питон и делался как клей

Не клей это, а другая органическая субстанция.

Внезапно питон и делался как клей

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

Я же не говорю про изначально, те времена были очень давно и просто прекрасно что вовремя вылупились сишный интерфейс модулей/ctypes/swig/cython/cffi

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

По-моему, навязывание питона в научных кругах (что де-факто сейчас и происходит) — верх маразма. Это только приучать к заведомо пагубной практике: отсутствие статической типизации, тупые ошибки, если нет нужных тест-кейсов (а кто из научных работников этой хренью будет заниматься?),

«Научным кругам», не связанным с теоретическим computer science, не привыкать. Даже на таком убогом DSL-переростке как Matlab, - который, к сожалению, используется не только в купе с Simulink и проч. инженерией, но и (некоторыми) в такой области как машинное обучение, - авторы используют не все возможности языка для придания ему более структурированного и удобочитаемого вида. Основной критерий применимости ЯП в таких случаях - возможность написать quick and dirty прототип, достаточный для получения научного результата, нарисовать графики и написать статью (если к тому же интерпретатор ЯП идёт составе IDE с отладчиком и средствами построения GUI - ещё лучше). Достижения же в теории формальных языков, технологичность инструментов и иные вопросы, так или иначе связанные с информатикой и разработкой ПО, уходят на второй план, главное - опубликоваться. Если тот или иной результат имеет практический потенциал, прототип переписывается (другими людьми) на более подходящем языке. И какая польза от статической типизации в вычислительных задачах, если количество типов ограничено, и в основном это вещественнозначные матрицы и простые структуры со именами файлов (откуда прочитать входные данные, куда записать выходные)?

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

Правда? Тогда вам сказочно повезло! Это у профессора есть аспиранты со студентами, что переписывать его г@#внокод. А молодой ученый — это и швец, и жнец, и в дуду игрец. Я не против использования питона, и считаю вполне правильной практикой те случаи, что вы описали. Но учить программировать научного работника нужно не с питона, а с нормального языка — С/С++. Питон он может освоить в любой момент, мозга там не надо. То, что видел я, это как раз наоборот: когда студенты, аспиранты тяжелее Mathematica ничего в руках не держали, а потом изучают питон. Выучат они потом нормальный язык после питона? Нет! Это равносильно как после ворда заставлять учить латех (латех нужно вбивать в голову с первых курсов). Вот и получается, что в издательствах и конференциях очень часто требуют именно ворд.

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

А зачем им знать нормальный язык? Давай всех программистами сделаем, путь дворники тоже что-нибудь на си пишут. Есть разные профессии, и программист - только одна из них. И computer science - только одна из областей науки. Ученые из других областей не должны быть программистами, они должны иметь простой инструмент для решения научных задач, такой как Mathematica, Matlab иди python. Молодым ученым не уперлось после аспирантуры идти сишниками работать. Так зачем им «нормальные языки»?

Молодым ученым не уперлось после аспирантуры идти сишниками работать. Так зачем им «нормальные языки»?

C другой стороны вторая специальность это не так уж и плохо) А с третьей стороны python даже лучше оплачивается))

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

Тут ты уже начинаешь передергивать. В идеале, конечно, знать нормальный язык не нужно. При условии, что есть язык, эффективный в создании прикладных программ учеными, здесь три критерия: простота изучения языка, быстрое прототипирование и эффективное исполнение (не только за счет NumPy, но и циклы, ветвления и прочее). Такого языка я не наблюдаю. Считаю, что научное сообщество не в состоянии создать такой язык собственными усилиями (подавляющее число грантов как-никак исследовательские). И ждать, что кто-нибудь со стороны сделает, это получится либо дорого, либо халтурно, либо то и другое.

простота изучения языка, быстрое прототипирование и эффективное исполнение

Это вещи диаметрально противоположные, поэтому такого языка и нет. А реально есть выбор - или простые и быстрые в плане разработки скриптовые языки или матпакеты, или эффективно исполняющиеся, но сложные в освоении и медленные в разработке. За все нужно платить, скорость и простота разработки неизбежно имеет свою цену.

Вот именно потому и нужно знать нормальный язык (хотя бы С/С++). А иначе как делать программы эффективными? Потому что остальные из этого списка требований гораздо проще выучить, и этот пробел легко ликвидировать.

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