Comments 14
Везде в коде R, зачем тогда в тегах указывать Python ? Причем нигде об этом не указано
В DS сейчас лидируют два языка (R, Python).
Тега DS нет, приходится расщеплять.
А что именно Вас беспокоит или огорчает?
Акцент на подходы.
Но да, питон куда беднее, нет нормальной векторизации, нет нормального бенчмаркинга фрагментов алгоритмов.
И в питоне цикл в цикле циклом погоняет -- классический стиль.
В статье весь код на R, причем тут python ? В статье нет ни одного упоминания о python. Синтаксис R и Python отличается. или с вашим подходом можно добавить и Java, и С++ ?
goto line 2 # вот и ручной бесконечный цикл
Как это понять, если информации об этом в статье нет? как понять на каком языке код в примерах, если в тегах указано 2 языка программирования? Если вы указываете абстрактно, тогда в статье не перечислены другие языки? Если в статье нет python, почему его бы не удалить из тегов?
Замечание дельное, спасибо. Дописал про язык.
Python и R -- основные в DS.
Подход первичен, код -- вторичен.
Если что-то из написанного нельзя повторить на питоне -- это будет не в его пользу.
Тэги расширяют охват аудитории. Но мне кажется такой маркетинговый ход не совсем правильный.
Что не так? Следите за руками.
Питон так же применяется в дс
В питоне циклы применяются ещё чаще
Здесь про подумать текст, а не кукбуки кодовые.
И да, я очень не люблю питон в дс за его косноязычность, ооп-шность, медленность. 1001 причина почему он плох.
Питон так же применяется в дс
И еще много где. То есть вы пытаетесь охватить аудиторию вне домена ДС. Напоминаю, мы обсуждаем соответствие тэга статье.
В питоне циклы применяются ещё чаще
Субъективное утверждение без контекста. pandas и numpy это то, где циклы применять не стоит. Это противоречит их основной идее.
Здесь про подумать текст, а не кукбуки кодовые
Если здесь про подумать, тогда почему такой ограниченный выбор языков в тэгах? Циклы много где есть.
а не кукбуки кодовые
Часть задач решается используя особенности языка, вполне кукбуки. Для питона они не подходят. Решения через алгоритмы не привязаны к языку.
И да, я очень не люблю питон в дс за его косноязычность, ооп-шность, медленность. 1001 причина почему он плох.
Если не секрет, R случайно не первый язык? Он достаточно специфичный, уклоном в оптимизацию. У меня был коллега который очень странный код на Питоне писал. Я понял почему только когда познакомился с R. В одной из первых строк статьи Вы пишите, "При работе с индексами цикла можно легко проглядеть и допустить ошибку". В контексте Питона это звучит странно, там сделано много, чтобы не работать с индексами напрямую.
питон в дс за его косноязычность
Я hello word на многих языках писал, R очень специфичный. Он хорош для той области для которой он создавался.
ооп-шность
Я хожу по краю ДС, поправьте меня, но там данные в основном в табличном виде, и парадигма ООП не особо используется. Или вы про DataModel?
медленность
Не надо обрабатывать питоном большие данные, он не для этого, им нужно оркестрировать обработку. Рекомендую посмотреть James Powell, он много рассказывает про "restricted computation domains".
Я взаимодействую с ребятами из ДС. Для них Питон это просто еще один инструмент, они освоили его на том уровне чтобы решать свои задачи. Знания языка порой на уровне джуна по Питону. Для работы с Pandas больше и не нужно.
Нет тэга ds, но это, вряд ли, вопрос ко мне.
Утверждение про циклы (да apply туда же) основано просто на просмотре многих Кloc кода.. можно по гитхабу погядеть, например. Отстутствие полноценной векторизации дает о себе знать. В R/Julia иначе.
На уровне асма циклы и ветвление -- базовая конструкция.
В DS чаще всего употребляется питон и R. отсюда и два языка. SQL вообще другое, а скалы и пр.. -- в бигдату не стоит погружаться.
Не секрет. R -- 1001-ый язык.
Ошибка с индексами цикла -- это типичный паттерн для всех языков. Out of Index... Например, Вы дельту между соседями считаете и забыли, что пролетов на 1 меньше, чем столбов.
ООП -- основа питона.... и весь дс пронизан им вдоль и поперек. методы и классы. объекты и свойства... Даже Series -- и тот является не массивом в его счетном понимании, а сложной структурой со скрытым индексом.
Вот и я про то -- питон не для больших данных. Но его по факту туда постоянно пихают. Оркестрация -- это ИТ-шные задачки.
Вот такая вот лапша между методами и функциями постоянна. Читается очень и очень тяжело...
for div in soup.findAll('div', {'class': 'entry-title'}):res[div.find('span').attrs['class'][1]] = div.text.strip()
Питон хорош для общих задач, для дс он страшно уныл. Наверное, мы как-то пришли к общему знаменателю. Спасибо за подробные вопросы.
Утверждение про циклы (да apply туда же) основано просто на просмотре многих Кloc кода.. можно по гитхабу погядеть, например
Не всё на ГитХабе стоит брать в пример.
На уровне асма циклы и ветвление -- базовая конструкция
Асм это когда в регистр кладёш из регистра достаёшь и туда-сюда прыгаешь. Нет там циклов, это уже логическая структура поверх языка.
Ошибка с индексами цикла -- это типичный паттерн для всех языков. Out of Index...
Я практически не пишу кода на Питоне, где такая ошибка может появится. Уже во многих мейнстримных языках есть итерация по коллекциям. В С++ на работе с индексами можно выиграть производительности, в Питоне скорее наоборот.
ООП -- основа питона.... и весь дс пронизан им вдоль и поперек. методы и классы. объекты и свойства... Даже Series -- и тот является не массивом в его счетном понимании, а сложной структурой со скрытым индексом.
ООП это подход к организации кода. Наличие объектов и классов само по себе не является ООП. Можно даже делать ООП без них.
Методы и классы добавляют значительную долю удобства. В Питоне отличная система типов, но в ДС она не используется, в основном там работают с набором высоко-уровневых коллекций из сторонних библиотек.
Какие у вас проблемы с Series? Заведите два массива, один для данных другой для индекса, напишите функции для изменения, чтения, используйте доступ по номеру ячейки, держите их постоянно в согласованном состоянии. Всё будет явно и никаких классов и методов, IndexError получите в подарок.
В R тоже есть сложные типы.
Вот и я про то -- питон не для больших данных. Но его по факту туда постоянно пихают. Оркестрация -- это ИТ-шные задачки
Под оркестрацией я имею ввиду передачу данных в не питоновский код, где они будет обрабатываться на скоростях близких к C++. Например Pandas это Питон снаружи и С++ внутри. Данные хранятся в С++ структурах и вызывая методы в Питоне в делегируете операции в сишный код. Аналогично с декодированием видео, все операции происходят в сишном коде.
Вот такая вот лапша между методами и функциями постоянна. Читается очень и очень тяжело...
Где здесь функции? Это плохой код не потому, что он на Питоне, а потому что он плохо написан. Как это на R будет выглядеть?
Уберите всё мыло в отдельные функции и напишите логику человеческим языком.
[clean(div) for div in get_titles()]Питон хорош для общих задач, для дс он страшно уныл. Наверное, мы как-то пришли к общему знаменателю.
У меня складывается ощущение, что вы сталкивались не с лучшим кодом на Питоне.
Возможности писать читаемый код на Питоне больше чем на R.
Андрей, а Вы неплохой оппонент! Стаж 15+?
Асм это когда в регистр кладёш из регистра достаёшь и туда-сюда прыгаешь. Нет там циклов, это уже логическая структура поверх языка.
Именно, там только условные и безусловные ветвления, я неточно выразился.
http://unixwiz.net/techtips/x86-jumps.html
Какие у вас проблемы с Series? Заведите два массива, один для данных другой для индекса, напишите функции для изменения, чтения, используйте доступ по номеру ячейки, держите их постоянно в согласованном состоянии.
У меня проблема с Series ровно одна -- он безумно заморочный. Я привык к malloc и понятному и честному представлению массивов в памяти. Series -- это объект со своим барахлом. Вы, наверное, с ndarray спутали. Series для расчетов -- медленно, неудобно, заморочно.
Например Pandas это Питон снаружи и С++ внутри.
Да ничего подобного, см https://github.com/pandas-dev/pandas. numpy -- с++. но его и писали астрономы а не недотыкомки аналитики. Почитайте про архитектуру и BlockManager, ужаснетесь. Wes McKinney уже с того момента вырос над собой и принес публичное покаяние https://wesmckinney.com/blog/apache-arrow-pandas-internals/ в виде проекта Apache Arrow.
Как это на R будет выглядеть?
Да вы посмотрите тексты публикаций. На R все выглядит компактно, элегантно и с лучшими практиками разработки.
У меня складывается ощущение, что вы сталкивались не с лучшим кодом на Питоне.
Уж как пишут -- то и приходится смотреть. Может в других частях галактики и пишут по-другому. В части DS читаемость кода на R в разы выше. Я регулярно привожу примеры. И почти всегда пример на R круче питонского.
Питон же в DS имеет огромное количество архитектурных изъянов.
Андрей, а Вы неплохой оппонент! Стаж 15+?
Поменьше.
У меня проблема с Series ровно одна -- он безумно заморочный. Я привык к
mallocи понятному и честному представлению массивов в памяти. Series -- это объект со своим барахлом. Вы, наверное, сndarrayспутали. Series для расчетов -- медленно, неудобно, заморочно.
Без контекста сложно ответить. Series это прежде всего индекс к данным. Под капотом там врде несколько ndarray
но его и писали астрономы а не недотыкомки аналитики
Как только производительнось выходит на первый план, код и апи сильно проседают по простоте и удобству. Про BlockManager почитаю. Врядли ужаснусь, я уже много разного кода видел.
Я регулярно привожу примеры. И почти всегда пример на R круче питонского.
А можно пару ссылок? По моим наблюдениям большая часть программистов пишет непонятный код. В ДС с этим должно быть еще хуже. По уму сравнивать нужно код одного качества, но что такое качество это сильно субъективно.
В ДС уже сложились некоторые традиции, которые меня с точки зрения Питона несколько огорчают. `from pandas import DataFrame` выглядит лучше, чем то, что приянто.
Питон же в DS имеет огромное количество архитектурных изъянов.
Языку широкого профиля сложно тягаться с узкоспециализированным.
Уточню, вы имеет именно Питон как язык или тот инструментарий для ДС который для него существует? В R базовые инструменты являются частью языка.
А Вы посмотрите на Series поближе. Навязанный скрытый индекс к массиву -- ужасный оверхед в счетных задачах. В R все честнее и проще. Есть массив, а есть список.
Про Numpy есть прекрасная обобщающая статя в Nature: https://www.nature.com/articles/s41586-020-2649-2Про недостатки DS питона в проде писал немного здесь: https://habr.com/ru/post/550962/
Примеры решения различных задач на R привожу в публикациях, можете поглядеть: https://habr.com/ru/users/i_shutov/posts/
R является языком общего применения и почти погодок питону. Можете посмотреть в публикациях по ссылке выше, как можно решать массу различных не DS задач.
Демонстрацию недостатков питона в части DS легко делать, открыв любую книгу по нему. Например, классику https://jakevdp.github.io/PythonDataScienceHandbook/.
И я не говорю уж о том, что в питоне нельзя просто побенчмарчить на уровне https://bench.r-lib.org/ фрагмент расчетного кода (не функции и не скрпипта) для выбора оптимального варианта решения.
%timeit вообще не игрок и вот почему:
требует юпитер ноутбука, нельзя в консоли запустить
неправильная методика эксперимента. тесты гонятся не вперемешку, а блоками. результат может быть подвержен внешним воздействиям
среднее — не лучший показатель, нужно распределения смотреть. квартили или медиану и мин/макс.
нет информации по потреблению памяти, а это важно.
Среднее по n минимальным (5 из 1000) — это вообще треш метрика. На этот показатель полагаться вообще нельзя. Статистики рыдают.
Дата саентист и циклы-циклы-циклы…