Состоялся релиз Python-библиотеки для научных вычислений NumPy 1.18, ориентированной на работу с многомерными массивами и матрицами, а также предоставляющей большую коллекцию функций с реализацией различных алгоритмов, связанных с использованием матриц. NumPy является одной из наиболее востребованных библиотек, применяемых для научных расчётов. Код проекта написан на языке Python с применением оптимизаций на языке Си и распространяется под лицензией BSD...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52082
Эта библиотека оскорбляет меня, потому что я не умею ей пользоваться.
А что такое матрица знаешь? Алебра тебя не оскорбляет?
Кто такая Алебра и почему она должна его оскорблять?
>что такое матрица знаешь?Знаю, там Нео таблетки глотал
Вот от чистого сердца огромный респект разрабам!
Я уже не представляю, как жил бы без этой либы.
Один раз попробуешь - и уже не захочешь без него писать.
>Один раз попробуешь - и уже не захочешь без него писать.А если писал до этого на матлабе - то бросишь это занятие
Если писал на Matlab'e, то переписать на NymPy - проще простого потратив относительно небольшое время, но права на код - твои, как и на Runtime - клепай свои пирожки з научным содержанием, да будет тебе счастье и вознаграждение за труд!
> то переписать на NymPy - проще простогоНо зачем, если есть Julia?..... Не пора ли прекратить грызть кактусы?....
Ваша Юлия - это и есть кактус. Матлаб и его клоны, включаю Юлию - это питон курильщика.
> это питон курильщикаКроме hello world, доводилось что-нибудь писать?.... И хоть на чём-нибудь кроме питона?
Вообще рекомендую Pandas а ещё лучше - Sage. С ним ты, как с гранатомёта, стреляешь по мат-фез. сложностями.
В реальной работе с данными - 95% методов закрывает Pandas (надстройка над NumPy). Но 5% все-таки остается. Хорошо что продукт который уже стал повсеместным в DS - развивается.
В DS у нас уже есть Julia. Всякие надстройки над надстройками - это пусть школьники тренируются.
Для этого есть гораздо более академичный R.
Тяжеловат он для молодёжи. Впрочем, если разобраться, то концепты R, таки, проще, чем то, что намешано в питоне. Ну и, производительность по современным меркам низкая.
ну да, LAPACK в юлии конечно быстрее будет (типа как "красная машина едет быстрее")
DS - это не только LAPACK. К тому же, да, надо смотреть по бенчмаркам. Даже в LAPACK разница в скорости есть.
Юлька хорошо, но под Python кратно больше всего готового в DS.Готов поспорить на ящик коньяка что Julia за 5 лет не догонит Python (и в DS, и вообще). На питоне пишется проще. А если не выключать голову - то и работает так же быстро. Вещей, подобных Anaconda - под Julia не появится, скорее всего, никогда.
Вашим мечтам сбыться не суждено. Питон, как технология, умирает. И сказки про производительность рассказывать не надо. Нигде его в прод не ставят. В том же, что касается science, если речь идёт о реальной науке и разработке новых методов, то питону там точно не место. Питону место там, где нужно что-то больше, чем калькулятор или Excel, но пользователь ничего больше не знает. В остальных местах питон - просто нашлёпка, реально тормозящая как сам процесс разработки, так и разработанную систему.
> если речь идёт о реальной науке и разработке новых методов, то питону там точно не местоАнонимусы понимают за науку, не то что этот ваш Нобелевский комитет.
Если вы про мечты о выигрыше ящика коньяка - то сбудутся.А можно доказательства хоть какого-то признака умирания Python как технологии? Только за науку, новые методы и прод - пожалуйста, не надо. Я сам прод, и вижу что в (вузовской) науке. Там еще не Julia, и давно уже не Matlab/R. Подрастет Юлька до уровня Питона по библам и комьюнити - перейдем на нее. Всего-то делов.
Про "торможение процесса разработки" - это неправда. Даже лютые противники Питона - признают высокую скорость разработки под ним.
А про скорость работы ванильного Питона я в курсе, она равна 0,1-0,15 от сишной, но в сабже она нормальная. Кроме того, сейчас никто не запрещает pypy/Cython. Но вот в чем загвоздка:
- каждый 1-й кодер (я тож) страдает преждевременной оптимизацией и нытьем что питон/джава... медленный, а ассемблер быстрый, поэтому он будет писать на чем-то третьем;
- мне как работодателю едва ли не проще докупить памяти на сервак или заменить камень на нем, чем ждать пока кодер не-на-питоне на чем то своем что-то напишет. Да и дешевле upgrade+питонер чем любой другой кодер со старым железом;
- все байки про "правильность" улетучиваются, когда усадишь команду 3-5 чел в JupyterHub и с мультикурсорами на Python накидываешь прототип DS-приложения за один вечер. И со мной это было так же - усадили и я уверовал.
> Если вы про мечты о выигрыше ящика коньяка - то сбудутся.Без шансов
> А можно доказательства хоть какого-то признака умирания Python как технологии? Только за науку, новые методы и прод - пожалуйста, не надо. Я сам прод, и вижу что в (вузовской) науке. Там еще не Julia, и давно уже не Matlab/R. Подрастет Юлька до уровня Питона по библам и комьюнити - перейдем на нее. Всего-то делов.
https://www.reddit.com/r/Julia/comments/dyf0c6/julia_ranks_1.../
(так просто, из свежего)
> А про скорость работы ванильного Питона я в курсе, она равна 0,1-0,15 от сишной, но в сабже она нормальная. Кроме того, сейчас никто не запрещает pypy/Cython.
Ещё можно Numba добавить, но делу не поможет. Фрагментация, головная боль при сборке и пр.
> мне как работодателю едва ли не проще докупить памяти на сервак или заменить камень на нем, чем ждать пока кодер не-на-питоне на чем то своем что-то напишет. Да и дешевле upgrade+питонер чем любой другой кодер со старым железом;
Исследователи не бывают дешевыми. Если речь про дата-инженер-макак, то ок. Но только пока речь идёт о типовых операциях по методичке. И да, они и за еду будут работать. Но только дальше методички выйти не могут.
> все байки про "правильность" улетучиваются, когда усадишь команду 3-5 чел в JupyterHub и с мультикурсорами на Python накидываешь прототип DS-приложения за один вечер. И со мной это было так же - усадили и я уверовал.
Ну не бывает в DS цикла разработки за вечер. Разработка нового алгоритма - от 3 до 6 месяцев. За вечер можно только по шаблону что-то сделать. К науке это никакого отношения не имеет. Впрочем, и на Julia можно за вечер по шаблону что угодно набросать. В том же Jupiter. А на следующий день собрать бинарник и закинуть в прод.
> - каждый 1-й кодер (я тож) страдает преждевременной оптимизацией и нытьем что питон/джава... медленный, а ассемблер быстрый, поэтому он будет писать на чем-то третьем;
Если вы в mail.ru/yandex работаете, то ок. Собрать весь код на питоне и сдать сишникам на полное переписывание. Хороший подход. Денег много. Можно и так работать...
Работаем в производстве, сишников не держим. Потому что эти сишники не знают питона, потребуют ТЗ, будут возиться месяц и добьются работы скрипта ну максимум "в ~2 раза быстрее". А мне не надо быстрее, мне нужно сразу, вот прямо сейчас. Весь DS в производстве, аудите, бухучете - это анализ в реальном времени. Если кто-то это еще не осознал, показываю кейс из жизни:Ответ по ЛЮБОЙ разумный вопрос по хоздеятельности - должен появляться за 60 секунд. Скажем, вопрос звучит так: "Показать список 10 самых сильно подорожавших материалов, индекс удорожания, ИНН и имя поставщика и уровень кредиторки по ним до/после - за всё время работы тов. Петрова начальником отдела снабжения". Тут три вопроса в одном.
Я укладываюсь в эти 3 минуты, используя Python+Pandas+NumPy+JupyterLab, сидя рядом с тов. Петровым бок о бок прямо на планерке, со своим же ноутбуком и RDP-сеансом по wifi к своему десктопу.
После минутного рассматривания таблички и графика - тов. Петрова увольняют, он пишет заявление по собственному, поскольку сам видел что его поставки подорожали на +88% за полгода, а по остальным снабженцам +16%. И никаких "надо посчитать, запросить, проверить" - всё сразу!
Любой другой стек технологий не даст и близко такой скорости, и никакой С/Go/Julia тут не нужен. Запрос по 4 млн строк проводок за 20 лет выполняется за 1 секунду в Python/Pandas. Для человека это такой же миг, как и 0,1 сек.
Мы такое 20 лет назад на чистом sql за минуту на древних машинках делали.А вам целый зоопарк нужен да, небось, еще и железо из верхнего ценового диапазона...
И на SQL это можно, но запрос будет выполняться в 50-100 раз дольше, должен быть толстый коннект к БД (а его в проде не выбьешь), а сам запрос должен выполнятся на сервере. Вот примерная метрика одинакового запроса 500/5000к х 50 полей:0,1 сек Pandas (RAM)
0,5 сек на SQLite IN-MEMORY (RAM)
2 сек на локальной SQLite (file)
5 сек на "сетевой" SQLite (share file)
8 сек прямой доступ к PostgreSQL
10 сек на сетевой PostgreSQL (1C)За 1 сек Pandas выдает таблицу со стилями, график по двум осям Y c усреднением по D/W/M/Q. Никакой SQL тут не поможет, а графики в Excel будут рисовать полчаса.
Из требований - только RAM. 8ГБ хватает на всё. Я вот на праздниках соберу на китайматери двухпроцовый сервак с ECC REG на 256 Гб (50 ГБ/сек на 1,8 ГГц), введу в домен и забуду эту 1С, Эксели и "далбички" как страшный сон. Ни разу не пожалел что перестал запросить в SQL в пользу Pandas.
> За 1 сек Pandas выдает таблицу со стилями, график по двум осям Y c усреднением по D/W/M/Q. Никакой SQL тут не поможет, а графики в Excel будут рисовать полчаса.Посмотрите продукты типа https://www.metabase.com/ , https://www.spagobi.org/
Возможно, питонистов после этого просто поувольняете за ненадобностью.
Starts at $10,000 /year... Не вижу никаких преимуществ перед PowerBI или, скажем, Dash (Flask+Plotly+Numpy)Знаете сколько я перевидал тех, кто говорил что программа заменит человека? Есть хорошая аналогия из истории: с приходом компьютеров в 1990-2000 прогнозировали снижение потребление бумаги во всем мире. На деле оно выросло в 5 раз.
Так вот скорее питонисты "выгонят" тунеядцев или лизингжопингующих откатмэнов.
> Так вот скорее питонисты "выгонят" тунеядцев или лизингжопингующих откатмэнов.Чистые питонисты никого не выгонят. Они ни алгоритмику не знают, ни современное железо. И как программисты в целом - довольно убоги. Проблема в том, что сейчас растёт молодёжь, которая реально верует в питон. И опять же, не путайте конкретные прикладные задачки с научной деятельностью. Чем хороша Julia - она синтаксически простая, но гибкая. Но при этом на ней можно писать программы, а не только связывать готовые куски, как на питоне. Сейчас реально непонятно, зачем использовать питон, хотя в обработке данных прекрасно ложится Julia, причём с теми же инструементами, на которых питонисты пальцы гнут. Включая кучу библиотек визуализации, как своих, так и переиспользованных с питона.
Также не забывайте, что у питона как у движка, уже нет поддержки. И сообщество разработчиков CPython разваливается. Numba работает, но частично. Nim - несовместим. Вы ни к кому не пойдёте, если что-то не работает. В случае Julia - можете дать денег Julia Computing. Они поправят что угодно от конкретных библиотек до компилятора. Лишь бы были деньги.
Сравнивать "поддержку" Python и Julia как-то рано. Ящик коньяка - в силе.Я присматриваюсь к Julia, но пока кроме питонхейта - ничего от её комьюнити не вижу. Негоже с этого начинать "расчистку территории". И вам не советую в подобном участвовать - навредите любимому ЯП.
Питон - да, не идеален, но хорош. В DS он "по залету", но лишь потому, что не-программисты (тысячи их - предметники, экономисты всякие, маркетологи, лаб. крысы) - устали ждать "правильных программистов", пока те напишут по ТЗ в кошерном ЯП. Они стали кодить сами. И Питон дал им самый простой старт и курву. 3/4 кода для всего - готово и лежит на pypi. 1/4 - это SO. Да, это клей, и он уже намазан на обе поверхности. Остается прижать.
Чистых питонистов, слава богу, нет. Алгоритмику преподают на Python же, и про "современное железо" - толсто.
> Работаем в производстве, сишников не держим. Потому что эти сишники не знают
> питона, потребуют ТЗ, будут возиться месяц и добьются работы скрипта ну
> максимум "в ~2 раза быстрее". А мне не надо быстрее, мне
> нужно сразу, вот прямо сейчас. Весь DS в производстве, аудите, бухучете
> - это анализ в реальном времени. Если кто-то это еще не
> осознал, показываю кейс из жизни:В Вашем use case напрочь отсутствует и Science, и Data. Это типовые операции на ограниченном объеме и не более того. Их и на Excel с подключенным внешним источником, наверняка, можно вообще без программирования сделать. Если же потребуется какой-нибудь нечёткий поиск и связывание строк на объемах в более, чем в 10^6, никакой питон не поможет. Будете либо на Julia переходить, либо сишников нанимать.
Ставите диагноз по фото? Я за конструктив.Кейс: две Pandas-таблицы, df1 4М*50, df2 1,6М*20. В одной - есть ИНН контрагентов, в другой есть ИНН и юрадреса, которые нам и нужны. Нужен LEFT OUTER JOIN по терминологии SQL (или =ВПР() без #Н/Д по Excel-ному). Вот как это в Pandas
df_merged = pd.merge(df1, df2, how='left', on='инн') # wall 1.2 s
Excel мало того что заткнется на 50k+ строк с ВПР (да-да, даже если это самый устойчивый формат XLSB и чтение было из TXT через простейший и быстрейший ISAM с schema.ini). Так еще и сделать вы в нем больше не сможете ничего.
Можно, конечно, прочесть силами VBA через ADO и RecordSet. Но позвольте - 1 секунда и 1 строчка кода, который можно скопипастить из тысячи мест - против кодинга на 30-50 строк и 2 часа работы?
А как вы график нарисуете по миллиону строк в Excel? А работа со временными рядами? PowerPivot - да, можно: еще один ЯП "M", еще один vendorlock, еще и -15 тыс. руб. за Excel.
Про нечеткий поиск и "большой" Excel у меня много кейсов (в нем я с 1995 г.), так что если интересно - продолжим.
Но на всякий напомню - Numpy написан на С и потому быстр. Pandas - обертка над numpy и скорости его не замедляет. Julia не быстрее С и сам С не быстрее С. Скорость всего - итак мгновенная. Ускорять - нечего.
> Но на всякий напомню - Numpy написан на С и потому быстр. Pandas - обертка над numpy и скорости его не замедляет. Julia не быстрее С и сам С не быстрее С. Скорость всего - итак мгновенная. Ускорять - нечего.Numpy будет быстр только на тех операциях, которые внутри него реализовны. И на них нет разницы, питон это или другой вариант обёртки. Возвращаясь к нечёткому поиску, сделайте склейку, например, по критерию Jaro-Winkler > 0.98, чтобы убрать опечатки. На указанных объемах, на питоне, можете его на год оставить работать... Так и о чём спорить? Код написанный на Julia - это гомогенный код, который полностью написан на Julia. А вот в numpy - любая пользовательская функция сравнения поставит его на колени.
> А как вы график нарисуете по миллиону строк в Excel? А работа со временными рядами? PowerPivot - да, можно: еще один ЯП "M", еще один vendorlock, еще и -15 тыс. руб. за Excel.
Ok. См. BI-продукты, коих море, включая opensource. Это к вопросу, как обойтись вообще без программирования.
Склейка по нечеткому 0,97 с помощью https://pypi.org/project/fuzzywuzzy/ - 4 минуты на 1 млн строк склеено, всего 4 млн.Насчет польз. функций, полагаю это про df.col.apply(lambda x: ... - оказались вполне шустрыми. Если нет - выносите в Cython, всего-то делов.
Julia рухнула в TIOBE на -11 позиций. Ящик коньяка стал чуть ближе:
Одно из немногих нужно, про которые написали на том сайте.
> а языке Python с применением оптимизаций на языке СиЧто же сразу и целиком не на C?
В библиотеке всё классами реализовано.
За что же Вы так жестоко троллите пользователей NumPy?
Fortran - наше всё.
Да, но с ним больше возни. Иногда все-таки проще SciPy-NumPy, чем копаться в древних интерфейсах какого-нибудь LAPACK из времен, когда Fortran не умел не то, что в allocate(), а даже в рекурсию.
Делетанский вопрос - нумпай это питоновская обертка для BLAS/LAPACK ?
Если да то мой второй вопрос не имеет смысла, если нет - сколько гигафлопов в пересчете на ядро на гигагерц ?
Нет.SciPy -- это питоновская обертка (довольно толковая) над BLAS/LAPACK и еще кучей либ, включая FFT, алгоритмы оптимизации и т.д. NumPy -- это ее движок (определяющий структуры данных и операции, позволяющие с этим всем работать эффективно, а не как через обычные массивы Python) -- если совсем безобразно упрощать, то питоновская обертка к реализации нормальных числовых массивов на C/Fortran .
А понятно, те в любом случае там интрефейс к сишным либам. Да я собственно почему спрашивал - на лиспе пишу, стараюсь все писать на нем, не обращаясь к С или Фотран. Надо сказать скорострельность очень даже и ничего получается.
> А понятно, те в любом случае там интрефейс к сишным либам. Да
> я собственно почему спрашивал - на лиспе пишу, стараюсь все писать
> на нем, не обращаясь к С или Фотран. Надо сказать скорострельность
> очень даже и ничего получается.Фортран велик тем, что за десятилетия его существования решения многих мыслимых математических задач уже написаны на нем и отшлифованы. Переписывать, например, LAPACK на Python -- можно, но это куча времени и усилий, сначала на реализацию, а потом гораздо больше на полировку. Собственно, авторы PyPy таки начинали реализовывать NumPy на чистом Python -- когда уткнулись в то, что обертка к C "infamously slow", но в итоге таки, похоже, забили.