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

Первый - ошибка на 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 раз выглядит слишком драматической.

Прочитал я тут историю как один инженер перешел из Google в OpenAI и между делом заявил, что для обучение Bart (аналога ChatGPT от гугла) использовались ответы ChatGPT, которые выложены на сайте sharegpt.com. Google все отрицает, доказательств нет и все выглядит как слово одного против слова другого.

В 2011 году произошла похожая история. Только доказательств было больше. Google подозревал Microsoft, а точнее Bing в том, что они копирую их поисковую выдачу. Чтобы доказать это они сделали следующее. Выбрали 100 редких запросов, вроде hiybbprqag, для которых или нет выдачи и руками захардкодили результаты в поиске. Потом попросили 20 своих инженеров из дома поискать по этим странным запросам в IE. Для 9 из этих 100 запросов Bing стал показывать то же самое. Инженеры из Google написали статью, мол Bing копирует нашу выдачу через Internet Explorer и Bing Toolbar. Напомню, что доля IE в 2011 была около 50%. Bing написал в ответ, что они только используют результаты поиска гугла, как сигнал, а не тупо копируют его. А еще накинул: “А вы сами данными Google Toolbar и Chrome не злоупотребляете?”.

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

Интересно, а в ChatGPT уже заложены ханипоты? И будет ли Google получать ответы ChatGPT с помощью Хрома, у которого доля рынка 66%?

Как-то я работал в компании, которая занималась геоаналитикой. А когда ты занимаешь геоаналитикой, приходится собирать данные из самых разных источников. Одним их таких источников был "Яндекс API поиск по организациям", откуда мы собирали данные по координатам и некоторым атрибутам магазинов, кафе и т. д. Пользовательское соглашение запрещало сохранять эти данные. Разрешено было только показывать их на картах Яндекса и кешировать. Но мы собирали и никому не рассказывали) Чтобы получить список организаций нужно передать границы прямоугольника и текстовый запрос, например "супермаркеты", "кафе и т.д." Максимум API выдавало 500 организаций. А если их было больше, то приходилось разбивать прямоугольник на прямоугольники поменьше. У бесплатного ключа стояло ограничение на 500 запросов в сутки. Поэтому приходилось регистрировать десятки Яндекса, и для каждого из них создавать ключ.

Интересный факт. Самые популярные названия магазинов выглядели примерно так:
- Продукты
- Магазин продукты
- Магазин продуктов
Оказывается крупнейшая сеть магазинов это не Пятерочка или Магнит, а Продукты

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

Поль — это реальная механическая рука, которая составлена из нескольких сервоприводов и держит самую обычную ручку. Ручку, а не карандаш, потому что карандаш может сломаться.

Работал робот, следующий образом: человек садиться перед веб камерой, робот его фотографирует и водит ручкой по бумаге. Причем алгоритм движения ручки не как у принтера сверху вниз, а как у реального художника. Вначале он намечает овал лица, потом отмечает крестиками глаза, нос, затем обозначает рот. После этого он дополняет портрет штрихами и линиями в разных частях портрета. Весь процесс занимает 30–40 минут. Это достаточно долго. Многие гости на выставке хотели себе портрет, но не каждый мог его получить. Все из-за того, что робот — это не принтер. Он работает далеко не по оптимальному алгоритму, а имитирует реального художника. Портреты получались своем авторском стиле. Этому стилю не мешают некоторые неточности или люфт механизмов.

Сейчас Поль продолжает свою творческую деятельности и не ограничивается портретами. Как и положено художнику широко не известен и проигрывает Midjourney и подобными нейронными сетями. Но что-то мне подсказывает, что человечество еще наиграется с нейронками и его время еще настанет.
https://vimeo.com/361093329