Продолжим анализировать баскетбольные данные с помощью R.

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

А строить мы будем графики скользящего среднего для трёх видов рейтинга команд НБА: атакующего, оборонительного и net-рейтинга (т.е. разницы между первыми двумя). В двух словах о них. Атакующий и оборонительный рейтинги — это количество очков, набранных/пропущенных командой за 100 владений. NET рейтинг — это их разница также на сто владений. Кому интересно узнать о них более подробно, могут прочитать глоссарий на сайте basketball-reference. Там есть формула расчёта, которую я тоже реализовал с помощью R, но так пока и не опубликовал статью об этом.

Для начала небольшая вводная информация. Меня зовут Владислав и моё знакомство с R состоялось в августе прошлого года. Изучать язык программирования я решил по причине прикладного характера. Мне с детства нравилось вести спортивную статистику. С возрастом это увлечение трансформировалось в желание как-то анализировать эти цифры и на основе анализа данных выдавать, по возможности, умные мысли. Проблема в том, что спорт в последние годы захлестнула волна данных, десятки компаний соревнуются между собой, пытаясь посчитать, описать и запихнуть в нейронку любое действие футболиста, баскетболиста, бейсболиста на площадке. И Excel для анализа не подходит категорически. Так что я решил изучать R, чтобы простейший анализ не занимал полдня. Уже в ходе изучения добавился интерес к программированию как таковому, но это уже лирика.

R — это объектно ориентированный язык. В нём абсолютно всё является объектом, начиная от функций и заканчивая таблицами.

В свою очередь, каждый объект в R относится к какому-либо классу. На самом деле, в окружающем нас мире ситуация примерно такая же. Мы окружены объектами, и каждый объект можно отнести к классу. От класса зависит набор свойств и действий, которые с этим объектом можно произвести.

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

Так получилось, что я провожу довольно много собеседований на должность веб-программиста. Один из обязательных вопросов, который я задаю — это чем отличается INNER JOIN от LEFT JOIN.

Чаще всего ответ примерно такой: "inner join — это как бы пересечение множеств, т.е. остается только то, что есть в обеих таблицах, а left join — это когда левая таблица остается без изменений, а от правой добавляется пересечение множеств. Для всех остальных строк добавляется null". Еще, бывает, рисуют пересекающиеся круги.

Я так устал от этих ответов с пересечениями множеств и кругов, что даже перестал поправлять людей.

Дело в том, что этот ответ в общем случае неверен. Ну или, как минимум, не точен.

Предисловие

Пакет tidyr входит в ядро одной из наиболее популярных библиотек на языке R — tidyverse.
Основное назначение пакета — приведение данных к аккуратному виду.

На Хабре уже есть публикация посвящённая данному пакету, но датируюется она 2015 годом. А я хочу рассказать, о наиболее актуальных изменениях, о которых несколько дней назад сообщил его автор Хедли Викхем.

SJK: Функции gather() и spread() будут считаться устаревшими?

Hadley Wickham: В какой то мере. Мы перестанем рекомендовать использование данных функций, и исправлять в них ошибки, но они и далее буду присутствовать в пакете в текущем состоянии.

Возникла недавно потребность решить вроде бы классическую задачу мат. статистики.
Проводится испытание определенного push воздействия на группу людей. Необходимо оценить наличие эффекта. Конечно, можно делать это с помощью вероятностного подхода.

Но рассуждать с бизнесом о нулевых гипотезах и значении p-value совершенно бесполезно и контрпродуктивно.

Как можно по состоянию на февраль 2019 года сделать это максимально просто и быстро имея под руками ноутбук «средней руки»? Заметка реферативная, формул нет.

Является продолжением предыдущих публикаций.

Практика показывает, что многие enterprise компании сталкиваются с трудностью в реализации аналитических проектов.

Все дело в том, что, в отличии от классических проектов по поставке железа или внедрению вендорских решений, укладывающихся в линейную модель исполнения, задачи, связанные с продвинутой аналитикой (data science) очень трудно формализуются в виде четкого и однозначного ТЗ в виде достаточным для передачи исполнителю. Ситуация отягощается тем, что для реализации задачи требуется интеграция массы различных внутренних ИТ систем и источников данных, часть вопросов и ответов может появиться только после того, как начинается работа с данными и вскрывается реальное положение дел, сильно отличающееся от документальной картины мира. Это все означает, что для написания грамотного ТЗ необходимо провести предварительную часть работы сопоставимую с половиной проекта, посвященную изучению и формализации реальных потребностей, анализу источников данных, их связей, структуры и пробелов. В рамках организаций сотрудников, которые способны провернуть такую масштабную работу, практически не бывает. Вот и получается, что на конкурсы выкладывают совсем сырые требования. В лучшем случае конкурсы отменяются (отправляются на доработку) после цикла уточняющих вопросов. В худшем случае — за громадный бюджет и длинные сроки получается нечто, совершенно не похожее на планы авторов требований. И остаются они у разбитого корыта.

Разумной альтернативой является создания внутри компании команды data science (DS). Если не замахиваться на строительство египетских пирамид, то команда и 2-3 грамотных специалистов может сделать весьма и весьма много. Но тут возникает другой вопрос, как подготовить этих спецов. Ниже хочу поделиться набором успешно апробированных соображений по быстрой подготовке такого «спецназа» с R в качестве оружия.

Является продолжением предыдущих публикаций.

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

Скорее всего достаточно длительное время вас это не будет беспокоить, и вы вряд ли будете задаваться этим вопросом. Но к примеру если вы столкнулись с задачей сбора данных из большого количества рекламных аккаунтов из API, например Яндекс.Директ, то вы значительно, как минимум в два — три раза, можете сократить время на сбор данных используя многопоточность.

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

Каждая уважающая себя контора регулярно проводит мониторинг заработных плат, чтобы ориентироваться в интересующем ее сегменте рынка труда. Однако несмотря на то, что задача нужная и важная, не все готовы за это платить сторонним сервисам.

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

Посмотреть вживую (и даже понажимать кнопки) можно здесь.

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

На протяжении многих лет я слежу за снукером, как за спортом. В нем есть всё: гипнотизирующая красота интеллектуальной игры, элегантность ударов киём и психологическая напряжённость соревнования. Но есть одна вещь, которая мне не нравится — его рейтинговая система.

Её основной недостаток заключается в том, что она учитывает только факт турнирного достижения без учёта "сложности" матчей. Такого недостатка лишена модель Эло, которая следит за "силой" игроков и обновляет её в зависимости от результатов матчей и "силы" соперника. Однако, и она подходит не идеально: считается, что все матчи проходят в равных условиях, а в снукере они играются до определённого количества выигранных фреймов (партий). Для учёта этого факта, я рассмотрел другую модель, которую назвал ЭлоБета.

В данной статье изучается качество моделей Эло и ЭлоБета на результатах снукерных матчей. Важно отметить, что основными целями являются оценка "силы" игроков и создание "справедливого" рейтинга, а не построение прогностических моделей для получения выгоды.

Тем, кто работает с R, хорошо известно, что изначально язык разрабатывался как инструмент для интерактивной работы. Естественно, что методы удобные для консольного пошагового применения человеком, который глубоко в теме, оказываются малопригодными для создания приложения для конечного пользователя. Возможность получить развернутую диагностику сразу по факту ошибки, проглядеть все переменные и трейсы, выполнить вручную элементы кода (возможно, частично изменив переменные) — все это будет недоступно при автономной работе R приложения в enterprise среде. (говорим R, подразумеваем, в основном, Shiny web приложения).

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

Является продолжением предыдущих публикаций.

Введение в теорию