Почему Python так хорош в научных вычислениях

http://blog.khinsen.net/posts/2017/09/12/why-python-does-so-well-in-scientific-computing/
  • Перевод

Несколько дней назад (Оригинал заметки был опубликован 12 сентября 2017. — Здесь и далее прим. переводчика), я заметил этот твит в своей ленте:



Я 'всё ещё' программирую на Си. Почему? Подсказка: дело не в производительности. Написал эссе с разбором… появится на Onward!

(Onward! — одна из конференций в составе SPLASH, посвящённая обсуждению новых идей и парадигм в программировании и размышлениям о программном обеспечении.)


Это показалось хорошим чтением на выходные — им оно и было. Главный аргумент, который приводит автор: язык Си остаётся непревзойдённым как язык системной интеграции, потому что разрешает взаимодействовать с "чужим" кодом, то есть кодом, написанным независимо и возможно даже на других языках, вплоть до ассемблера. Фактически, Си — один из немногих языков программирования, позволяющих иметь дело с любыми данными на уровне байтов. Большинство более "современных" языков запрещают такое взаимодействие во имя безопасности: вся память, к которой вы можете получить доступ — это память, выделенная с помощью безопасной среды исполнения языка. Как следствие, вы застреваете в его замкнутой вселенной.


Системная интеграция — несомненно важный аспект работы с программным обеспечением, который часто упускают из виду. И это особенно верно для научных вычислений (scientific computing), где прикладное программное обеспечение с фиксированным набором функций встречается редко. Чтобы решить научную задачу часто требуется собрать множество кусочков программ в сильно зависящее от конкретной проблемы целое, которое, возможно, будет запущено всего пару раз (смотрите также мой более ранний пост на эту тему). Это в точности та задача, которой занимается системная интеграция: собрать из кусочков единое целое, при необходимости используя связующий код. В вычислительной науке (computational science) связующий код принимает форму скриптов, потоков работ (workflows) и, в последнее время, блокнотов (notebooks). C технической точки зрения это заметно отличается от системной интеграции на уровне операционной системы, на которую ссылается Стивен Келл, но функционально это то же самое.


Статья Стивена напомнила мне о давнем плане написать в блог о том, почему Python так успешен в научных вычислениях, несмотря на его репутацию языка с плохой производительностью. Так что… вот она.


Разумеется, причин успеха Python много, но одна из них — он отлично справляется с задачами системной интеграции. Python обладает двумя особенностями, которые я считаю важными в этом деле, и которые не поддерживаются многими другими языками. Одна — типы данных, явно разработанные для связывания (interfacing); другая — утиная типизация в сочетании с маленьким, но гибким набором стандартных интерфейсов.


Первый тип данных Python, разработанный для связывания в контексте научных вычислений — старый добрый массив NumPy, который на деле оказывается старше NumPy, будучи представлен в 1995 году его предшественником, Numeric. Массивы — это один из типов данных, являющихся "хлебом насущным" научных вычислений, вплоть до того что это единственный тип, доступный в языках вроде Fortran 77 или APL. Реализация массивов в Numeric была разработана для использования с той же схемой расположения данных, что и в Фортране с Си, чтобы обеспечить взаимодействие с библиотеками на Фортране и Си, доминировавшими в научных вычислениях в 1995 году (и до сих пор, хоть и в меньшей степени). За Numeric и, позднее, NumPy всегда стояла идея использовать Python как связующий язык для библиотек на Фортране и Си, и добиваться скорости, делегируя критичные по времени операции коду, написанному на этих языках.


Второй тип данных Python, спроектированный для связывания — это memoryview, связанный с buffer protocol. Здесь Python ближе всего подбирается к Си-образному доступу к памяти. Буферный протокол позволяет разным типам данных Python получать доступ к внутренностям друг друга на уровне байтов. Типичным примером использования может быть тип данных изображения (например из Pillow), с доступом к представлению изображения в памяти через тип массива (например из NumPy), что позволяет реализовать алгоритмы работы с изображениями в виде операций над массивами.


Третий и наименее известный тип данных Python для связывания — это capsule, заменяющий более ранний CObject. Капсулы существуют исключительно на благо написанных на Си модулей Python, которые с помощью связующего кода на Python могут обмениваться друг с другом непрозрачными данными, даже несмотря на то, что сам связующий код не может как-либо проверить или обработать данные. Типичный пример: обернуть указатели на функцию на языке Си в объект Python так, чтобы связующий код на Python — скрипт, например, — мог передать функцию на Си из одного модуля коду на Си в другом модуле.


Все эти интерфейсные типы данных служат посредниками между кодом на Python и Си, хотя зачастую системный интегратор на Python вообще не подозревает об использовании кода на Си. Другая особенность Python для системной интеграции, утиная типизация со стандартными интерфейсами, способствует связыванию независимо написанных модулей Python. Под "стандартными интерфейсами" я понимаю интерфейсы последовательности (sequence) и словаря (dictionary), а также стандартные имена методов для перегрузки операторов.


Чтобы увидеть, почему эта особенность важна, посмотрим на статически типизированные языки, в которых она намеренно отсутствует. В качестве конкретного примера возьмите многомерные массивы Java. Они не являются частью языка или стандартной библиотеки, но могут быть реализованы поверх них с разумными усилиями. Фактически существует несколько реализаций на Java, из которых вы можете выбирать. В этом и кроется проблема. Предположим, вы хотите использовать библиотеку для быстрого преобразования Фурье (БПФ), основанную на реализации массивов "A", вместе с библиотекой линейной алгебры, основанной на реализации массивов "B". Не повезло — массивы из "A" и "B" имеют разные типы, так что вы не можете использовать выходные данные БПФ как вход для системы решения линейных уравнений. Не имеет значения, что в основе лежат одни и те же абстракции, и даже что реализации имеют много общего. Для компилятора Java типы не совпадают, и точка.


Python не полностью свободен от этой проблемы. Вполне можно писать код на Python или код в модуле на Си, который ожидает точный тип данных в качестве входа, а иначе выбрасывает исключение. Но для кода на Python это будет считаться плохим стилем, и в модулях на Си для Python тоже, за исключением тех, где требуется производительность или совместимость с другим кодом на Си. Там, где это возможно, от программистов на Python ожидается использование стандартных интерфейсов для работы с данными. Например, итерация и индексирование работают одинаково для массивов и встроенных списков. Для операций, не поддерживаемых стандартными интерфейсами, от программистов на Python ожидается использование методов Python, также подлежащих утиной типизации. На практике, независимо реализованные типы Python намного более интероперабельны, чем независимо реализованные типы Java. В конкретном случае n-мерных массивов, у Python был шанс принятия подавляющим большинством единой реализации, что связано с вопросами скорее социальными и историческими, чем техническими.


Наконец, даже несмотря на то, что Python — довольно хороший выбор для системной интеграции в научных вычислениях, разумеется есть ограничения, как раз того рода, что описывает Стивен Келл в своём эссе: сочетание кода Python с кодом на других языках с управляемой памятью, скажем, R или Julia, требует много труда, и даже после этого остаётся хрупким, потому что требуются ухищрения, основанные на недокументированных деталях реализации. Подозреваю, что единственным решением может быть появление нейтральных по отношению к языкам объектов данных, поддерживающих сборку мусора и предоставляемых как сервис уровня операционной системы, сохраняющий возможность неуправляемого (unmanaged) доступа на уровне байтов, а-ля Си. Самая близкая из существующих технологий, о которой мне известно — CLR от Microsoft, более известная под коммерческим названием .NET. Её реализация теперь имеет открытый исходный код и работает на множестве платформ, но её происхождение "только для Windows" и прочные связи с огромной майкрософтовской библиотекой являются препятствием для принятия в традиционно Unix-центричном сообществе людей, занимающихся научными вычислениями.

Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 54
  • +5
    Что-то я так ничего и не понял. Чем же он так хорош? Единственный пример с массивами так и не доведен до логической развязки. В общем — видимо, минусы не зря поставили.
    • +1
      как в том анектоде.
      и не питон а библиотеки Numpy и Scypy и.т.п
      и не хороши, а плохи по производительности по сравнению с тем же
      Tensorflow для CPU не говоря уже о паралельном железе.
      • +19
        Python «хорош» в научных вычислениях из-за низкого порога вхождения.
        Для большинства людей, занимающихся наукой (даже теорией), необходим инструмент для каких-никаких расчетов, да чтоб еще графики рисовал. В моей области когда-то давно был такой монстр как IDL, но сейчас все поголовно пишут на Python.
        При этом зачастую не используются никакие фичи языка кроме стандартных циклов/ветвлений, функций и многомерных (в лучшем случае) массивов. Всё.
        Т.к. никто не хочет тратить время на «это ваше программирование», ни об ООП, ни об оптимизации, ни о чем либо еще люди даже не слышали. К исследованиям Python не побуждает, т.к. почти всё нужное среднестатистическому учёному можно найти в той или иной библиотеке.
        Провал между средним «научным» программированием и средним «профильным» программированием настолько велик, что, измеряя его в годах задержки, эквивалентен лагу в хороших лет 30. Такие дела.

        Всё вышенаписанное — личное мнение, основанное на личном опыте.
        • +2
          К исследованиям Python не побуждает, т.к. почти всё нужное среднестатистическому учёному можно найти в той или иной библиотеке.


          Об этом и речь. Если бы человек хотел заниматься программированием — стал бы программистом, разве нет? А если инструмент прост в освоении и подходит для решения научных задач — в чём польза от времени, потраченного на изучение «профильного» программирования?

          Ничего не имею против «программирования ради программирования», но у всего есть свои границы применимости.

          Интересно было почитать про IDL, спасибо! А что у вас за область, если не секрет?
          • +1
            IDL никогда не пользовался (я несколько младше, не застал), но «старшие» (от 35 где-то) всё еще его используют. Я вычисления/графики делаю на R (и я один такой на отделении).
            Специальность — астрофизика.
            • +1
              + в карму R (его редко цитируют где-либо в рунете). Я тоже на R фигачу. Но сам этот факт не отделяет этот язык от Python в срезе
              К исследованиям Python не побуждает, т.к. почти всё нужное среднестатистическому учёному можно найти в той или иной библиотеке.
              Хотя, в чем-то и отделяет, например, через возможность связать функции библиотеки с рядом публикаций, указанных в help.
              • +1
                А что вы имеете в виду под возможностью связать публикации? Действительно интересно. Это не то же самое, что например в питоне — вот хелп первой попавшейся функции из scipy, там для всего разумного даны ссылки. И такое видел во многих библиотеках, несколько раз действительно смотрел указанные статьи когда нужно было.
                • +1
                  Я имею в виду, что открывая help в любой функции из R stats:: или из другой библиотеки можно уточнить смысл некоторых — говоря языком разработчика — скалярных значений, возвращаемых этими функциями при определенных условиях, либо же в целом понять подход, который закодирован в этих функциях, почитав публикации в реферируемых журналах. Пример для семейства функций gamma:
                  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

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

                    "Редко цитируют" не довод для ученого!


                    Я на Matlab работал с 1989 года с версии 2.0 до примерно 2005.
                    В течение 12 лет я не встречал ни одного человека, который бы тоже работал в Matlab, за исключением своего универовского друга, который меня и "подсадил", коллег, с которыми я сам поделился сей радостью, и своих студентов.


                    И с появлением ру интернета очень долго — годы! — никто про матлаб даже не упоминал. Так что ссылки в инете не есть "наше все".

                    • 0
                      В этой цитате никаких доводов и не было!

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

                        Удачи! :)

                        • 0
                          Ок, и Вам. Я вообще не ученый, просто довольно много статистики в моей DS-работе (на production, в том числе).
                          • 0
                            Пишем большой проект одновременно на R и Python. Обкладываем проверками, используем быстрые библиотеки для прожевывания датафреймов. Мой коллега на Py пишет в стиле OOP, я, как не программист, пишу функционально. Объемы кода до 10К строк. Все крутится на production в docker container. Переходим на Spark. И R и Python идут нос в нос, но на R быстрее разработка идет. Также были сложности с переносом в Py логики расчета доверительных интервалов для моделей (то, что в R вызывается в функции, в Py решается матричными операциями, что опять же накладывает ограничение на скорость разработки).
                            • +1
                              Также были сложности с переносом в Py логики расчета доверительных интервалов для моделей (то, что в R вызывается в функции, в Py решается матричными операциями, что опять же накладывает ограничение на скорость разработки).

                              Не только скорость разработки, еще и делегирование ответственности влияет на выбор тулсов.


                              По степени доверия в вопросах статистики опенсорсный R, пожалуй, уже приближается к SAS.
                              Да, без проблем найти формулы для доверительных интервалов (и прочей статистической лабуды). И джуниор запрограммирует хоть на питоне, хоть на сях, хоть на фортране.
                              Вот, только, в серьезный продакшен лучше запускать статистику на надежных библиотеках, а не самописанную. Я так думаю.

                • +3

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

                  • +1
                    В инженерных и около-инженерных отраслях часто точно такая же ситуация.
                  • +2
                    Т.к. никто не хочет тратить время на «это ваше программирование», ни об ООП, ни об оптимизации [...]
                    Провал между средним «научным» программированием и средним «профильным» программированием настолько велик, что, измеряя его в годах задержки, эквивалентен лагу в хороших лет 30. Такие дела.
                    А зачем? ООП ради ООП, программирование ради программирования? Вы путаете программирование для автоматизации и программирование для вычислений.

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

                    Когда мне нужно проверить теорию, к примеру, time series forecasting с помощью Х, я беру python, открываю jupyter notebook, пишу модель, тестирую ее, визуализирую результаты, подвожу итоги. Если результат удачный, я перепишу получившийся алгоритм для продакшена, а этот код выкину. Если нет — я этот код опять-таки выкину. Какой смысл наводить красоту в, по сути, одноразовом коде?
                    • 0
                      Если результат удачный, я перепишу получившийся алгоритм для продакшена, а этот код выкину.
                      Подскажите, а это на сколько трудозатратно. Я вот тоже смотрю в сторону ML, эксперементирую с Anaconda, skikit-learn. Хотел бы ввести некоторые модели и наработки в прод. Сам я также занимаюсь бэкэндом под .NET, архитектурой, БД и автоматизацией в общем. И вот задумался, как бы лучше ввести в продакшн некоторые алгоритмы из библиотеки skikit-learn…
                      • 0
                        Для моих целей лучший результат дают простые линейные модели, которые можно на любом языке без проблем «в лоб» написать, без библиотек. Чем больше фич учитывает модель, чем она сложнее — тем хуже в итоге результат на out of sample.

                        Если же использовать что-то сложное, то лучшее, до чего я смог дойти — запихнуть модель в микросервис на питоне, залить в облако для маштабирования, и обращаться к нему по рест-апи с бекендов на других языках.
                      • +2
                        Возможно мы немного о разном говорим, но в моем случае код пишется один раз «как есть», не важно, как хорошо он работает, считает ли он сутки то, что при небольшой оптимизации считается за час. Никакого «перепишу потом». И хорошо, если один раз написал, опубликовал и забыл. А если через пол года этот код отдается в руки студенту для проекта «а давайте учтем еще один фактор в модели»? Когда ни писавший этот код ни тем более другой не-программист не могут понять, что же в нем происходит? Например из-за повального отсутствия комментариев и выражений вида
                        cc1 =  aa1 + bb1; 
                        c2 = cc1 * dg3

                        Если вы когда-нибудь работали с legacy-кодом, то представьте что здесь «legacy»-код зачастую пишется в реальном времени.
                        Понятное дело что ни у кого нет времени писать качественный код, когда нужно делать науку. Хотя вот сейчас пошла мода на требование исходников при публикации определенных типов работ. Может это поправит ситуацию.
                      • –1
                        На самом деле оптимизации не помешали бы. Я бы не отказался от такого языка, компилятор которого анализирует поток вычислений и делает из него машинный код, аналогичный оптимизированому на с. Помню, сидел я как то 3 дня, за которые компьютер воспроизвёл всего 13 лет жизни системы. А нас интересовала тясяча. Код тогда никто не переписывал, просто закинули на суперкомп. Получить доступ к суперкомпьютеру оказалось проще, чем уговорить кого-то переписать код на с++, потому что на фоне пайтона это объективно — ад. Хотя скорость выполнения искушает…
                      • 0
                        В моей области (астрофизика) царит огромный зоопарк языков программирования, библиотек и инструментов. IDL — только одна маленькая клеточка, причиняющая боль всей голове кучей необходимого легаси кода и проприетарных зависимостей. Многие направления десятилетиями развивались независимо, результат — практически у каждой специализированной софтины (пакета) есть свой уникальный интерфейс командной строки, свой скриптовый язык, свой формат конфигов. И конечено же, цимес в том, что сейчас, в эпоху великого объединения, требуется работать сразу с добрым десятком таких пакетов (астрономия стала воистину всеволновой!). К счастью, многие значимые для меня проекты стали использовать Python в качестве своего рода командной оболочки. Это радикально упрощает жизнь. Пиши вычислительный код на чём пожелаешь (хоть на Brainfuck), строй графики в экселе, но интерфейсик делай на Python)). Python в науке для учёного — скорее как bash или powershell в *nix/win для юзера/админа. Не стоит удивляться, что возможности языка часто используется слабо. Может это и к лучшему.
                      • +2
                        С задачей системной интеграции прекрасно справляются множество языков. TCL первым озаботился этой проблемой и вполне успешно ее решал. Lisp замечательно может справиться с интергацией. С помощью различных RPC-подобных протоколов, от CORBA до GraphQL, интеграцию можно осуществлять практически на любом языке. То же можно делать на системах обмена сообщениями.
                        • +1
                          --интеграцию можно осуществлять
                          --То же можно делать

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

                          Для этого есть специально обученые аспиранты.
                          • +1
                            А на питоне видели?
                            Все биндинги написаны теми же аспирантами или самими разработчиками библиотек. И даже не потому-что к питону биндинги писать проще, а потому-что он уже популярен и при наличии биндингов к питону библиотекой скорее станут пользоваться. Все преимущество в положительной обратной связи популярностей у разработчиков библиотек и конечных пользователей. В системах с такой связью велико влияние случайности и совсем не обязательно побеждает лучший.
                        • 0

                          Почему ruby не стал таким популярным?

                          • 0
                            Заметку как раз на эту тему я изначально и увидел: jeffknupp.com/blog/2017/09/15/python-is-the-fastest-growing-programming-language-due-to-a-feature-youve-never-heard-of

                            Вкратце: буферный протокол, позволяющий эффективно работать с данными.
                            • +1
                              Потому что основная документация к нему очень долго была на японском и медленно переводилась на английский.
                              • 0
                                Сейчас уже интересно, почему не взлетает Julia…
                                • 0

                                  Потому что есть питон и R и этого достаточно? Кстати, как у Julia с параллельностью?

                                  • 0

                                    На параллельность они и давят, вроде бы.

                                    • 0
                                      Очень хорошо. Вообще мы сравнивали решение нескольких задач на нескольких языках. Julia выдавала результаты сравнимые с C/C++ с OpenMP и примерно в 16-24 раз быстрее чем Матлаб (Пухтон и R кстати медленнее Маталаба), которому даже Parallel Toolbox Не помог, хотя если использовать GPU, то Matlab тоже хорошие результаты показывает (если закрыть глаза на неоптимальное использование видеопамяти), как C/C++ и Julia на CPU :-)
                                    • 0
                                      До сих пор нет еще релизной версии языка, дебаггер пока еще неудобный (чего я лично жду, еще я жду нормальной сборки библиотек без танцев с бубном), нету такого клочиества тулбоксов (мне то пофиг, но вот много народу уже слишком разбалованны всякими fir1), как у того же Матлаба. В общем язык еще сырой. Но вообще он (она?) оказался хорошей альтернативой Фортрану и Си.
                                      Ну и инерция еще, хотя народ (буржуи) на него постепенно переходит.
                                  • 0
                                    В качестве конкретного примера возьмите многомерные массивы Java. Они не являются частью языка или стандартной библиотеки, но могут быть реализованы поверх них с разумными усилиями. Фактически существует несколько реализаций на Java, из которых вы можете выбирать.

                                    Мне не очень понятен этот фрагмент. В java есть многомерные массивы, они являются частью языка и есть только одна «реализация». Вот пример:
                                    byte[][][] test = new byte[100][100][100];
                                    • +1
                                      Да, не очень ясный момент. Подозреваю, что автор имел в виду отсутствие многомерности «как в NumPy». В Java, насколько я понимаю, приведённый вами код это всё таки «массив массивов массивов», то есть массив указателей на массивы указателей на массивы элементов. В Python ndarray — это гораздо более гибкая штука, по сути — кусок памяти, который можно разбить на элементы произвольным образом.
                                      • 0
                                        Да, получится «массив массивов массивов».
                                      • +1
                                        Это будет не массив массивов? То есть с дополнительным уровнем коственности на каждый индекс?
                                        • 0
                                          Это не многомерный массив в numpy'евском понимании, это массив указателей на массивы указателей на массивы.
                                          Под многомерным массивом тут понимается непрерывный кусок памяти у которого «многомерность» появляется только на этапе индексации. Это дает всякие плюшки типа быстрых решейпов, быстрой индексации, лучшего обращения к кешу и так далее.
                                          Нативно в java такого нет, есть в C#:
                                          byte[ , , ] arr = new byte[2, 3, 8]
                                          • 0
                                            Операции умножения, скалярного произведения, тензорного произведения, обращения матрицы и т.п. там из под коробки есть? А собственные числа, число обусловленности, всякие разложения матрица (SVD, верхнетреугольные и т.д.) там есть?
                                            Комплексные и гиперкомплексные числа?

                                            А как с памятью дело обстоит? Это будет отдельный кусок в памяти или указатели, на указатели на разбросанные по всей памяти ячейки?
                                          • +5

                                            Многие положения статьи показывают, что автор не имел счастья поработать с приличным коммерческим научным софтом, который существовал во все времена, но был не для всех.
                                            Все, что в статье ставится в заслугу Питону, придумано и воплощено давно и другими авторами, как говаривал мой шеф.
                                            Кроме тех преимуществ, которые дал Питону опенсорс, ничего выдающегося в нем для науки ИМХО нет. R люблю больше.
                                            Питон использую вынужденно, если нужен доступ к библиотекам,, с которыми R не подружили.Например OpenCV

                                            • +1
                                              Сейчас питон просто «достаточно хорош» по сути во всех областях, пусть и не является везде лучшим. Зато можно знать по сути один язык, и иметь готовые функции для огромного количества математических операций (numpy, scipy, другие более мелкие библиотеки), писать достаточно тяжёлые численные вычисления (numba), заниматься статистикой включая продвинутую байесовскую (pymc), писать маленькие и большие скрипты, делать сайты (flask, django, ...), рисовать графики и иллюстрации (matplotlib), и многое другое. И пусть в одной области несколько лучше чем python будут C/Fortran, в другой R, в третьей например nodejs — но библиотек на любой случай жизни уже столько, что другие языки нужны в очень-очень узких случаях.

                                              Всё вышеописанное конечно не относится к программистам, у которых программа это основной выходной результат — скорее к учёным или людям, программирование для которых является именно инструментом. Сейчас вижу, как у нас всё больше и больше людей разных возрастов (как минимум до 40-50) переходят на питон со всяких fortran, idl, perl и т.п.

                                              Но почему библиотеки «для всего» появились именно в питоне, а не в каком-нибудь R, я что-то так и не понял.
                                              • +1
                                                Но почему библиотеки «для всего» появились именно в питоне, а не в каком-нибудь R, я что-то так и не понял.

                                                Положительная обратная связь. Много пользователей — имеет смысл разработчикам делать биндинги своих библиотек, доступно много библиотек — у пользователей появляется стимул перейти в эту экосистему.
                                                • +1
                                                  Но почему библиотеки «для всего» появились именно в питоне, а не в каком-нибудь R, я что-то так и не понял.

                                                  Что и где появилось впервые — вопрос спорный.
                                                  Вот здесь главный (но не единственный) репозиторий библиотек R.

                                                  В принципе, это нарастающий холивар -- R vs Python in Data Science
                                                  Посмотрите, может найдете что-нить для себя.

                                                  Мой взгляд на этот вопрос — выбор во многом зависит кто и откуда приходит в то, что сейчас называют Data Science.

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

                                                  В Python-Sci приходят из программирования, когда открывают для себя науку.
                                                  Но эти часто бросаются в Python вместо (бездарного по их мнению) сидения в библиотеке и изучения наследия гигантов. Вот они погуглили, все поняли, а потом все, что они поняли, расскажут коротко и ясно в 3-х минутном ролике на Ютубе.

                                                  Утрирую, конечно…

                                                  За что и почему я люблю R я писал.


                                                  • 0
                                                    В data science — может и нарастающий холивар, не буду спорить (хотя все знакомые в этой отрасли преимущественно используют питон, да и курсы в основном на нём). И я знаю, что в R есть больше статистических библиотек — но ведь data science и статистика это только один из огромного массива применений для языка программирования. В R, насколько я знаю, далеко не так удобно писать например сайты, скрипты автоматизации; ООП так себе в нём реализовано; биндинги для всяких нишевых библиотек реже есть готовые. Ну и лично мне сам язык не понравился, хотя начал немного писать на нём примерно одновременно с питоном :)
                                                    А, ещё очень удобная среда сначала появилась именно для питона — ipython notebook, это уже потом куда подключили всё что можно. И сейчас намного проще писать на питоне, изредка для очень узкоспециализированных вещей используя например R, чем наоборот.
                                                    • 0
                                                      Вообще-то notebook сначала появился для Wolfram Mathematica.
                                                      • 0
                                                        Ну вольфрам это всё-таки не general purpose язык, его напрямую странно сравнивать с питоном. Я имею в виду из нормальных языков — а из них питон первый получил notebook.
                                                        • 0
                                                          А, ещё очень удобная среда сначала появилась именно для питона — ipython notebook

                                                          Идею нотбука на PC я впервые осязал в Mathcad V2.6.
                                                          Я с ним немного работал параллельно с Матлабом, но потом Матлаб победил.


                                                          спойлер

                                                          А вообще я опасаюсь исторические изыскания молодых и ищущих как вот тут с Питоном. Что компьютер изобрел Бил Гейтся и Стив Джобс — это я уже слышал.


                                                          В общем, не против Питона я.


                                                          Не сотвори себе кумира — я вот о чем.

                                                          • 0
                                                            Прочитайте комментарий прямо над вашим — он абсолютно так же применим к Mathcad, как и к wolfram mathematica. Оба этих продукта странно напрямую сравнивать с нормальными языками (типа C/Python/...).
                                                            • 0
                                                              исторические изыскания молодых и ищущих

                                                              Не знаю насчёт комментаторов, но автора статьи едва ли можно назвать молодым. Он вообще являлся одним из разработчиков Numerical Python, так что, надо полагать, знает о чём говорит.

                                                              Сопутствующие bias — отдельная тема, но как попытка описать возможные причины объективно наблюдаемой популярности Python — почему бы и нет?
                                                    • +1
                                                      Научные вычисления научным вычислениям рознь. Если говорить про анализ данных, то
                                                      есть большая четвёрка универсальных программ, есть куча мелких полезных специализированных программ, есть недо-программы. Python (в части набора библиотек по анализу данных) видимо входит в третью группу.
                                                      Как универсальная платформа, библиотеки python не дотягивают ни до R, ни до SAS, ни до Matlab. Если человек не работал в статистических программах, то он вряд ли поймёт минусы python, у него нет какого-то сценария, что должен делать уважающий себя статпакет с пол пинка.
                                                      По скорости обработки данных тоже есть вопрос. Если pandas относительно молодой, перспективный, то почему он медленнее того же data.table в R?
                                                      • 0

                                                        Как говорил мой преподаватель, Python — это клей между большим количеством разнообразных готовых библиотек.

                                                        • 0
                                                          Сравнивать реальную сигрантуру методов, а не объявленые типы — иногда хорошо, но динамическая типизация по мне всё равно — это плохо. По мне гораздо лучшее решение в Swift — если какой-то класс не реализует нужный протокол, а просто совпадает сигнатура, то в расширении можно объявить, что он его реализует. Причём протоколы в Swift могут содержать конструкторы, и существует понятие оябзательного конструктора. А ещё любую структуру можно объявить константой: если вызов функции меняет данные, то это можно объявить, и компилятор не позволит вызвать эту функцию для константы. И кроме того, если какой-то параметр должен содержать значение, в т. ч. ссылочный тип, то в Swift это тоже можно объявить, и компилятор не позволит передать туда пустой указатель. А если нужно объединить протоколы, можно даже не использовать наследование — хватит typealias.

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                          Самое читаемое