Комментарии 54
Что-то я так ничего и не понял. Чем же он так хорош? Единственный пример с массивами так и не доведен до логической развязки. В общем — видимо, минусы не зря поставили.
как в том анектоде.
и не питон а библиотеки Numpy и Scypy и.т.п
и не хороши, а плохи по производительности по сравнению с тем же
Tensorflow для CPU не говоря уже о паралельном железе.
и не питон а библиотеки Numpy и Scypy и.т.п
и не хороши, а плохи по производительности по сравнению с тем же
Tensorflow для CPU не говоря уже о паралельном железе.
Python «хорош» в научных вычислениях из-за низкого порога вхождения.
Для большинства людей, занимающихся наукой (даже теорией), необходим инструмент для каких-никаких расчетов, да чтоб еще графики рисовал. В моей области когда-то давно был такой монстр как IDL, но сейчас все поголовно пишут на Python.
При этом зачастую не используются никакие фичи языка кроме стандартных циклов/ветвлений, функций и многомерных (в лучшем случае) массивов. Всё.
Т.к. никто не хочет тратить время на «это ваше программирование», ни об ООП, ни об оптимизации, ни о чем либо еще люди даже не слышали. К исследованиям Python не побуждает, т.к. почти всё нужное среднестатистическому учёному можно найти в той или иной библиотеке.
Провал между средним «научным» программированием и средним «профильным» программированием настолько велик, что, измеряя его в годах задержки, эквивалентен лагу в хороших лет 30. Такие дела.
Всё вышенаписанное — личное мнение, основанное на личном опыте.
Для большинства людей, занимающихся наукой (даже теорией), необходим инструмент для каких-никаких расчетов, да чтоб еще графики рисовал. В моей области когда-то давно был такой монстр как IDL, но сейчас все поголовно пишут на Python.
При этом зачастую не используются никакие фичи языка кроме стандартных циклов/ветвлений, функций и многомерных (в лучшем случае) массивов. Всё.
Т.к. никто не хочет тратить время на «это ваше программирование», ни об ООП, ни об оптимизации, ни о чем либо еще люди даже не слышали. К исследованиям Python не побуждает, т.к. почти всё нужное среднестатистическому учёному можно найти в той или иной библиотеке.
Провал между средним «научным» программированием и средним «профильным» программированием настолько велик, что, измеряя его в годах задержки, эквивалентен лагу в хороших лет 30. Такие дела.
Всё вышенаписанное — личное мнение, основанное на личном опыте.
К исследованиям Python не побуждает, т.к. почти всё нужное среднестатистическому учёному можно найти в той или иной библиотеке.
Об этом и речь. Если бы человек хотел заниматься программированием — стал бы программистом, разве нет? А если инструмент прост в освоении и подходит для решения научных задач — в чём польза от времени, потраченного на изучение «профильного» программирования?
Ничего не имею против «программирования ради программирования», но у всего есть свои границы применимости.
Интересно было почитать про IDL, спасибо! А что у вас за область, если не секрет?
IDL никогда не пользовался (я несколько младше, не застал), но «старшие» (от 35 где-то) всё еще его используют. Я вычисления/графики делаю на R (и я один такой на отделении).
Специальность — астрофизика.
Специальность — астрофизика.
+ в карму R (его редко цитируют где-либо в рунете). Я тоже на R фигачу. Но сам этот факт не отделяет этот язык от Python в срезе
К исследованиям Python не побуждает, т.к. почти всё нужное среднестатистическому учёному можно найти в той или иной библиотеке.Хотя, в чем-то и отделяет, например, через возможность связать функции библиотеки с рядом публикаций, указанных в help.
А что вы имеете в виду под возможностью связать публикации? Действительно интересно. Это не то же самое, что например в питоне — вот хелп первой попавшейся функции из scipy, там для всего разумного даны ссылки. И такое видел во многих библиотеках, несколько раз действительно смотрел указанные статьи когда нужно было.
Я имею в виду, что открывая help в любой функции из R stats:: или из другой библиотеки можно уточнить смысл некоторых — говоря языком разработчика — скалярных значений, возвращаемых этими функциями при определенных условиях, либо же в целом понять подход, который закодирован в этих функциях, почитав публикации в реферируемых журналах. Пример для семейства функций gamma:
Пример для функции регуляризованной обобщенной регрессии glmnet:
И, вдогонку к последнему примеру, обсуждение формулы для смешанной регуляризации на профильном ресурсе (обсуждение на уровне топовых представителей математической статистики): https://stats.stackexchange.com/questions/326427/why-does-glmnet-use-naive-elastic-net-from-the-zou-hastie-original-paper/327129#327129
Все это подстегивает определенный исследовательский интерес. Но, в целом, его подстегивает, в первую очередь, заказ на глубину объяснения используемых методов со стороны заказчика. Если его нет, то тут уж сам скорее себя драйвишь.
dgamma is computed via the Poisson density, using code contributed by Catherine Loader (see dbinom).
pgamma uses an unpublished (and not otherwise documented) algorithm ‘mainly by Morten Welinder’.
qgamma is based on a C translation of
Best, D. J. and D. E. Roberts (1975). Algorithm AS91. Percentage points of the chi-squared distribution. Applied Statistics, 24, 385–388.
plus a final Newton step to improve the approximation.
rgamma for shape >= 1 uses
Ahrens, J. H. and Dieter, U. (1982). Generating gamma variates by a modified rejection technique. Communications of the ACM, 25, 47–54,
and for 0 < shape < 1 uses
Ahrens, J. H. and Dieter, U. (1974). Computer methods for sampling from gamma, beta, Poisson and binomial distributions. Computing, 12, 223–246.
Пример для функции регуляризованной обобщенной регрессии glmnet:
Author(s)
Jerome Friedman, Trevor Hastie, Noah Simon and Rob Tibshirani
Maintainer: Trevor Hastie hastie@stanford.edu
References
Friedman, J., Hastie, T. and Tibshirani, R. (2008) Regularization Paths for Generalized Linear Models via Coordinate Descent, web.stanford.edu/~hastie/Papers/glmnet.pdf
Journal of Statistical Software, Vol. 33(1), 1-22 Feb 2010
www.jstatsoft.org/v33/i01
Simon, N., Friedman, J., Hastie, T., Tibshirani, R. (2011) Regularization Paths for Cox's Proportional Hazards Model via Coordinate Descent, Journal of Statistical Software, Vol. 39(5) 1-13
www.jstatsoft.org/v39/i05
Tibshirani, Robert., Bien, J., Friedman, J.,Hastie, T.,Simon, N.,Taylor, J. and Tibshirani, Ryan. (2012) Strong Rules for Discarding Predictors in Lasso-type Problems, JRSSB vol 74,
statweb.stanford.edu/~tibs/ftp/strong.pdf
Stanford Statistics Technical Report
Glmnet Vignette web.stanford.edu/~hastie/glmnet/glmnet_alpha.html
И, вдогонку к последнему примеру, обсуждение формулы для смешанной регуляризации на профильном ресурсе (обсуждение на уровне топовых представителей математической статистики): https://stats.stackexchange.com/questions/326427/why-does-glmnet-use-naive-elastic-net-from-the-zou-hastie-original-paper/327129#327129
Все это подстегивает определенный исследовательский интерес. Но, в целом, его подстегивает, в первую очередь, заказ на глубину объяснения используемых методов со стороны заказчика. Если его нет, то тут уж сам скорее себя драйвишь.
Вижу, что для этого примера в Python также есть ссылки. Но я не говорю, что это самый главный фактор превращения программиста в ученого, но как бы в R-сообществе этому принято больше внимания уделять, что-ли.
+ в карму R (его редко цитируют где-либо в рунете). Я тоже на R фигачу. Но сам этот факт не отделяет этот язык от Python в срезе
"Редко цитируют" не довод для ученого!
Я на Matlab работал с 1989 года с версии 2.0 до примерно 2005.
В течение 12 лет я не встречал ни одного человека, который бы тоже работал в Matlab, за исключением своего универовского друга, который меня и "подсадил", коллег, с которыми я сам поделился сей радостью, и своих студентов.
И с появлением ру интернета очень долго — годы! — никто про матлаб даже не упоминал. Так что ссылки в инете не есть "наше все".
В этой цитате никаких доводов и не было!
Я только вношу маленький вклад в популяризацию.
Я только вношу маленький вклад в популяризацию.
Я понял, что это довод, но не Ваш, а скорее, Ваших оппонентов и вы его во внимание не особо принимаете, а продолжаете на R фигачить. Я понял так и попытался поддержать описанием своего примера с матлабом.
Удачи! :)
Удачи! :)
Ок, и Вам. Я вообще не ученый, просто довольно много статистики в моей DS-работе (на production, в том числе).
Пишем большой проект одновременно на R и Python. Обкладываем проверками, используем быстрые библиотеки для прожевывания датафреймов. Мой коллега на Py пишет в стиле OOP, я, как не программист, пишу функционально. Объемы кода до 10К строк. Все крутится на production в docker container. Переходим на Spark. И R и Python идут нос в нос, но на R быстрее разработка идет. Также были сложности с переносом в Py логики расчета доверительных интервалов для моделей (то, что в R вызывается в функции, в Py решается матричными операциями, что опять же накладывает ограничение на скорость разработки).
Также были сложности с переносом в Py логики расчета доверительных интервалов для моделей (то, что в R вызывается в функции, в Py решается матричными операциями, что опять же накладывает ограничение на скорость разработки).
Не только скорость разработки, еще и делегирование ответственности влияет на выбор тулсов.
По степени доверия в вопросах статистики опенсорсный R, пожалуй, уже приближается к SAS.
Да, без проблем найти формулы для доверительных интервалов (и прочей статистической лабуды). И джуниор запрограммирует хоть на питоне, хоть на сях, хоть на фортране.
Вот, только, в серьезный продакшен лучше запускать статистику на надежных библиотеках, а не самописанную. Я так думаю.
По своему опыту научной работы могу сказать, что когда над задачей работает от одного до нескольких человек, он повторном использовании кода речи не идёт. Пишут как получится, используются минимальные возможности языка, о системах контроля версий большинство не знает. Да и в общем потоке информации которую необходимо изучать ( математика, физика) для программирования места почти нет. Может быть, если бы на первых курсах универа больше уделяли этому внимания, ситуация могла быть лучше.
Т.к. никто не хочет тратить время на «это ваше программирование», ни об ООП, ни об оптимизации [...]А зачем? ООП ради ООП, программирование ради программирования? Вы путаете программирование для автоматизации и программирование для вычислений.
Провал между средним «научным» программированием и средним «профильным» программированием настолько велик, что, измеряя его в годах задержки, эквивалентен лагу в хороших лет 30. Такие дела.
Когда мне нужно написать, к примеру, бекенд для веб-приложения, я проектирую архитектуру, пишу классы, использую фреймворки и всё такое.
Когда мне нужно проверить теорию, к примеру, time series forecasting с помощью Х, я беру python, открываю jupyter notebook, пишу модель, тестирую ее, визуализирую результаты, подвожу итоги. Если результат удачный, я перепишу получившийся алгоритм для продакшена, а этот код выкину. Если нет — я этот код опять-таки выкину. Какой смысл наводить красоту в, по сути, одноразовом коде?
Если результат удачный, я перепишу получившийся алгоритм для продакшена, а этот код выкину.Подскажите, а это на сколько трудозатратно. Я вот тоже смотрю в сторону ML, эксперементирую с Anaconda, skikit-learn. Хотел бы ввести некоторые модели и наработки в прод. Сам я также занимаюсь бэкэндом под .NET, архитектурой, БД и автоматизацией в общем. И вот задумался, как бы лучше ввести в продакшн некоторые алгоритмы из библиотеки skikit-learn…
Для моих целей лучший результат дают простые линейные модели, которые можно на любом языке без проблем «в лоб» написать, без библиотек. Чем больше фич учитывает модель, чем она сложнее — тем хуже в итоге результат на out of sample.
Если же использовать что-то сложное, то лучшее, до чего я смог дойти — запихнуть модель в микросервис на питоне, залить в облако для маштабирования, и обращаться к нему по рест-апи с бекендов на других языках.
Если же использовать что-то сложное, то лучшее, до чего я смог дойти — запихнуть модель в микросервис на питоне, залить в облако для маштабирования, и обращаться к нему по рест-апи с бекендов на других языках.
Возможно мы немного о разном говорим, но в моем случае код пишется один раз «как есть», не важно, как хорошо он работает, считает ли он сутки то, что при небольшой оптимизации считается за час. Никакого «перепишу потом». И хорошо, если один раз написал, опубликовал и забыл. А если через пол года этот код отдается в руки студенту для проекта «а давайте учтем еще один фактор в модели»? Когда ни писавший этот код ни тем более другой не-программист не могут понять, что же в нем происходит? Например из-за повального отсутствия комментариев и выражений вида
Если вы когда-нибудь работали с legacy-кодом, то представьте что здесь «legacy»-код зачастую пишется в реальном времени.
Понятное дело что ни у кого нет времени писать качественный код, когда нужно делать науку. Хотя вот сейчас пошла мода на требование исходников при публикации определенных типов работ. Может это поправит ситуацию.
cc1 = aa1 + bb1;
c2 = cc1 * dg3Если вы когда-нибудь работали с legacy-кодом, то представьте что здесь «legacy»-код зачастую пишется в реальном времени.
Понятное дело что ни у кого нет времени писать качественный код, когда нужно делать науку. Хотя вот сейчас пошла мода на требование исходников при публикации определенных типов работ. Может это поправит ситуацию.
На самом деле оптимизации не помешали бы. Я бы не отказался от такого языка, компилятор которого анализирует поток вычислений и делает из него машинный код, аналогичный оптимизированому на с. Помню, сидел я как то 3 дня, за которые компьютер воспроизвёл всего 13 лет жизни системы. А нас интересовала тясяча. Код тогда никто не переписывал, просто закинули на суперкомп. Получить доступ к суперкомпьютеру оказалось проще, чем уговорить кого-то переписать код на с++, потому что на фоне пайтона это объективно — ад. Хотя скорость выполнения искушает…
В моей области (астрофизика) царит огромный зоопарк языков программирования, библиотек и инструментов. IDL — только одна маленькая клеточка, причиняющая боль всей голове кучей необходимого легаси кода и проприетарных зависимостей. Многие направления десятилетиями развивались независимо, результат — практически у каждой специализированной софтины (пакета) есть свой уникальный интерфейс командной строки, свой скриптовый язык, свой формат конфигов. И конечено же, цимес в том, что сейчас, в эпоху великого объединения, требуется работать сразу с добрым десятком таких пакетов (астрономия стала воистину всеволновой!). К счастью, многие значимые для меня проекты стали использовать Python в качестве своего рода командной оболочки. Это радикально упрощает жизнь. Пиши вычислительный код на чём пожелаешь (хоть на Brainfuck), строй графики в экселе, но интерфейсик делай на Python)). Python в науке для учёного — скорее как bash или powershell в *nix/win для юзера/админа. Не стоит удивляться, что возможности языка часто используется слабо. Может это и к лучшему.
С задачей системной интеграции прекрасно справляются множество языков. TCL первым озаботился этой проблемой и вполне успешно ее решал. Lisp замечательно может справиться с интергацией. С помощью различных RPC-подобных протоколов, от CORBA до GraphQL, интеграцию можно осуществлять практически на любом языке. То же можно делать на системах обмена сообщениями.
--интеграцию можно осуществлять
--То же можно делать
Почти никогда нельзя.
Не видил ни одного учёного крупного вне математики (в меньшей степени) или информатики (в большей) который бы тратил силы на интеграцию с корбой, GraphQL или кафкой.
Для этого есть специально обученые аспиранты.
--То же можно делать
Почти никогда нельзя.
Не видил ни одного учёного крупного вне математики (в меньшей степени) или информатики (в большей) который бы тратил силы на интеграцию с корбой, GraphQL или кафкой.
Для этого есть специально обученые аспиранты.
А на питоне видели?
Все биндинги написаны теми же аспирантами или самими разработчиками библиотек. И даже не потому-что к питону биндинги писать проще, а потому-что он уже популярен и при наличии биндингов к питону библиотекой скорее станут пользоваться. Все преимущество в положительной обратной связи популярностей у разработчиков библиотек и конечных пользователей. В системах с такой связью велико влияние случайности и совсем не обязательно побеждает лучший.
Все биндинги написаны теми же аспирантами или самими разработчиками библиотек. И даже не потому-что к питону биндинги писать проще, а потому-что он уже популярен и при наличии биндингов к питону библиотекой скорее станут пользоваться. Все преимущество в положительной обратной связи популярностей у разработчиков библиотек и конечных пользователей. В системах с такой связью велико влияние случайности и совсем не обязательно побеждает лучший.
Почему ruby не стал таким популярным?
Заметку как раз на эту тему я изначально и увидел: jeffknupp.com/blog/2017/09/15/python-is-the-fastest-growing-programming-language-due-to-a-feature-youve-never-heard-of
Вкратце: буферный протокол, позволяющий эффективно работать с данными.
Вкратце: буферный протокол, позволяющий эффективно работать с данными.
Потому что основная документация к нему очень долго была на японском и медленно переводилась на английский.
Сейчас уже интересно, почему не взлетает Julia…
Потому что есть питон и R и этого достаточно? Кстати, как у Julia с параллельностью?
На параллельность они и давят, вроде бы.
Очень хорошо. Вообще мы сравнивали решение нескольких задач на нескольких языках. Julia выдавала результаты сравнимые с C/C++ с OpenMP и примерно в 16-24 раз быстрее чем Матлаб (Пухтон и R кстати медленнее Маталаба), которому даже Parallel Toolbox Не помог, хотя если использовать GPU, то Matlab тоже хорошие результаты показывает (если закрыть глаза на неоптимальное использование видеопамяти), как C/C++ и Julia на CPU :-)
До сих пор нет еще релизной версии языка, дебаггер пока еще неудобный (чего я лично жду, еще я жду нормальной сборки библиотек без танцев с бубном), нету такого клочиества тулбоксов (мне то пофиг, но вот много народу уже слишком разбалованны всякими fir1), как у того же Матлаба. В общем язык еще сырой. Но вообще он (она?) оказался хорошей альтернативой Фортрану и Си.
Ну и инерция еще, хотя народ (буржуи) на него постепенно переходит.
Ну и инерция еще, хотя народ (буржуи) на него постепенно переходит.
НЛО прилетело и опубликовало эту надпись здесь
Да, не очень ясный момент. Подозреваю, что автор имел в виду отсутствие многомерности «как в NumPy». В Java, насколько я понимаю, приведённый вами код это всё таки «массив массивов массивов», то есть массив указателей на массивы указателей на массивы элементов. В Python ndarray — это гораздо более гибкая штука, по сути — кусок памяти, который можно разбить на элементы произвольным образом.
Это будет не массив массивов? То есть с дополнительным уровнем коственности на каждый индекс?
Это не многомерный массив в numpy'евском понимании, это массив указателей на массивы указателей на массивы.
Под многомерным массивом тут понимается непрерывный кусок памяти у которого «многомерность» появляется только на этапе индексации. Это дает всякие плюшки типа быстрых решейпов, быстрой индексации, лучшего обращения к кешу и так далее.
Нативно в java такого нет, есть в C#:
Под многомерным массивом тут понимается непрерывный кусок памяти у которого «многомерность» появляется только на этапе индексации. Это дает всякие плюшки типа быстрых решейпов, быстрой индексации, лучшего обращения к кешу и так далее.
Нативно в java такого нет, есть в C#:
byte[ , , ] arr = new byte[2, 3, 8]Операции умножения, скалярного произведения, тензорного произведения, обращения матрицы и т.п. там из под коробки есть? А собственные числа, число обусловленности, всякие разложения матрица (SVD, верхнетреугольные и т.д.) там есть?
Комплексные и гиперкомплексные числа?
А как с памятью дело обстоит? Это будет отдельный кусок в памяти или указатели, на указатели на разбросанные по всей памяти ячейки?
Комплексные и гиперкомплексные числа?
А как с памятью дело обстоит? Это будет отдельный кусок в памяти или указатели, на указатели на разбросанные по всей памяти ячейки?
Многие положения статьи показывают, что автор не имел счастья поработать с приличным коммерческим научным софтом, который существовал во все времена, но был не для всех.
Все, что в статье ставится в заслугу Питону, придумано и воплощено давно и другими авторами, как говаривал мой шеф.
Кроме тех преимуществ, которые дал Питону опенсорс, ничего выдающегося в нем для науки ИМХО нет. R люблю больше.
Питон использую вынужденно, если нужен доступ к библиотекам,, с которыми R не подружили.Например OpenCV
Сейчас питон просто «достаточно хорош» по сути во всех областях, пусть и не является везде лучшим. Зато можно знать по сути один язык, и иметь готовые функции для огромного количества математических операций (numpy, scipy, другие более мелкие библиотеки), писать достаточно тяжёлые численные вычисления (numba), заниматься статистикой включая продвинутую байесовскую (pymc), писать маленькие и большие скрипты, делать сайты (flask, django, ...), рисовать графики и иллюстрации (matplotlib), и многое другое. И пусть в одной области несколько лучше чем python будут C/Fortran, в другой R, в третьей например nodejs — но библиотек на любой случай жизни уже столько, что другие языки нужны в очень-очень узких случаях.
Всё вышеописанное конечно не относится к программистам, у которых программа это основной выходной результат — скорее к учёным или людям, программирование для которых является именно инструментом. Сейчас вижу, как у нас всё больше и больше людей разных возрастов (как минимум до 40-50) переходят на питон со всяких fortran, idl, perl и т.п.
Но почему библиотеки «для всего» появились именно в питоне, а не в каком-нибудь R, я что-то так и не понял.
Всё вышеописанное конечно не относится к программистам, у которых программа это основной выходной результат — скорее к учёным или людям, программирование для которых является именно инструментом. Сейчас вижу, как у нас всё больше и больше людей разных возрастов (как минимум до 40-50) переходят на питон со всяких fortran, idl, perl и т.п.
Но почему библиотеки «для всего» появились именно в питоне, а не в каком-нибудь R, я что-то так и не понял.
Но почему библиотеки «для всего» появились именно в питоне, а не в каком-нибудь R, я что-то так и не понял.
Положительная обратная связь. Много пользователей — имеет смысл разработчикам делать биндинги своих библиотек, доступно много библиотек — у пользователей появляется стимул перейти в эту экосистему.
Но почему библиотеки «для всего» появились именно в питоне, а не в каком-нибудь R, я что-то так и не понял.
Что и где появилось впервые — вопрос спорный.
Вот здесь главный (но не единственный) репозиторий библиотек R.
В принципе, это нарастающий холивар -- R vs Python in Data Science
Посмотрите, может найдете что-нить для себя.
Мой взгляд на этот вопрос — выбор во многом зависит кто и откуда приходит в то, что сейчас называют Data Science.
К R приходят те, чей путь тем или иным образом проходит через медико-биологические и кондово-статистические задачи. Т.е. из науки (исходно без программирования), но с кучей данных.
В Python-Sci приходят из программирования, когда открывают для себя науку.
Но эти часто бросаются в Python вместо (бездарного по их мнению) сидения в библиотеке и изучения наследия гигантов. Вот они погуглили, все поняли, а потом все, что они поняли, расскажут коротко и ясно в 3-х минутном ролике на Ютубе.
Утрирую, конечно…
За что и почему я люблю R я писал.
Мой взгляд на этот вопрос — выбор во многом зависит кто и откуда приходит в то, что сейчас называют Data Science.
К R приходят те, чей путь тем или иным образом проходит через медико-биологические и кондово-статистические задачи. Т.е. из науки (исходно без программирования), но с кучей данных.
В Python-Sci приходят из программирования, когда открывают для себя науку.
Но эти часто бросаются в Python вместо (бездарного по их мнению) сидения в библиотеке и изучения наследия гигантов. Вот они погуглили, все поняли, а потом все, что они поняли, расскажут коротко и ясно в 3-х минутном ролике на Ютубе.
Утрирую, конечно…
За что и почему я люблю R я писал.
В data science — может и нарастающий холивар, не буду спорить (хотя все знакомые в этой отрасли преимущественно используют питон, да и курсы в основном на нём). И я знаю, что в R есть больше статистических библиотек — но ведь data science и статистика это только один из огромного массива применений для языка программирования. В R, насколько я знаю, далеко не так удобно писать например сайты, скрипты автоматизации; ООП так себе в нём реализовано; биндинги для всяких нишевых библиотек реже есть готовые. Ну и лично мне сам язык не понравился, хотя начал немного писать на нём примерно одновременно с питоном :)
А, ещё очень удобная среда сначала появилась именно для питона — ipython notebook, это уже потом куда подключили всё что можно. И сейчас намного проще писать на питоне, изредка для очень узкоспециализированных вещей используя например R, чем наоборот.
А, ещё очень удобная среда сначала появилась именно для питона — ipython notebook, это уже потом куда подключили всё что можно. И сейчас намного проще писать на питоне, изредка для очень узкоспециализированных вещей используя например R, чем наоборот.
Вообще-то notebook сначала появился для Wolfram Mathematica.
Ну вольфрам это всё-таки не general purpose язык, его напрямую странно сравнивать с питоном. Я имею в виду из нормальных языков — а из них питон первый получил notebook.
А, ещё очень удобная среда сначала появилась именно для питона — ipython notebook
Идею нотбука на PC я впервые осязал в Mathcad V2.6.
Я с ним немного работал параллельно с Матлабом, но потом Матлаб победил.
спойлер
А вообще я опасаюсь исторические изыскания молодых и ищущих как вот тут с Питоном. Что компьютер изобрел Бил Гейтся и Стив Джобс — это я уже слышал.
В общем, не против Питона я.
Не сотвори себе кумира — я вот о чем.
Прочитайте комментарий прямо над вашим — он абсолютно так же применим к Mathcad, как и к wolfram mathematica. Оба этих продукта странно напрямую сравнивать с нормальными языками (типа C/Python/...).
исторические изыскания молодых и ищущих
Не знаю насчёт комментаторов, но автора статьи едва ли можно назвать молодым. Он вообще являлся одним из разработчиков Numerical Python, так что, надо полагать, знает о чём говорит.
Сопутствующие bias — отдельная тема, но как попытка описать возможные причины объективно наблюдаемой популярности Python — почему бы и нет?
Научные вычисления научным вычислениям рознь. Если говорить про анализ данных, то
есть большая четвёрка универсальных программ, есть куча мелких полезных специализированных программ, есть недо-программы. Python (в части набора библиотек по анализу данных) видимо входит в третью группу.
Как универсальная платформа, библиотеки python не дотягивают ни до R, ни до SAS, ни до Matlab. Если человек не работал в статистических программах, то он вряд ли поймёт минусы python, у него нет какого-то сценария, что должен делать уважающий себя статпакет с пол пинка.
По скорости обработки данных тоже есть вопрос. Если pandas относительно молодой, перспективный, то почему он медленнее того же data.table в R?
есть большая четвёрка универсальных программ, есть куча мелких полезных специализированных программ, есть недо-программы. Python (в части набора библиотек по анализу данных) видимо входит в третью группу.
Как универсальная платформа, библиотеки python не дотягивают ни до R, ни до SAS, ни до Matlab. Если человек не работал в статистических программах, то он вряд ли поймёт минусы python, у него нет какого-то сценария, что должен делать уважающий себя статпакет с пол пинка.
По скорости обработки данных тоже есть вопрос. Если pandas относительно молодой, перспективный, то почему он медленнее того же data.table в R?
Как говорил мой преподаватель, Python — это клей между большим количеством разнообразных готовых библиотек.
Сравнивать реальную сигрантуру методов, а не объявленые типы — иногда хорошо, но динамическая типизация по мне всё равно — это плохо. По мне гораздо лучшее решение в Swift — если какой-то класс не реализует нужный протокол, а просто совпадает сигнатура, то в расширении можно объявить, что он его реализует. Причём протоколы в Swift могут содержать конструкторы, и существует понятие оябзательного конструктора. А ещё любую структуру можно объявить константой: если вызов функции меняет данные, то это можно объявить, и компилятор не позволит вызвать эту функцию для константы. И кроме того, если какой-то параметр должен содержать значение, в т. ч. ссылочный тип, то в Swift это тоже можно объявить, и компилятор не позволит передать туда пустой указатель. А если нужно объединить протоколы, можно даже не использовать наследование — хватит typealias.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Python так хорош в научных вычислениях