data hate
103 subscribers
57 photos
1 video
14 links
Авторский канал про противоречия, заблуждения и интересные факты связанные с данными.
Download Telegram
Channel created
Однажды, исследуя данные, я посчитался среднее одной из колонок. И получил примерно такую картину:
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
👍2
Что опаснее зеленуха или ковид?

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

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

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

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

Я взял данные с сайта http://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 ℃
Графики к посту выше
Продолжим тему погоды

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

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

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

Стоит ли говорить, что работа над праздниками других стран также закончилась ничем. Оказалось писать посты в проще, чем код, поэтому это пост есть, а готового кода нет.
Но я не оставляю надежду. Если вы разбираетесь в лунных календарях пишите…
И заканчивая тему календарей. Будет ли 2100 год високосным?
Anonymous Quiz
35%
да
65%
нет