Доступен релиз Python-библиотеки для научных вычислений NumPy 1.19, ориентированной на работу с многомерными массивами и матрицами, а также предоставляющей большую коллекцию функций с реализацией различных алгоритмов, связанных с использованием матриц. NumPy является одной из наиболее востребованных библиотек, применяемых для научных расчётов. Код проекта написан на языке Python с применением оптимизаций на языке Си и распространяется под лицензией BSD...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53203
Нужно.
/* сарказьм
Не нужно. Наука не нужна. Нужно пилить и осваивать - только так делаются состояния, а ваша наука - пережиток вымершей цивилизации.
сарказьм окончен */
Бородатая шутка из 90-х: "Раз ты такой умный, почему же ты бедный".Из типичного разговора двух мужиков, при котором один говорит другому, о том, что он учится в вузе, а другой ему дежурно отвечает: "Учишся? Молодец."
>Не нужно. Наука не нужна. Нужно пилить и осваивать - только так делаются состояния, а ваша наука - пережиток вымершей цивилизации.
Это не сарказм - это мысли чиновника и барыги (поддельника-распильщика).
>Бородатая шутка из 90-х: "Раз ты такой умный, почему же ты бедный".Богат тот, которому ничего не нужно.
Так то на оборот код написан на языке Си с приминением Python для писсимизации.
На какой оборот?
Наоборот это библиотека для Си на Питоне. Человек матан переботал.
Если ты такой умный, че про примИнение не спросил?, а так просто опозорился.
Интересно какие конкретно фичи из 3.5 помешали? Вроде же их только добавляли в последних версиях
>Вроде же их только добавляли в последних версияхТогда не помешали, а их не доставало.
Это скорее C-библиотека с обёрткой в виде Python.
Ага а python это чекер отступов к набору макросов на C.
Если бы не обёртка, им от силы бы пользовались полтора учёного.
А чем питон нереально проще практически всех нынешних языков и их подобий вплоть до Си и JS ?
Чего в нем такого нереально божественного и богоподобного, что исключительно из-за этой «обёртки» ей пользуются ?
Его многие годы рекламировали и пиарили, в некоторых странах запада - и вовсе, нередко использовали просто как первый/учебный ЯП( вместо паскаля и какого-нибудь qbasic’a ), потому по западным меркам было поверие, что его народ должен знать лучше всего и именно с его интеграции и надо начинать поддержку «скриптоты» в конкретном ПО.
В данном конкретном случае numpy питон в основном применяется в виде интерактивной оболочки, а не в виде исполняемого файла, как у C.
Не особо фанат Python. Но его создатель математик, и среди девизов нас колько помню "больше правил меньше исключению".Вот к примеру нужно сложить два целых числа почти везде c = a + b. Это правило
Где-то нужно предварительно объявить переменную для результата - ок, тоже считаем правило. (Хотя ученый скажет, зачем если оно и так понтяно)
Нужно выбрать тип переменной - хм... ну ладно, и разрядность - понял, понял и разрядность.
А еще заранее подумать не выйдет ли оно за пределы границ... Хм... И знаковое или беззнаковое...
Получается сложное правило с кучей исключений, и кроме того если значение больше чего-то там в степенях двойки, то уже увы никак.
Нужно это всё ученному? Которому, еще надо помнить зачем он эти числа складывает.
> Не особо фанат Python. Но его создатель математик, и среди девизов нас
> колько помню "больше правил меньше исключению".Математики - это вроде бы те, кто занимаются математикой, а не программированием, ещё и столь специфическим( разработка ЯП итд)
Более того, как «математик» он, вероятно, был в курсе о существовании того же фортрана..>[оверквотинг удален]
> Где-то нужно предварительно объявить переменную для результата - ок, тоже считаем
> правило. (Хотя ученый скажет, зачем если оно и так понтяно)
> Нужно выбрать тип переменной - хм... ну ладно, и разрядность - понял,
> понял и разрядность.
> А еще заранее подумать не выйдет ли оно за пределы границ... Хм...
> И знаковое или беззнаковое...
> Получается сложное правило с кучей исключений, и кроме того если значение больше
> чего-то там в степенях двойки, то уже увы никак.
> Нужно это всё ученному? Которому, еще надо помнить зачем он эти числа
> складывает.Самое забавное, что примерно за это( просто работает без бесконечно цирка с исключениями/типизациями/итп и гор типизированных портянок/простыней, которые делают столь простые действия, для которых нынче и одной строки кода - уже много) хейтят штуки вроде JS.
жс это нелепый костыль без человеческих типов, который случайно заполз в браузеры и из-за обратной совсемстимости не хочет вылезать обратно. си на много-много порядков более низкоуровневый и без такого обильного количества сахара. у питона есть несколько киллер-фич на мой взгляд. 1. огромное сообщество с библиотеками для всего. 2 интуитивность. даже если чего-то не знаешь, то можешь прикинуть как это может быть - и оно скорее всего так и будет. ну и он весьма стройный потому как продумывался чтобы легко читался и расширялся. хотя последние версии радуют все меньше
>последние версии радуют все меньшеНаоборот, всё больше, теперь можно писать всё проще и понятней, да и гораздо лаконичней, а := так вообще годнота. Мои регулярки ещё никогда не выглядели так хорошо в питоне. Те же хинты тоже позволили выкинуть много костыльных костылей, которые были пришлёпнуты сбоку. У меня большие надежды на избавление от гила, субинтерпретаторы это конечно хорошо (если они будут работать, как задумывалось), но проблема остаётся. Пока код однопоточный, гил не является проблемой. Но в многопоточном коде можно полагаться только на код без гила, а это уже не совсем питон. Плоховато скалируется. Кроме того, есть ещё вот это https://instagram-engineering.com/dismissing-python-garbage-... (вроде та ссылка)
Тайп-хинты, f-строки безусловно хороши, но вот новое присваивание как мне кажется противоестественно остальному языку. не зря много копий об него сломалось, в том числе и гвидовское
> Тайп-хинты, f-строки безусловно хороши, но вот новое присваивание как мне кажется противоестественно
> остальному языку. не зря много копий об него сломалось, в том
> числе и гвидовскоеЯ немного расстроился, что := нельзя использовать в f"". Пришлось запихнуть в .format(), но довольно неплохо получилось в принципе. Никогда ещё однострочники не были такими эффективными.
> А чем питон нереально проще практически всех нынешних языков и их подобий вплоть до Си и JS ?Да хоть управление памятью (которое надо ручками в Cи, ага).
> Его многие годы рекламировали и пиарили
Кто, опять жидомасоны?!
> нередко использовали просто как первый/учебный ЯП
Вполне логичный выбор, проще сложно найти.
>> А чем питон нереально проще практически всех нынешних языков и их подобий вплоть до Си и JS ?
> Да хоть управление памятью (которое надо ручками в Cи, ага).В JS и иных скриптовых управление памятью исключительно ручное ?) Ну не зря же это было упомянуто как единственный аргумент для перечня из JS и Си.
Хотя даже в том же Си на момент обучения ему не могу сказать что это было чем-то даже относительно сложным - скорее интересным, насколько малоимущую прогу можно сделать.> Кто, опять жидомасоны?!
Мне он даже в книгах по 3DS Max попадался.
Притом, подача была такова, что это чуть ли не божественное поделие( хотя, кого мы обманываем ?:) Почти аналогичное говорили и про перл и про руби и про луа и почти про что угодно другое )> Вполне логичный выбор, проще сложно найти.
JS / Си / Go / Ruby / Почти что угодно другое, особенно на фоне бесконечного цирка с версиями у питона ?
Если бы не С, матрица сотого порядка обращалась бы сутки, а не 0,0001 с.
> Если бы не С, матрица сотого порядка обращалась бы сутки, а не 0,0001 с.У опеннетных фантазеров - несомненно 🙄
https://github.com/numpy/numpy/blob/8e6796e93b9f7d132a95e4bf...
> n = (fortran_int)dimensions[0];
> if (init_@lapack_func@(¶ms, n, n)) {https://github.com/Reference-LAPACK/lapack/blob/master/SRC/d...
> DGETRI computes the inverse of a matrix using the LU factorization
>*> computed by DGETRF.https://github.com/Reference-LAPACK/lapack
> Fortran 78.1% C 20.4%
К чему это ты написал? Доказал, что фортран быстр? Ну быстр. Но в ветке темы обсуждается Python и C.
> К чему это ты написал? Доказал, что фортран быстр? Ну быстр.К тому, что для обращаения матрицы в сабже используется код на фортране. И проценты - это (грубое) соотношение кода в библиотеке lapack.
> Но в ветке темы обсуждается Python и C.
В ветке темы, в очередной раз, фантаз^W "обсуждается"
>>> Это скорее C-библиотека с обёрткой в виде Python.и
>>> Если бы не С, матрица сотого порядка обращалась бы сутки, а не 0,0001 с..
По секрету, весь питон это си.
А что случилось с Фортраном? Зачем учёные возятся с Питоном? Был же у них спец.язык, специально под их нужды.
На фортране написан lapack, что в ядре numpy, но на нём не напишешь ничего, кроме математики, ибо нет биндингов к графике, диаграмам, субд и др. И вообще numpy в основном для быстрой апробации идей, а не для готового ПО.
>На фортране написан lapack, что в ядре numpyНу вот, хоть тут честно, а то на C, на C...
Ошибкой является сравнение Фортрана с Пайтоном. Различные назначения совершенно. Фортран с С сравнить можно, но тот же алгоритм, выполненный на С, работает быстрее фортрановской реализации, хотя и непринципиально.
В теории С/С++ быстрее Fortran в некоторых случаях. Но на практике в поле применения Fortran (научные расчеты) он не хуже С/С++, а в некоторых случаях даже лучше. При этом намного проще и безопаснее С/С++.
>А что случилось с Фортраном?Фортран жив, и уйдёт вместе с пожилыми. Сейчас на Западе все научные вычисления обрабатываются с помощью Питона.
Поколения меняются.
Очень смелое заявление. Тогда поясните: - расчеты симуляции ядерного взрыва, погодных изменений, и т.д. тоже на Python c GIL делают или все таки на кластерах компьютеров с Coarray Fortran?
> тоже на Python c GILа причем тут GIL? очевидно, вы не понимаете, что это и зачем было сделано
Может ОпенНет читают пользователи из Сарова и подскажут, что за ЯП используется у них на кластере? ;)
На ЛОРе тусуется персонаж из института исследования океанов. Они обсчитывают свои модели на Fortran
>пакеты программ 3D имитационного моделирования на супер-ЭВМ, такие как, ЛОГОС, ДАНКО+ГЕПАРД, НИМФА, TDMCC, включающие в себя модели и методы для имитационного моделирования на супер-ЭВМЭто глубокий, глубочайший совок. Увидев Питон страички из НИИ Сарова будут в шоке.
>Зачем учёные возятся с Питоном?питон приятнее
>А что случилось с Фортраном?случилась эволюция
Python - для быстрых зарисовок. Fortran - для картин, типа Монализа. И таки да, ви есть оказались правы, сейчас уже не Fortran IV, а Fortran 2018 - тоже приятный для своей области язычок. Если кто Fortran-у и конкурент в этой области, так не Python, а Julia (если взлетит)
> Fortran 2018 - тоже приятный для своей области язычокНу да. Если писать не руками, а с помощью питона.
> не Python, а Julia (если взлетит)
Лет десять уже взлетает. По мойму - эт страус.
> не Python, а Julia (если взлетит)
>Лет десять уже взлетает. По мойму - эт страус.питон - 1991, питон 1.0 - 1994
1994+10 = 2004джулия - 2012, джулиа 1.0 - 2019
Ой, ви делаете мне смешно. Таки выпуск версии 1.0 что-то значит для современных разработчиков, они теперь точно заплатят ипотеку?!)
>Ой, ви делаете мне смешно. Таки выпуск версии 1.0 что-то значит для современных разработчиков, они теперь точно заплатят ипотеку?!)Нет, это вы делаете из себя смешно.
А для тех кто понимает там впервые гарантировано заморожен АПИThe single most significant new feature in Julia 1.0, of course, is a commitment to language API stability: code you write for Julia 1.0 will continue to work in Julia 1.1, 1.2, etc. The language is “fully baked.”
If you’re upgrading code from Julia 0.6 or earlier, we encourage you to first use the transitional 0.7 release, which includes deprecation warnings to help guide you through the upgrade process. Once your code is warning-free, you can change to 1.0 without any functional changes. The registered packages are in the midst of taking advantage of this stepping stone and releasing 1.0-compatible updates.
С Фортраном все хорошо. У него немного другое использование.Python + условный "стек NumPy" (NumPy/SciPy/Pandas/Matplotlib/Sklearn/...) используют там, где нужно обрабатывать данные с помощью алгоритмов, которые сами по себе нетривиальны, но не требуют безумных ресурсов. Например: снятые с прибора данные обрезать, преобразовать, пройтись шумодавом, вычислить коэффициенты линейной регрессии и отрисовать в виде картинки. Причины: (1) писать удобнее, чем на Фортране (2) стек модулей уж очень удачный получился, все необходимое на разные случаи собрано в одном месте.
А в Фортран приходится лезть тогда, когда критична именно высокая производительность, когда нужно выжимать максимум мощности, параллелить и т.д. Например, квантовохимический расчет.
Впрочем, есть проекты типа Psi4, который предоставляет Python API для квантовохимических модулей, написанных на крестах. Схема тут в целом примерно та же -- высоконагруженные вещи пишутся на Фортране/С/C++, плюс делают обертку на Python.
Нюанс еще в том, что для многих "классических" задач (типа преобразований матриц, задач оптимизации и т.д.) уже написаны и компилируемые реализации, и Python API -- и можно смело обойтись только последним. А для "новых" задач (та же квантовая химия, моделирование погоды, астрономические задачи, ядерная физика) -- т.е. там где продолжают развиваться какие-то алгоритмы -- там без Фортрана/С/C++ никак.
Пенсионерам уважуха, но смена поколений и эволюция должна сделать своё. В научных расчётах Python должен заменить Fortran.И язык "R" для статистики.
Ну да - они же похожи ... так же один залетевший Tab портит всю программу.
>В научных расчётах Python должен заменить Fortran.В научных расчётах matlab (и его родственники octave,scilab) будет заменен на
Питон тут временное недоразумение. Используется для дерганья библиотек на других языках (Opencv и т.п.), ну и попытка эмуляции возможностей матлаба через numpy, но не так удобно, например матлаб-джулиа
a = [1 2 3]
или нампай
a = numpy.array([1, 2, 3])
и так там все матлабовское эмулировано кривовато и неудобно
Вы занимаетесь научными расчетами?
>Вы занимаетесь научными расчетами?Понимаете, научные расчеты (точнее было бы сказать - расчеты в научной деятельности) они очень разные даже в одной области науки встречаются. Это примерно как спросить - программируете ли вы. Ответ на оба вопроса - да, но эти ответы практически не несут полезной информации.
Именно поэтому огульно заявлять "должен быть заменен", "временное недоразумение" и т.д. как минимум самоуверенно.
С опытом приходит понимание что такое хорошо, а что такое плохо (и понимание, что понимание приходит не ко всем).Но вы так за питон не переживайте, опыт других недоразумений (скажем си и жабоскрипта) обещает ему долгую жизнь. К тому же вы наверняка знаете много причин по которым он хорошо подходит для применения в науке (желательно хаотичное применение статистических методов к данным непонятной достоверности, часто называемое машинным обучением и нудное обучение сеток в тензор флоу не предлагать), в отличие от специально созданных для этого языков.
Кстати, для интересующихся, неплохой обзор джулиа с упомининиями
https://habr.com/ru/company/oleg-bunin/blog/476114/
> Кстати, для интересующихся, неплохой обзор джулиа с упомининиями
> https://habr.com/ru/company/oleg-bunin/blog/476114/Вот чем он "неплох"? Вранье - с первой буквы: "Классический Python относится к первой категории. Если убрать NumPy, считать что-то на чистом Python медленно." (ц) Для начала, "считать" можно хотеть что-то - точно.
>Вот чем он "неплох"? Вранье - с первой буквы: "Классический Python относится к первой категории. Если убрать NumPy, считать что-то на чистом Python медленно." (ц) Для начала, "считать" можно хотеть что-то - точно.Действительно вранье, даже с нампай часто медленно, ибо не все векторизуется (но автор там сам питонист и многого не видел). Про точность вообще смешно. К каждому языку библиотек для произвольной точности понаписано, но ни одного случая их применения неизвестно.
https://en.wikipedia.org/wiki/List_of_arbitrary-precision_ar...
https://github.com/benibela/bigdecimalmathт.е. это как раз и говорит о том что разработчики совершенно не понимали расчетных задач, но тут как раз критики нет, ведь и не для этого делал
> Про точность вообще
> смешно. К каждому языку библиотек для произвольной точности понаписано, но ни
> одного случая их применения неизвестно.Вы про системы компьютерной алгебры хоть слыхали?
(Да, arbitrary-precision != точные вычисления.)
> т.е. это как раз и говорит о том что разработчики совершенно не
> понимали расчетных задач, но тут как раз критики нет, ведь и
> не для этого делалЧьи разработчики, кого не понимали?..
> Вы про системы компьютерной алгебры хоть слыхали?Они практически не применяются в повседневной работе. Сам не знаю ни одного примера, было бы даже интересно, может у математиков чистых каких. А вот численные вычисления постоянно.
> Чьи разработчики, кого не понимали?..
Разработчики питона не интересовались научными вычислениями. Ну хоть википедию то прочтите про цели
https://ru.wikipedia.org/wiki/Python
Для распределённой ОС Amoeba требовался расширяемый скриптовый языкКогда начали пытаться считать (не знаю кому это вообще пришло в голову), сразу стало ясно что это невозможно и скопировали (не очень удачно, пользоваться существенно менее удобно, я пример приводил как простое становится сложнее) матлаб в виде нампая (питонисты слова матлаб не слышали поэтому этого не знают). Вы то сами сколько языков знаете, чтобы сравнивать?
Джулия же сразу оттолкнулась от матлаба и птается исправить его недостатки. К ней тоже вопросы конечно есть, но это разумная попытка.
>> Вы про системы компьютерной алгебры хоть слыхали?
> Они практически не применяются в повседневной работе. Сам не знаю ни одного
> примера, было бы даже интересно, может у математиков чистых каких.Вот кстати вспомнил, что когда-то видел символьные вычисления определителя в связи с дифурами у пользователей mathcad, типа такого
https://community.ptc.com/t5/PTC-Mathcad/Symbolically-find-a...
но порядки были невысокие т.е. эо чисто вопрос удобства, там и на бумажке можно, просто ленится народ
В матлабоподобных такое есть, но не видел чтоб пользовались, обычно не те задачи
https://octave.sourceforge.io/symbolic/overview.html
https://www.mathworks.com/help/symbolic/sym.det.htm
> там и на бумажке можно, просто ленится народНу посчитай мне на бумашке точки для гауссовой квадратуры порядка 9)
>> там и на бумажке можно, просто ленится народ
> Ну посчитай мне на бумашке точки для гауссовой квадратуры порядка 9)Может еще таблицу умножения посчитать? Это все 200-лет стандартное и давно в библиотеках. А определитель это a*b-c*d, ну точно без мэпла не посчитать, ага
>>> там и на бумажке можно, просто ленится народ
>> Ну посчитай мне на бумашке точки для гауссовой квадратуры порядка 9)
> Может еще таблицу умножения посчитать? Это все 200-лет стандартное и давно в библиотеках.Ну давай библиотеку. Или не ждать, герой? И у меня еще есть много задачек, ага)
> Ну давай библиотеку. Или не ждать, герой? И у меня
> еще есть много задачек, ага)https://juliamath.github.io/QuadGK.jl/latest/
Могу еще библиотеки для логарифма и синуса дать
>> Ну давай библиотеку. Или не ждать, герой? И у меня
>> еще есть много задачек, ага)
> https://juliamath.github.io/QuadGK.jl/latest/Задача была вполне конкретная. Где там на нее ответ, по вашему мнению?
>> Вы про системы компьютерной алгебры хоть слыхали?
> Они практически не применяются в повседневной работе.Да, касирши из "Пятерочки" - ими не пользуются, эт вы верно подметили.
> Сам не знаю ни одного
> примера, было бы даже интересно, может у математиков чистых каких. А
> вот численные вычисления постоянно.Сейчас без аналитических вычислений численные - не делают. (Под "численными" - я подразумеваю
то, что относится к нормальным численным методам, а не всякие нейронные сети и т.п. балаган.)>> Чьи разработчики, кого не понимали?..
> Разработчики питона не интересовались научными вычислениями.А, вы про то что это задумывалось не как узкоспециализированный язык?
> Когда начали пытаться считать (не знаю кому это вообще пришло в голову),
> сразу стало ясно что это невозможноВообще-то - довольно понятно почему пришло в голову. Матлаб - он не для
слабонервных, а некоторым все-таки хочется писать код быстро и по-возможности
не только write-only.Кстати, почему невозможно? С PyPy, к примеру, вполне возможно.
> и скопировали матлаб в виде нампая
Ну если любым образом прикрученный LAPACK считать матлабом...
> (питонисты слова матлаб не слышали поэтому этого не знают).
(Питонистов матлабу учили когда вы еще под стол пешком ходили.)
> Вы то сами сколько языков знаете, чтобы сравнивать?
Скорее всего, больше вас. Причем, подозреваю, где-то на порядок.
> Джулия же сразу оттолкнулась от матлаба и птается исправить его недостатки.
Не знаю. Макросы - это хорошо, конечно. Хотя и это в питон уже завезли, для
любителей. А вообще - не вижу какого-то реального смысла в узкоспециализированном
языке и буду сильно удивлен, если оно таки (после десятка лет?) - взлетит.
Проще питона для прототипирования ничего не завезли пока.
>>> Вы про системы компьютерной алгебры хоть слыхали?
>> Они практически не применяются в повседневной работе.
> Да, касирши из "Пятерочки" - ими не пользуются, эт вы верно подметили.
> Сейчас без аналитических вычислений численные - не делают. (Под "численными" - я подразумеваю то, что относится к нормальным численным методам, а не всякие нейронные сети и т.п. балаган.)Сейчас кому нало результат делают просто в ansys, не знают видимо про питон
>> Разработчики питона не интересовались научными вычислениями.
> А, вы про то что это задумывалось не как узкоспециализированный язык?Это задумывалось как тяп-ляп на коленке срочно (как и си и жабоскрипт) ну и чтобы уже имеющийся бэш, перл и т.п. не использовать т.к. Not invented here, потом потихоньку обросло костылями
> Вообще-то - довольно понятно почему пришло в голову. Матлаб - он не для слабонервных, а некоторым все-таки хочется писать код быстро и по-возможности не только write-only.
Анекдот какой-то. Матлаб это сложно, а скопированный с него нампай с добавленными синтаксическими неудобствами это просто. Логика настоящего ученого.
>> (питонисты слова матлаб не слышали поэтому этого не знают).
>(Питонистов матлабу учили когда вы еще под стол пешком ходили.)Ну да, именно поэтому для них нампай откровение от Гвидо на котором писать то оказывается проще, чем на матлабе с которого он криво содран.
> Ну если любым образом прикрученный LAPACK считать матлабом...
Я уже и так понял, что и си и матлаба вы не видели, потому м разница непонятна.
>> Джулия же сразу оттолкнулась от матлаба и пытается исправить его недостатки.
> Не знаю. Макросы - это хорошо, конечно. Хотя и этоМакросы тут не при чем. Это вообще зло.
Недостатков матлаба всего 2 - его хорошая реализация сильно платная, и у него проблемы с невекторизованными вычислениями (ну у платного уже в общем нет, а у бесплатных в полный рост). Вот их и надо исправить. Ну и приучить людей делать интерфейсы к их бмблиотекам не на питоне.
То что на нем сайтики не делают это для нвуки не недостаток.
> Проще питона для прототипирования ничего не завезли пока.Прототипирование это дерганье библиотеки к котрой 2 интерфейса написали - к питону и с++? Что тут причина использования питона, а что следствие не догадываетесь?
Или есть примеры численных расчетов без нампая? А это матлаб ( что как оказыватеся все питонисты уже и знают).
Вообще я питон к каким-то особо простым не отнесу, это заблуждение тех кто только его и знает, много там вообще не очень удобно сделано.
Проблема 2 языков и перехода от прототипа к результату вижу непонятна, хотя по моей ссылке человек ее объяснил. Ну это не объяснишь тому кто не сталкивается.
Это причем даже у машинлернеров проблема, про реальные расчеты и говорить бессмысленно.В реале это всегда типа так
GMES: A Python package for solving Maxwell’s equations using the FDTD method
Programming language: C++, Python.
Computer: Any computer with a Unix-like system with a C++ compiler, and a Python interpreter;Ну да Питон, понимаешь, ничего лучше нет да
> Сейчас кому нало результат делают просто в ansys, не знают видимо про питонНикогда не видел статей с использованием ansys. Боюсь, таких
нет в природе. Даже без учета того, что эта штука - закрытая.>>> Разработчики питона не интересовались научными вычислениями.
>> А, вы про то что это задумывалось не как узкоспециализированный язык?
> Это задумывалось как тяп-ляп на коленке срочно (как и си и жабоскрипт)Во всяком случае, получился не худший вин.
>> Вообще-то - довольно понятно почему пришло в голову. Матлаб - он не для слабонервных, а некоторым все-таки хочется писать код быстро и по-возможности не только write-only.
> Анекдот какой-то. Матлаб это сложно, а скопированный с него нампай с добавленными
> синтаксическими неудобствами это просто. Логика настоящего ученого.numpy не скопирован с матлаба. Это так можно договориться до того, что LAPACK с
матлаба скопирован.>>> Джулия же сразу оттолкнулась от матлаба и пытается исправить его недостатки.
>> Не знаю. Макросы - это хорошо, конечно. Хотя и это
> Макросы тут не при чем. Это вообще зло.Нет, конечно. Наверное, вас в ПТУ на каком-нибудь C++ учили - вот и детская травма.
> Недостатков матлаба всего 2 - его хорошая реализация сильно платная, и у
> него проблемы с невекторизованными вычислениями (ну у платного уже в общем
> нет, а у бесплатных в полный рост).Недостатков матлаба - то, что это далее узкоспециализированного языка
он не ушел. По сравнению с этим - все остальное просто меркнет.>> Проще питона для прототипирования ничего не завезли пока.
> Прототипирование это дерганье библиотекиНет, прототипирование - это когда дергать еще нечего.
> Или есть примеры численных расчетов без нампая?
Есть конечно, не все же вокруг - линейная алгебра.
> Вообще я питон к каким-то особо простым не отнесу, это заблуждение тех
> кто только его и знает, много там вообще не очень удобно сделано.Питон - это псевдокод.
> В реале это всегда типа так
В реале - нобелевские премии)
> прекращена поддержки Python 3.5 и удаленён код для обеспечения работы с Python 2Ясно, понятно, циферки ради циферок. Верной дорогой идёте, товарищи, прямо в жοпу.
С чистым numpy никто не работает, всё идет через Pandas.Эта связка потеснила R и Fotran, скопировав их методы и местами даже синтаксис.
нампай копирует матлаб (только менее удобно, см.пример выше), и это в общем-то похоже только для заядлых питонистов новость, при чем здесь р и фортран?https://opencv-python-tutroals.readthedocs.io/en/latest/py_t...
And the support of Numpy makes the task more easier. Numpy is a highly optimized library for numerical operations. It gives a MATLAB-style syntax. All the OpenCV array structures are converted to-and-from Numpy arrays.и работают с ним постоянно там где матрицы отдаются, opencv например
https://docs.opencv.org/trunk/d3/df2/tutorial_py_basic_ops.html
Almost all the operations in this section are mainly related to Numpy rather than OpenCV. A good knowledge of Numpy is required to write better optimized code with OpenCV.
А ничего, что MATLAB здорово ассоциируется с Windows? Проприетарный MATLAB не нужен!
>А ничего, что MATLAB здорово ассоциируется с Windows? Проприетарный MATLAB не нужен!У кого ассоциируется. У людей которрые им не пользуются?
https://www.mathworks.com/help/matlab/matlab_env/start-matla...
и кстати его запуск на линуксе это как раз в основном про теслы суперкомпьютерные всякие, отлаживать то ясно под форточками проще
Два самых популярных аналога - octave, scilab это кросспоатформа.
julia во многом совместима с матлабом, но расширена
numpy это неудобная попутка эмуляции возможностей матлаба
Ну а насчет не нужен, скажу как пользователь аналогов - они работают и иногда вполне годны, но до вылизанности матлаба и его тулбоксов им как до луны. Невекторизованные расчеты на октаве раз так в 100 медленнее (джит так и не работает). Сайлаб чуть побыстрее но соместимость бессмыслено испорчена, для переносаменяй там fopen на mopen и т.п. ерунду. В общем типичный опенсорс вместо работы, кого то это развлекает, а кого-то нет.
Распараллелить цикл - в матлабе меняешь for на parfor, в октаве танцы с бубном. Про использование ГПУ уж и не говорю.
Для полноты картины -в матлабе не хватает multi-gpu реализаций, на 8х gpu почти ничего нет.
И добавление multi- gpu методов идет очень медленно, и это самая большая его проблемма сейчас