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

При расчете средней заработной платы, когда 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

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

В ноябре продажи снизились на 2% по отношению к октябрю, составив 133 тыс. авто. Из них было продано 108,5 тыс. легковых машин (меньше на 3%), 11,1 тыс. LCV (рост на 5%), 12,1 тыс. грузовиков (меньше на 5%), 1,4 тыс. автобусов (рост на 18%).

Эти же данные можно представить в виде таблицы. В отчете, на основе которого написано новость, именно таблица. Зачем её переписывать?

Решил я поиграться с Mojo - новым языком программирования, который позиционируется как более продвинутая альтернатива Python. Тем более недавно выкатили его SDK и теперь его можно запускать локально, а не в ноутбуке на облаке. Код, правда, писать можно только в VS Code. Туда завезли плагин для подсветки синтаксиса. Так что пришлось скачивать непривычную для меня IDE. В jupyter ноутбуке Mojo как бы можно запускать, но не в привычном всем виде, а опять таки через только через VS Code.

Я немного поигрался, почитал доку. Mojo как я понял пытается более эффективно работать с памятью. Но в отличие от других языков старается делать так, чтобы не было возможности выстрелить себе в ногу. При этом сохраняя совместимость с Python. Везде в доке написано примерно следуещее: можете делать как в Python, а можете по новому вот так.

Существует страница с проектами на Mojo. Но там в основном проекты, которые кто-то сел затащил в одиночку, а сейчас подзабросил. Это мне напомнило мои pet-проекты, поэтому не знаю взлетит все это в ближайшее время или нет)) Есть относительно популярный репозиторий для работы с датами morrow.mojo. У него 26 форков, но при этом всего 2 контрибьютора. При том что нет отрытых issue или pull requests. Зачем его форкают? По приколу?

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

В далекую доковидную эпоху, до появления искусственного интеллекта, появился генератор "Генератор тупых новогодних поздравлений". Сейчас такой генератор никого не удивит. Чего мы только не видели за последнее время. Но давайте в наступающем году не забывать про if'ы, эвристики и прочие просты подходы.
https://maximilyahov.ru/generator-new-year/

Недавно я потестил Copilot. У них есть бесплатный триал на один месяц, но для этого нужна карта. Пришлось воспользоваться одним из сервисом, который за 300 рублей дал мне на время карту, которую можно прикрепить. Я установил плагин в свой любимый PyCharm и начал тестировать.

Код он генерить - все как положено. Но вот сгенерировать что-то осмысленное я так и не смог. Я открыл свой пет-проект. Жму на кнопку, смотрю, что там Copilot предложит. Но ничего интересного он не предложил. Либо предложил, но что-то совсем не то. Может быть если бы я более детально написал промт, то он и написал бы, то что мне нужно. Но раз Copilot - "искусственный интеллект", пусть он за меня думает. Если уже нужно детально что-то прорабатывать, то я напишу код, а не супер подробное ТЗ.

Так что мне пока не зашло.