Однажды, исследуя данные, я посчитался среднее одной из колонок. И получил примерно такую картину:

In [3]: df['col'].mean()
Out[3]: 2.007003005007002e+28

Это было сильно больше того, что я ожидал увидеть. Так как значения там были порядка 100
In [4]: df[['col']].head(3)
Out[4]:
col
0 200
1 700
2 300

Оказалось, что дело в том, что в поле col были строки, а не числа. И pandas незадумываясь сложил строки, а потом поделил. Раз считается среднее, то, тем более, посчитается и сумма.
In [5]: df['col'].sum()
Out[5]: '200700300500700200700300500700'

А вот и разгадка числа появления числа 2.007003005007002e+28
In [6]: int(df['col'].sum())/len(df)
Out[6]: 2.007003005007002e+28

Что опаснее зеленуха или ковид?

Есть довольно известная задача про зеленуху:
Тест на болезнь «зеленуху» имеет вероятность ошибки 0.1 (как позитивной, так и негативной), зеленухой болеет 10% населения. Какая вероятность того, что человек болен зеленухой, если у него позитивный результат теста?

Правильный ответ 0.5, а не 0.9. Подробнее почему здесь dyakonov.org/2015/10/12/формула-байеса

Теперь применяем задачу у нашим реалиям, то есть к тесту на коронавирус. Мы точно не знаем какая часть от всех людей болеет, у разных тестов разная точность, да ещё и точность зависит от тяжести симптомов. Но точно можно сказать, что если человек прошел тест случайно (допустим не из-за симптомов, а просто так или для поездки/мероприятия) и тест показал положительный результат, далеко не факт, что он болен.

Не читайте новости про погоду

Каждый год появляются новости о новых температурных рекордах. Один день "стал самым холодным за 30 лет", другой "самым жарким за всю историю". Послушаешь эти новости и кажется, что скоро мы придем к тому, что температура будет колебаться между -100 и +100°C. Но это не совсем так, да и рекорды не совсем рекорды.

Я взял данные с сайта https://pogoda-service.ru/ для Москвы. Это источник с самой большой историей подневных данных о погоде. Данные не полные (см. ниже график "Число записей для каждого года"), но будем анализировать то, что есть.
Из графика "Число дней с рекордной температурой за всю доступную историю" хорошо, что видно, что у каждого года есть свой температурный рекорд (нет рекордов только там, где нет данных).

Давайте рассмотрим новость "Температурный рекорд 1973 года побит в Москве". https://www.interfax.ru/moscow/701064
В ней говорится, что 26 марта 2020 стал самым теплым 26 марта как минимум с 1973 года. По моим данным так и есть. И этот рекорд 16.2 ℃. Но это день не такой уж и теплый. Например в 2014 году были дни до 26 марта, когда температура была больше . А в 1990 году 20 марта была достигнута температура 16.8 ℃.

| дата | макcимальная |
| | температура,℃ |
|:-----------|---------------:|
| 20.03.1990 | 16.8 |
| 24.03.2014 | 18.4 |
| 25.03.2014 | 19.2 |
| 26.03.2020 | 16.2 |
| 27.03.1983 | 16.4 |
| 28.03.2020 | 17.4 |

Так что формально рекорд, есть но по-хорошему он не то, что 1973 год не побил, он даже 2014 не смог переплюнуть. Поэтому настоящие рекордсмены 1990 год в категории до 20 марта и 2014 год в категории до 25 марта.

Тут еще стоит подумать как сравнивать даты по разную стороны от середины зимы. Вот, например заслуживает ли 13.11.1977 с 19 ℃ большей славы чем 20.03.1990 с 16.8 ℃

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

На этот раз я хочу докопаться до новостей вроде “выпала половина месячной нормы осадков”. Как-то слишком часто мы её слышим. Вернемся к данным с сайта 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 больше никогда не возвращался, но еще долго писал его в резюме.