Продолжим тему погоды

На этот раз я хочу докопаться до новостей вроде “выпала половина месячной нормы осадков”. Как-то слишком часто мы её слышим. Вернемся к данным с сайта https://pogoda-service.ru/ для все той же Москвы. C данными по количеству осадков есть проблема - много пропусков. Поэтому для анализа оставим только те месяца, для которых есть информация по осадкам за все его дни. Все графики как и в прошлый раз ниже.

Распределение количества осадков имеет достаточно длинный хвост. Что, намекает, на то, что очень большие значения не должны быть редкостью.
А дальше проделаем следующую манипуляцию. Для каждого месяца посчитаем норму, как среднее количество осадков за месяц. Затем для каждого дня посчитаем его долю осадков от месячной нормы. Потом для каждого года выбираем день с наибольшей долей от нормы и наносим все это на график. Оказывается, что практически, каждый год найдется день, за который выпало больше трети месячной нормы. А половина месячной нормы выпадала минимум в 56% случаев. То есть раз в два года можно писать “сегодня выпала половина месячной нормы”

Более того, здесь я еще не рассматривал ситуации в духе “треть нормы за ночь”, “месячная норма за 3 дня” и т.д. Короче, поводов поднять шум много, но смысла в этом никакого.

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

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

В то же время, самый частый упрек в сторону соискателей, в особенности начинающих, - это их неправильное представление о будущей работе. Мол все они считают, что их ждет fit predict, а на деле это лишь малая часть работы. А если это малая часть, то почему столько внимания DS соревнованиям? Может стоит заняться чем-нибудь другим? И тут на ум приходят pet-project’ы. Уже лучше. Но далеко не у каждого хватит сил создать нужную широкому обществу библиотеку или популярный сервис. Скорее всего код будет лежать мертвым грузом радуя только своего создателя и, я надеюсь, нанимателя.

Однако, есть еще одна активность, которую забывают упомянуть - участие в open source проектах. Сами посудите: это тоже дает опыт, этим можно похвастаться на гитхабе. Вдобавок даже минимальная правка - уже законченный кусок работы. Можно добавить одну строчку кода и на этом остановиться. В то время, как в своем проекте запросто можно застрять на полпути и в итоге не получится ничего. Плюс у этого занятия есть общественная ценность. После того как твои правки приняли, пользователи по всему миру начинают использовать твой код. А это добавляет мотивацию.

Я бы не писал этот пост если бы сам, хоть чуть-чуть не контирубьютил. Мой выбор пал на достаточно простую, но полезную библиотеку https://github.com/dr-prodigy/python-holidays,
Так что если давно мечтали начать свой путь путь в open source, то это отличный старт, ведь там есть праздники для 90 стран, а в мире их по мнению ООН 193. А когда страны закончатся, можно перейти к праздникам отдельных областей, провинций и штатов.

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

Сейчас настало время рассказать о неудачном опыте с лунными календарями в процессе работы над библиотекой python-holidays.

Начало не предвещало беды. Я увидел на issue, в котором предлагалось добавить праздники из prophet для стран которых нет в python-holidays, а это Индонезия, Пакистан, Филиппины, Таиланд. Автора этого issue останавливала только необходимость писать тесты. А меня нет поэтому я взялся за работу. Благо код можно было взять из prophet, а сам код праздников написан по такому же принципу как и в python-holidays.

С самого начало все пошло не совсем гладко. Оказалось, что праздники, которые завязаны на лунный календарь захордкожены. То есть просто вбит список дат за 2020 год +/- 5-10 лет. Готовых библиотек для нужных мне стран не было. Поэтому там где не смог написать по-нормальному, оставил захордкоженные даты. Естественно я написал тесты для каждого праздника. Но test coverage уменьшился, а у авторов pithon-holidays принципиальная позиция - каждый pull request не должен понижать покрытие тестами, которое и без того 99%. Покрытие уменьшилось из-за того что тест не обходил каждую строчку. Можно было бы дополнить тесты по сути скопировав код. Но по-моему как-то тупо писать тесты на захордкоженные даты. Поэтому я решил все-таки разобраться в этих лунных календарях.

Расскажу, что у меня приключилось на примере Таиланда. Я нашел астрономическую библиотеку ephem, в которой можно узнать все о положении небесных тел. Меня здесь интересуют полнолуния. В Таиланде, если верить википедии первый месяц их лунно-солнечного календаря наступает в первое полнолуние декабря. Все просто. Берем функцию которая считает datetime следующего полнолуния. Хотим мы например посчитать время праздника "Asalha Puja", который отмечают каждое 8 полнолуние года. Берем первое полнолуние в декабре, отсчитываем еще нужное количество полнолуний и получаем дату. Вроде бы все так, но не совсем. Сравниваем прогноз с фактом и вот что имеем:

| fact | pred datetime of full moon| delta, days |
|:-----------|:--------------------------|--------------:|
| 2001-07-05 | 2001-07-05 22:03:45+07:00 | 0 |
| 2002-07-24 | 2002-06-25 04:42:20+07:00 | -29 |
| 2003-07-13 | 2003-07-14 02:21:22+07:00 | 1 |
| 2004-07-31 | 2004-07-02 18:08:53+07:00 | -29 |
| 2005-07-21 | 2005-07-21 18:00:13+07:00 | 0 |
| 2006-07-11 | 2006-07-11 10:01:52+07:00 | 0 |
| 2007-06-30 | 2007-06-30 20:48:42+07:00 | 0 |
| 2008-07-18 | 2008-07-18 14:59:03+07:00 | 0 |
| 2009-07-07 | 2009-07-07 16:21:24+07:00 | 0 |
| 2010-07-26 | 2010-06-26 18:30:20+07:00 | -30 |
| 2011-07-15 | 2011-07-15 13:39:35+07:00 | 0 |
| 2012-08-02 | 2012-07-04 01:51:52+07:00 | -29 |
| 2013-07-22 | 2013-07-23 01:15:31+07:00 | 1 |
| 2014-07-11 | 2014-07-12 18:24:53+07:00 | 1 |
| 2015-07-30 | 2015-07-02 09:19:34+07:00 | -28 |
| 2016-07-19 | 2016-07-20 05:56:33+07:00 | 1 |
| 2017-07-09 | 2017-07-09 11:06:33+07:00 | 0 |
| 2018-07-27 | 2018-06-28 11:52:57+07:00 | -29 |
| 2019-07-16 | 2019-07-17 04:38:12+07:00 | 1 |
| 2020-07-05 | 2020-07-05 11:44:23+07:00 | 0 |
| 2021-07-24 | 2021-06-25 01:39:40+07:00 | -29 |
| 2022-07-13 | 2022-07-14 01:37:35+07:00 | 1 |
| 2023-07-03 | 2023-07-03 18:38:38+07:00 | 0 |
| 2024-07-21 | 2024-07-21 17:17:04+07:00 | 0 |
| 2025-07-10 | 2025-07-11 03:36:42+07:00 | 1 |

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

Первый - ошибка на 29-30 дней. Тут я кое о чем не упомянул. Если год составить из 12 лунных месяцев, то его продолжительность будет 354-355 дней и он будет сдвигаться относительно Григорианского и времен года. Что конечно неудобно, ведь непонятно когда сажать картошку. Мусульмане на это забивают, а вот буддисты нет и иногда добавляют еще один високосный месяц (а почему мы не добавлять месяц). В википедии про это написано, но непонятно по какому правилу определяется какой код високосный, а какой нет.

Второй - ошибка на день, с которой я совсем не разобрался.

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

Есть довольно известное высказывание: “Существуют три вида лжи: ложь, наглая ложь и статистика”. Достоверно неизвестно, кто ее придумал, но в широкий оборот её ввел Марк Твен. Меня всегда напрягала эта фраза - это же приговор целой науке, притом достаточно точной. Чтобы понять что к чему, я обратился к источнику этой фразы - автобиографии Марка Твена. https://www.gutenberg.org/files/19987/19987.txt

В моем вольном переводе/пересказе вот он пишет:
36 лет назад, когда я был молодым я писал по 3к слов в день, а сейчас пишу плюс-минус 1.5к слов в день. Может показаться, что я замедлился, но раньше работал я целыми днями, а теперь работаю по пол дня. Получается половина работы за пол дня.
А дальше цитата про ложь, наглую ложь и статистику.

Интересно, конечно, но, по моему, очень слабо чтобы ссылаться на эту цитату в сколько-нибудь разговорах.

Безусловно, статистика может приводить к ошибочным выводам, если ей намеренно манипулируют или случайно ошибаются из-за недостатки компетенций в предметной области. Но в таком случае оспаривать выводы нужно по фактам, а не фразой: “Статистика - ложь, бе, бе, бе…”

Так что давайте забудем эту фразу и будем вспоминать, только когда речь зайдет о том сколько часов в день работал Марк Твен в разные периоды своей жизни.

Есть фраза от которой у меня все полыхает внутри: “История не терпит сослагательного наклонения”. Мол, зачем задумываться, что было бы если бы Наполеон не напал, если бы мы не победили в Сталинградской битве и т.д. Это не случилось вот мы и не знаем, что бы было поэтому и не стоит про это говорить.
Кто там не должен терпеть? Давайте посмотри на определение истории как науки.

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

Как сделать выводы о причинах событий не рассуждая о том куда бы все пришло, если бы не все сложилось иначе. Посмотрим например на Сталинградскую битву. Что было бы если бы мы её проиграли? Предположим, что тогда мы бы проиграли войну. Тогда делаем вывод о причине события: война выиграна, в том числе, благодаря победе в этой битве.
Или если мы считаем, что и без этого была бы одержана победа, то мы вычеркиваем эту битву из причин победы в войне.

Это чем-то похоже на методы оценки экономических эффектов, даже при отсутствии AB теста. Это непросто. Приходится опираться на некоторые предположения и делать допущения. Но можно употребить сослагательное наклонение и сказать, к примеру, если бы не эта рекламная кампания, то продажи были бы такие. Это ничем принципиально не отличается от если бы в истории.

Gartner - крупная консалтинговая компания, которая работает более чем в 100 странах мира. В последние годы она она стала известна широкой публике своей методологией анализа технологий - Gartner Hype Cycle или попросту говоря кривой Гартнера (см. картинку).
Ее идея состоит в том, что новые технологии проходят разные этапы: инновационный триггер, пик завышенных ожиданий, пропасть разочарования, склон просветления, плато продуктивности. Технологии располагаются на кривой. Глядя, на кривую можно увидеть что подбирается к пику хайпа, чей хайп скоро закончится и так далее.

Недавно мне попалась на глаза научная статья 2010 , про эту кривую года Scrutinizing Gartner’s Hype Cycle Approach. В ней авторы авторы критикуют эту кривую. Даже не просто критикуют, а называют её устройство методологически и эмпирически flawed (ущербным). Flawed можно перевести как ошибочный, но первый перевод мне нравится больше).

Авторы отдельно рассматривают два участка кривой - пик и S-образный выход на плато. С пиком хайпа все понятно - он внезапно начинается и также внезапно пропадает. По оси X время, по оси Y ожидание. А вот у S-образной кривой теоретическая подоплека несколько богаче. Есть исследования, в которых говорится, что технологии развиваются по такой кривой, и в конце упираются в технологический потолок. Проблема в том, что у S-образной кривой развития технологий другие по осям величины не время и ожидание, а вклад в развитие технологии (инвестиции) и распространение (доля рынка). Как известно, разные величины нельзя ни складывать, ни откладывать от одной оси. Поэтому кривая как-то не совсем складывается.

Методологическими замечаниями авторы не ограничились. Если есть прогноз, то почему бы его не проверить. Для проверки авторы выбрали технологии энергетической отрасли отмеченные на кривых 2003 - 2009 годов и сразу столкнулись с проблемой.
Технологии могут переименовать, разделить на несколько или убрать с кривой. Некоторые технологии задерживаются на пике хайпа, что противоречит самой идеи кратковременного пика, какие-то так и не забираются на этот пик, другие же появляются только на плато.

Однако, сложности не остановили исследователей. Они выбрали 3 технологии и сравнили положение на кривой Гартнера с число статей в google news и количеством запросов выбранных технологий относительно всей энергетической отрасли. Точность кривой Гартнера, мягко говоря, вызывала вопросы.

Я тоже решил посмотреть на прогноз некоторых технологий. В 2015 сразу на пике появляется machine learning. Он остается на пике и в 2016, и в 2017 году, а в 2018 году пропадает. Прошло 10 лет, а кривая лучше не стала.

Gartner curve 2016, картинка к посту выше

Часто встречаются ситуации, когда вместо среднего арифметического используется медиана. И идёт речь о том, что среднее врет, а медиана показывает настоящее правильное значение. И приводят такой пример:

При расчете средней заработной платы, когда 19 сотрудников получают по 20 тысяч рублей, а директор — миллион. Среднее арифметическое в этом случае будет равным 69 тысячам рублей, а медиана — 20. Поэтому медиана лучше, ведь большинство получат 20 тысяч, а 69 тысяч какое-то неправильное значение.

Как-то маловата компания, чтобы директор получал миллион. Допустим, что это утрированный случай для яркой иллюстрации. Тогда давайте рассмотрим другой утрированный случай. Представьте, что в некоторой другой компании 11 сотрудников получают 20 тысяч рублей, а остальные 9 по миллиону. Тогда медиана у этих двух компаний одинаковая, по 20 тысяч, а вот среднее во втором случае 461 тысяча. Здесь среднее показывает более честную картину.

Продолжим тему зарплат. По данным Википедии средняя зарплата в России 56 тысяч, а медиана 40. Очевидно в этом виноват длинный хвост больших зарплат, а медиана менее сильно на него реагирует. Проблема в том, что и на околонулевые значения она реагирует меньше. Представьте, что зарплата 30 процентов самых бедных выросла, но не до уровня медианы. Тогда медиана не изменится, а вот среднее покажет рост. Несмотря на это медиану выбирают как более честную меру. Мол 40 тысяч еще похоже на правду, 56 ни в какие ворота не лезет, посмотрите на зарплату на заводе. Не обязательно использовать медиану, чтобы оценить зарплату на условном заводе. Для этого можно подсчитать средний доход, например, среди 30% самых низких зарплат.

Еще один случай - расчет фичей. В таком случае одно аномально большое значение может сильно сместить среднее. Но и в этом случае не обязательно использовать медиану. Можно просто выкинуть выбросы. Или вот такой пример:

Представьте, что у нас мало, точек и мы хотим посчитать по ним среднее. Допустим эти значения {0, 1, 10}. Медиана равна 1. И чем медиана равная 1 лучше чем среднее 3.67?

Среднее значение повсеместно используется при расчете среднего чека. Почему-то никто не считает медианный чек, и правильно делает. Есть очевидное соотношение выручка = средний чек * количество чеков. Хотите увеличить выручку - повышайте количество чеков или средний чек. А вот для медианного чека такое соотношение не получится посчитать. Вдобавок к этому рост медианного чека при том же количестве чеков не обязательно будет означать рост выручки.

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

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

Наткнулся на классную видео визуализацию того как технологии двигались по кривой Гартнера. Можно наблюдать как пересматриваются прогнозы. Особенно занятно выглядит история для виртуального ассистента. В 2009 год у него уже прошел хайп, в 2013 он "скоро достигнет плато", а в 2014 году оказалось, что хайп еще впереди. Позалипать на то как менялись тренды можно в оригинальном видео по ссылке.
https://vimeo.com/464835556#t=2m18s

На 2 курсе бакалавриата у нас был выбор: пойти на обычное программирование или на интересное. В интересном было много курсов, и я выбрал программирование на LabVIEW. LabVIEW - язык программирования на основе блок диаграмм. Но его главная особенность - возможность быстро подключиться к любой железке и быстро набросать интерфейс для взаимодействия с ней. В конце курса каждый студент должен был сделать проект. Мой проект назывался “задача слежения”. Заключалась она в следующем. Имелась камера Logitech Orbit. Она могла поворачиваться влево вправо и наклоняться вверх вниз.

Можно попробовать выбрать объект и следить за ним. Если он не в центре, то необходимо повернуть камеру в нужную сторону. Сегодня эта задача не звучит сложной, но как это сделать если на дворе 2013 год, а код нужно писать на языке LabVIEW. К счастью, все не так плохо, как кажется. Была готовая библиотека, которая по небольшой картинке находит расположение максимально похожее на заданное изображении. За давностью лет я не помню как она работала, но там точно и речи не шло про нейронные сети.

Еще удалось реализовать фичу расчета расстояния от камеры до точки. Делалась это на основе того как смещалось положение объекта в кадре в зависимости от ворота камеры. Тут с со слежением было попроще, потому что окружение объекта не двигалось, а менялся только ракурс. Из-за сильного люфта была очень большая погрешность измерения расстояния. Но отличить 30 см от 1 метра, и метр от 3 метров было реально.

С тех пор к языку LabVIEW больше никогда не возвращался, но еще долго писал его в резюме.

Существует Портал открытых данных Москвы . Там есть данные разной степени интересности от практически бесполезных до, например, датасета дорожных знаков.

Мне же приглянулся датасет расписание рейсов, в котором есть детальное расписание всех маршрутов наземного городского пассажирского транспорта. Рядом лежат справочники, в которых находится информация какому рейсу соответствует какой маршрут и т. д. Все датасеты можно сохранить в удобном формате. Но год назад, когда я собирался это сделать возникла проблема. Датасет расписание рейсов нельзя было скачать. Под ссылкой на скачивание было написано генерируется. Я подождал несколько дней, а датасет для скачивания все еще генерировался. Пришлось воспользоваться API. Оно, к счастью, у data.mos.ru есть.

В API можно пропускать N первых строк и выбрать число объектов в ответе. В документации говориться, что можно запрашивать до 10 тысяч записей, но в реальности для датасета с расписанием это оказалось слишком много. Поэкспериментировав с числом записей, которое я хочу получить и разным количеством одновременных запросов, я пришел к следующей формуле: оптимально запрашивать по 100 записей пачками по 5-7 запросов одновременно. Если запрашивать больше, записей или чаще, то это помогает ненадолго. Потом API перестает работать на несколько минут. У меня сложилось впечатление, что у них какая-то супер неоптимальная база для миллионов строк и я её единственный пользователь, который работает на грани того, чтобы её положить.

Так как сбор данных - это разовая акция, то я не заморачивался и запускал скрипт локально из ноутбука. Иногда я забывал включить сбор данных, бывало ночью компьютер сам по-себе перезагружался, однажды даже выключили свет. Несмотря на это, почти за месяц мне все-таки удалось собрать датасет.

Хорошо, что сейчас его можно скачать по-человечески одним кликом. И хорошо, что такая возможность появилась только сейчас, а не сразу после того как я закончил свои мучения с API. Иначе было бы очень обидно.

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

Я считал, что есть 3 вида вершин графа.
- точки начала и конца маршрута
- пешеход на остановке
- человек в автобусе на остановке
Точки начала и конца маршрута соединяем с ближайшими вершинами пешеход на остановке. Пешехода на остановке соединяем с человеком в автобусе на этой же остановке. Вершины в автобусе на остановке соединены друг с другом согласно маршруту, по которому движется автобус.

Вес (время в пути) для ребер, в зависимости от того, что мы соединяем - это
- интервал движение конкретного маршрута
- время в пути между остановками
- расстояние деленное на скорость пешехода

Стоит отдельно упомянуть про соединение вершин пешеход на остановке. Если маршрут с пересадкой, то иногда сесть на второй автобус нужно не на той остановке, на которую ту приехал. Необходимо пройтись для соседней. В графе это реализуется просто - нужно добавить ребер между соседними остановками. Однако, необходим компромисс - если соседей мало, то возникают маршруты, где нужно:
- выйти из автобуса
- дойти до остановки 1
- дойти до остановки 2
- дойти до остановки 3
- сесть в автобус.
Зачем идти до 2 остановки, если можно сразу дойти до 3. Этот эффект можно устранить, если увеличить количество соседних остановок, между которыми я строю ребра, но это увеличивает размер графа а, следовательно, время построения маршрута. Для работы с графами я использую библиотеку networkx и в этой задаче я упираюсь в производительность, поэтому приходится искать компромисс. К счастью этот компромисс мне удалось найти и получились маршруты похожие на правду.

У нас есть маршрутизатор. Осталось добавить карту и "убийца Яндекса" готов. Для рисования карт я выбрал библиотеку OpenLayers, которая подкупила меня богатой галереей примеров.

Посмотреть, что же получилось и поиграться можно по ссылке.
https://185.117.153.195:5000/

По данным Mediascope аудитория Instagram упала в 5 раз. Стоит задаться вопросом, как они считают. А считаю они следующим образом. Они просят людей установить приложение на свой телефон. А приложение передают детальную информацию о трафике и использовании приложений. Mediascope утверждают, что выборка у них репрезентативная, а если нет, то они её перевзвешивают. И вроде бы все хорошо. Но есть два нюанса:
- приложение Mediascope есть только на Android. То есть в выборку не попадают пользователи яблочных телефон. А это важно, особенно для определения популярности инсты
- cколько людей, которые продолжили пользоваться истаграмом с помощью VPN, удалили или не стали устанавливать приложение, которое следит за ними? Ведь как-то странно с одной стороны заходить обходными путями в запрещенную соцсеть, а с другой отдавать свои данные кому попало. Интересно, сколько по их данным, особенно одаренных людей, которые пользуются тором.

Поэтому оценка падения в 5 раз выглядит слишком драматической.