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

Эээ... это такой автотроллинг? Просто для протокола: в Си++ это очень сильно зависит от типов a и b, и может включать в себя хоть матричные операции,

Ты прекрасно понял о чём речь, не устраивай клоунаду.

Ну да, только тянет за собой KDE.

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

Ты прекрасно понял о чём речь

А ты, похоже, не понял.

Ну да, только тянет за собой KDE.

Уж лучше один раз утянуть KDE

Утяни мне KDE5 (для KDevelop5) в, например, Wheezy. Или Squeeze.

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

Ну мне-то сказок не рассказывай, я ~10 лет пользуюсь Eclipse.

Совершенно очевидно даже школьнику, что, если каким-то инструментом люди пользуются много, а каким-то мало, то либо инструмент очень узкой специализации, что может быть верно для Haskell и прочих «правильных» языков, либо он просто неудовлетворителен, относительно, потребностей людей, а при этом свершенно неважно насколько он математически обоснован. Так потому и возникает два простейших вопроса: что вместо мейнстримных языков типа Питона взять и использовать, почему научное сообщество должно ломанутся рразрабатывать альтернативы и где примеры значимого применения «правильных» языков, пока тот же хаскель я наблюдаю в основном в учебниках же по хаскелю или логике математической. Кстати говоря, неужели математически обоснованная верификация программ уже встроена в хаскель или таки она не «из коробки»?

Утяни мне KDE5 (для KDevelop5) в, например, Wheezy. Или Squeeze.

dpkg-buildpackage -us -uc

?

Требуемые версии библиотек не совпадут.

Требуемые версии библиотек не совпадут.

Ах, ну да, зависимости же. Ну можно поправить в depends на те которые есть.

Брать и выдавать взаимодополняющие условия за взаимоисключаеющие - это дешёвая демагогия.

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

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

Проблемы начинаются когда это уже не proof of concept, а инструмент рабочий. Для proof of concept - подойдёт любая система комп.алгебры. Если proof of concept - это всё что требуется, то нафиг не нужны никакие языки вообще. А вот если надо обработать терабайты данных с какого-нибудь радиотелескопа, или там сотни гигабайт срани с детекторов - то с жабами-питонами это всё может растянуться на долгие годы, и в конце-концов таки полученный результат уже будет никому не нужен.

Не, конечно и для жабы можно jni забабахать, и для питонов с перлами библиотечку написать, но зачем тогда нужны эти язычки, если один хрен на каких-нибудь сях или фортране всё писать придётся?

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

Люди не идеальны, люди делают ошибки. И лучше их предотвращать а не скоростями меряться.

Ошибкой может быть как раз использование питона вместо фортрана, например. :)

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

Ей богу, откуда вы лезете. То питон с явой встают в один ряд, то «JIT - какая разница», то jni забабахивается.

Тебе известна основное применение jni? Почему для оптимизации это редко когда вариант и по каким причинам? Вопрос риторический, видно, что нет.

О, еще один эмбеддещик и царь сишки с мемасами про тормозную яву

О, ещё один обладатель 32х ксеонов, терабайта рамы и коган жабы, со сказками про нетормозящее JRE.

Тебе известна основное применение jni? Почему для оптимизации это редко когда вариант и по каким причинам? Вопрос риторический, видно, что нет.

Ну заюзай какую куду или OpenCL из жабки, ага. С железом там пообщайся, да хоть с LabVIEW каким. Без JNI.

А вариант это хреновый потому, что в этом случае смысл в жабе пропадает совсем.

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

Так он мне чисто эстетически не нравится.

1. Не нравится ни рыба, ни мясо типизация. Вроде типы есть, а контроль их отсутствует. Ну то есть, как я понимаю, тип проверить *можно*, но опечатки тебе никто не выловит... Это хорошо работает в том же матлабе, где типов раз-два и обчелся: скаляр, вектор-столбец/строка, матрица, n-мерный массив, указатель на функцию. Но в питоне система типов может быть весьма развесистая, хорошо бы как то заставлять его хоть варнингами плеваться, но я не знаю как.

2. Не нравится индексация массивов в numpy с 0. В матлабе и фортране она с 1. Не нравится C-шный дефолт по упорядочению массивов. Неудобно переключаться и портировать. Матлабовские алгоритмы после чистки я почти дословно переписываю на фортран, без заботы таких гадких мелочах.

3. Не нравятся, что питон вводит свои «питонизмы». Например, for i in range(n) мне кажется куда менее естественным, чем матлабовское for i=1:n, мэпловское for i from 1 to 10 или сокращенное i=1..n или даже фортрановское do i=1,10. Бесит.

В общем, хотя я и пользуюсь научным софтом писанным на питоне, и иногда даже его дополняю/правлю, душа у меня к питону так и не легла. Возможно из-за того, что все мои use cases покрываются матлабом/октавой или фортраном/c++. Символьная математика у меня в мэпле, текстовая обработка bash/gawk/grep/sed, а питон мог бы быть универсальной заменой всему этому... но так и не стал, наверное потому что я никогда не искал себе «швейцарский нож», а изучал узкоспециализированные инструменты.

Питон не нужен, хоть это не все осознают.Для научных вычислений - матлаб/октава уже давно как отлично вычисляют, строят, пашут и т.д. Зачем ставить очередной велосипед, когда это можно реализовать без велосипеда и осваивания говноязыка? И да, не понимаю нахера читать лекции по тому материалу, который повторяет известные книжки по языку? Показать что ты книгу прочитали или освоил материал или что? Масса копипасты ни разу не приносит понятность (вот было время когда был только Керниган-Ричи и все писали вполне годно).

Именно так и делают. Вот, например: http://corticalcafe.com/prog_CGHmaker.htm

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

Не, конечно и для жабы можно jni забабахать, и для питонов с перлами библиотечку написать, но зачем тогда нужны эти язычки, если один хрен на каких-нибудь сях или фортране всё писать придётся?

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

Зачем ставить очередной велосипед, когда это можно реализовать без велосипеда и осваивания говноязыка?

Питон намного быстрее и удобнее, чем октава.

Именно так и делают. Вот, например: http://corticalcafe.com/prog_CGHmaker.htm

И да, при чем тут больные с java головного мозга? Речь шла про питон. На питоне ни один вменяемый человек не делает численные методы напрямую, т. к. не составляет труда на C модуль написать, в отличие от жабы. То что java не подходит для этих целей, я и не спорю.

Ну можно поправить в depends на те которые есть.

Qt5 в squeeze просто нет. Можно собрать, наверное, но...

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

Какой глупый нынче школьник пошел.

Динамическая типизация - да, проблема. Но, если сравнивать с Matlab (а не с Haskell), это не проигрыш не видно.

Это хорошо работает в том же матлабе, где типов раз-два и обчелся: скаляр, вектор-столбец/строка, матрица, n-мерный массив, указатель на функцию. Но в питоне система типов может быть весьма развесистая

Но в Matlab это просто невыразимо .

текстовая обработка bash/gawk/grep/sed, а питон мог бы быть универсальной заменой всему этому... но так и не стал

У тебя, наверное, текстовая обработка простая :)

Питон намного быстрее и удобнее, чем октава.

Ответ должен быть примерно таким:

- А си намного удобнее и быстрее, чем питон! - Какие ваши доказательства?! - Кокаинум!!!

Т.е. ты видишь? Я утверждаю тезис и подтверждаю его пруфом, у тебя же «мне питон нравится, он удобнее».

Я утверждаю тезис и подтверждаю его пруфом

Не подтверждаешь.

почему такой серьёзный?

Какой толк в инструменте пусть он хоть тремя разными методами обоснован и доказан, если уровень его применения исчезающе мал? И для него даже не проглядывается при этом какой-то его области применения. В области формальной верификации программ делают совершенно разные инструменты и для разных языков и прикладных областей, в общем программировании даже basic с его диалектами смотрится куда более живым чем Haskell и сотоварищи, в научном, вот, как вы сами говорите Python пробивает себе дорогу. Так что вопрос то можно считать не отвеченным, а переход на личности ответом не считается.

Т.е. ты видишь? Я утверждаю тезис и подтверждаю его пруфом

Ты извини, но в упор никакого пруфа от тебя не вижу.

А си намного удобнее и быстрее, чем питон

Тут интересно то, что обсуждаемые здесь numpy/scipy - это и есть си.

Тут интересно то, что обсуждаемые здесь numpy/scipy - это и есть си.

Python в научных вычислениях (комментарий)

Потоки не везде подходят, зависит от железа же

Использование этой вашей явы нивелирует преимущества cuda

Мне кажется ты просто маллок не осилил вот и вайнишь за плюсы. На какой системе у тебя всё это работает? На чём эта система написана? Исходники как ни странно .с. Совпадение?

ЩИТО?

Так ты у нас человек-флюгер: что признают другие, то и ты. Завтра популярным станет другой язык, например, Go, ты начнешь говорить по-другому.

Python пробивает себе дорогу

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

Что коряво в PyROOT и какие есть ограничения? Что я не могу сделать в python, но могу в C++ с ROOT?

Мало того что С не осилил, так ещё и русский язык не могу

Доо, «вайнишь за плюсы» - это русский язык просто тургеневского уровня.

Он C++сный один в один — то есть тебе всё равно нужно знать ROOTовский интерфейс во всей его красе. Ограничений в PyROOT нет, кроме скорости — она такая же, как и в случае cint, то есть порядок к скомпилированной программе.

Что мешает написать на C модуль для питона и потом дергать этот метод из модуля?

Речь в теме вроде как об учёных. Которые С не знают. А если знают - зачем им питон?

Питон намного быстрее и удобнее, чем октава.

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

т. к. не составляет труда на C модуль написать, в отличие от жабы.

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

Там вроде Qt5 и libkde5 нужно. Собрать их, если у тебя eclipse нитармазит - минуты 2 наверно займёт. Ну и KDevelop полминуты.

Собрать их, если у тебя eclipse нитармазит - минуты 2 наверно займёт

Собери KDevelop5 на Squeeze - может, поймешь, что проблема не в скорости процессора. Потом повтори упражнение на Lenny.

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

На чистом питоне насколько я знаю реализаций FFT, матриц широкоиспользуемых нет,да только в чем проблема то, если язык может использовать довольно неплохо уже существующие и проверенные библиотеки низкого уровня типа lapack и т.д. Где можно ознакомится тогда с чистыми реализациями матриц, FFT и прочего на «правильных» языках при том чтобы их использовали не три с половиной анонима? Если же их нет, то вопрос сразу возникает: почему при всех шикарных свойствах хаскеля или еще чего-то такого он даже не может предоставить то, что предоставляет «паразит». И мне важно не столько что говорят другие, а каково сообщество языка, его прикладнные наработки,пока по этим параметрам питон неплох, не смотря на то что у него есть проблемы, для меня язык программирования только инструмент, а не священная корова. Я посмотрел тот же Go, любопытный язык, но для моих задач совершенно необязателен, никаких киллер-фич для себя в нем не нашел.

Речь в теме вроде как об учёных. Которые С не знают.

А такие учёные что бывают?

Слушайте вы своей демагогией на тему проблем с установкой KDevelop5 на говне мамонта уже надоели.

На слаке 14 собирал - нет проблем. Почему на дебиане должны быть?

А такие учёные что бывают?

Полно. В лучшем случае - знают фортран (математики и теорфизики обычно). В худшем - юзают матлаб какой-нибудь.

Прости, я был не прав — это ты не прочитанное не понял; я признаю, что ты просто не читал. Во-первых, я не говорил, что один язык лучше другого, я лишь сказал, что «по мне функциональный подход эффективнее», у вас другая точка зрения — это ваше право, но мне об этом знать необязательно. Во-вторых, есть точка зрения известного математика Дейкстры (расслабься, о нем тебе знать тоже не обязательно), почему дело обстоит так. Дело в том, что процедурный подход в случае большого проекта приводит к так называемому комбинаторному взрыву, когда возникающих ситуаций так много, что за ними нет возможности уследить. Что приводит к большому кол-ву багов, повышению издержек на поддержку кода. У функционального подхода этот порог наступает гораздо позже. Спорить о практичности или не практичности функционального подхода с тобой мне не интересно.

Что мешает написать на C модуль для питона и потом дергать этот метод из модуля?

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

Зачем нужен bash если файловые операции можно делать из си, а также запускать программы и связывать их ввод-вывод пайпами и т.п.?

Назови мне IDE для Си++, которая лучше Eclipse CDT.

clion же %) хотя эклипс не пробовал.

Тема про научные вычисления, Си оттуда уже вытеснили? А мужики-то не знают!

Си оттуда уже вытеснили?

Но ведь библиотеки эти для питона на си. А на питоне удобно делать к ним обертки т.к. удачный си api и всякие SWIG.

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

Совершенно очевидно, что большинство физиков, математиков, биологов являются очень плохими программистами (кому не очевидно, могут взять и почитать исходники программ, например в ЦЕРНе и прочих). Есть конечно и исключения. Поэтому основное развитие идёт в простых языках, где что то сделать оно как-то иногда будет работать проще. Дальше выгодно брать ЯП, где такого больше, поэтому Р и питон гораздо лучше подходит для многих, где из палок и прочего можно создать какой-то вычислительный эксперимент.

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

Однако ситуация может поменяться, если вам нужно определённое качество софта и у вас есть квалифицированные специалисты, за примером успеха можете посмотреть Amgen (это те с Кес мне приходилось работать). По haskell и Amgen можно быстро нагуглить несколько интересных статей с историями успеха.

//qnikst

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