В этой статье я бы хотел рассказать о том, как именно работает метод анализа главных компонент (PCA – principal component analysis) с точки зрения интуиции, стоящей за ее математическим аппаратом. Максимально просто, но подробно.

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

Я достаточно долгое время использовал sublime (около 4 лет) в качестве основной среды разработки, но в последнее время кое-что изменилось: я освоил слепой 9-ти пальцевый метод печати. В тот момент я начал понимать людей, которым неудобно тянуться к мышке или стрелочкам. Убирать пальцы с «домашних» позиций стало неестественно и непродуктивно. Тогда я включил vintage. Проблема, вроде бы, стала неактуальна, но чего-то не хватало. Не помню, что заставило меня пересесть за vim, но мне всегда нравилось, как в нем выделяются фигурные скобки (MatchParen) и как выглядит курсор :). Vim я пробовал и до этого, когда правил конфиги на сервере, правда, вся «магия» ограничивалась переходом в режим вставки и успешным сохранением/выходом из редактора.

(ОБНОВЛЕНО!)
Среди многих реализаций LINQ-подобных библиотек на C++, есть много интересных, полезных и эффективных. Но на мой взгляд, большинство из них написаны с неким пренебрежением к C++ как к языку. Весь код этих библиотек написан так, словно пытаются исправить его «уродливость». Признаюсь, я люблю C++. И как бы его не поливали грязью, моя любовь к нему едва ли пройдёт. Возможно, это отчасти потому, что это мой первый язык программирования высокого уровня и второй, который я изучил после Ассемблера.

Написать этот пост меня вдохновила замечательная статья в блоге Gaffer on Games «Reading and Writing Packets» и неуёмная тяга автоматизировать всё и вся (особенно написание кода на C++!).

Начнём с постановки задачи. Мы пишем сетевую игру (и сразу MMORPG, конечно же!), и независимо от архитектуры у нас возникает необходимость постоянно посылать и получать данные по сети. У нас, скорее всего, возникнет необходимость посылать несколько разных типов пакетов (действия игроков, обновления игрового мира, просто-напросто аутентификация, в конце концов!), и для каждого у нас должна быть функция чтения и функция записи. Казалось бы, не вопрос сесть и написать спокойно эти две функции и не нервничать, однако у нас сразу же возникает ряд проблем.

• Выбор формата. Если бы мы писали простенькую игру на JavaScript, нас бы устроил JSON или любой его самописный родственник. Но мы пишем серьёзную многопользовательскую игру, требовательную к трафику; мы не можем позволить себе отправлять ~16 байт на float вместо четырёх. Значит, нам нужен «сырой» двоичный формат. Однако, двоичные данные усложняют отладку; было бы здорово, если бы мы могли менять формат в любой момент, не переписывая целиком все наши функции чтения/записи.
• Проблемы безопасности. Первое правило сетевой игры: не доверяй данным, присланным клиентом! Функция чтения должна уметь оборваться в любой момент и вернуть false, если что-то пошло не так. При этом использовать исключения считается неважной идеей, поскольку они слишком медленные. Мамкин хакер пусть и не сломает ваш сервер, но вполне может ощутимо замедлить его беспрерывными эксепшнами. Но вручную писать код, состоящий из if'ов и return'ов, неприятно и неэстетично.
• Повторяющийся код. Функции чтения и записи похожи, да не совсем. Необходимость изменить структуру пакета приводит к необходимости поменять две функции, что рано или поздно приведёт к тому, что вы забудете поменять одну из них или поменяете их по-разному, что приведёт к трудно отлавливаемым багам. Как справедливо замечает Gaffer on Games, it is really bloody annoying to maintain separate read and write functions.

Всех интересующихся тем, как Бендер выполнил своё обещание и при этом решил обозначенные проблемы, прошу под кат.

Буду потихоньку дорассказывать про Inception.
Предыдущая часть здесь — https://habrahabr.ru/post/302242/.
Мы остановились на том, Inception-v3 не выиграл Imagenet Recognition Challange в 2015-м, потому что появились ResNets (Residual Networks).

Что такое вообще ResNets?

Реконструкция фильмов при помощи искусственных нейросетей

Предлагаю вашему вниманию перевод авторского описания работы алгоритма автокодировщика, использовавшегося для создания реконструкции фильма “Бегущий по лезвию”, о котором я уже делал статью.В ней была описана общая история создания фильма и то, как Warner подала, а затем отозвала иск о нарушении копирайта. Здесь же вы найдёте более подробное техническое описание алгоритма и даже его код.

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

Используемый тип нейросетей называется автокодировщиком. Автокодировщик – тип нейросети с очень малым размером скрытого слоя. Он кодирует порцию данных в гораздо более короткое представление (в данном случае – в набор из 200 чисел), а затем реконструирует данные наилучшим возможным образом. Реконструкция не идеальна, но проект был по большей части творческим исследованием возможностей и ограничений данного подхода.

Работа была проделана в рамках диссертации на факультете творческих вычислений в институте Голдсмита.

Почему?

Сейчас Relap.io генерирует 40 миллиардов рекомендаций в месяц на 2000 медиаплощадках Рунета. Почти любая рекомендательная система, рано или поздно, приходит к необходимости брать в расчет содержимое рекомендуемого контента, и довольно быстро упирается в необходимость как-то его классифицировать: найти какие-то кластеры или хотя бы понизить размерность для описания интересов пользователей, привлечения рекламодателей или еще для каких-то темных или не очень целей.

Задача звучит довольно очевидно и существует немало хорошо зарекомендовавших себя алгоритмов и их реализаций: Латентное размещение Дирихле (LDA), Вероятностный латентно-семантический анализ (pLSA), явный семантический анализ (ESA), список можно продолжить. Однако, мы решили попробовать придумать что-нибудь более простое, но вместе с тем, жизнеспособное.

О создании новой операционной системы в последнее время говорят немало, особенно в России. В сумме размер всех публикаций по данной теме наверняка превышает размеры исходного кода любой операционной системы. Так что остается только одна проблема – от этих разговоров никаких новых OS не появляется. Всё, что предъявляется публике (и на что тратятся бюджетные деньги), на поверку оказывается кастомизированными сборками OS семейства Linux, а значит, не содержит ничего принципиально нового. Но, если о чем-то не говорят, это не значит, что его не существует.
В этой статье – проект принципиально новой OS, созданный в нерабочее время одним из ведущих сотрудников (Principal Engineer) российского подразделения Intel.

У меня тут синхронизируется VM надолго, поэтому есть время рассказать про то, что я недавно читал.
Например, про GoogLeNet.
GoogLeNet — это первая инкарнация так называемой Inception architecture, которая референс всем понятно на что:

(кстати, ссылка на него идет первой в списке референсов статьи, чуваки жгут)

Она выиграла ImageNet recognition challenge в 2014-м году с результатом 6.67% top 5 error. Напомню, top 5 error — метрика, в которой алгоритм может выдать 5 вариантов класса картинки и ошибка засчитывается, если среди всех этих вариантов нет правильного. Всего в тестовом датасете 150K картинок и 1000 категорий, то есть задача крайне нетривиальна.

Чтобы понять зачем, как и почему устроен GoogLeNet, как обычно, немного контекста.

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

Напоследок, о второй части доклада Surya Ganguli — как теоретическое понимание процесса оптимизации может помочь на практике, а именно, какую роль играют седловые точки (первая часть вот тут, и она совершенно необязательна для чтения дальше).

Статья для тех, кому интересна реализация библиотеки boolinq из предыдущего моего поста. В этой статье я копну в исходники и покажу несколько интересных приёмов, которые позволили сделать библиотеку «ленивой» и расширяемой.

Всё началось с того, что я в институте и после его окончания писал код на C++ и не знал бед. Но тут в один прекрасный день пришлось писать код под .NET на C#. Сперва немного поплевался, но потом ничего — втянулся. Увидел выгодные отличия от C++: безопасность, строгость и т.д. Также не смог обойти стороной LINQ при работе с коллекциями…

Продолжаю рассказывать об интересных докладах на MBC Symposium (MBC, кстати, расшифровывается как Mind Brain Computation).

Surya Ganguli — человек из теоретического neuroscience, то есть, занимается тем, чтобы понять, как работает мозг, на основе измерений импульсов нейронов на различных уровнях.

И вот тут независимо от neuroscience в мире случается deep learning, и у нас получается некую искусственную систему чему-то научить.
В отличие от мозга, в котором у нас ограниченное разрешение, сложность с повторяемостью, итд итп, про deep network-то мы знаем абсолютно все, про все веса, про все состояния. Возникает вопрос — если мы собираемся разобраться, как работает мозг, может попробуем для начала понять как и почему работает вот такая маленькая система?

Без надежд, что мозг работает также, скорее с прицелом разработать какие-то методы, которые могут быть применимы потом.

Метод Монте-Карло это алгоритм принятия решений, часто используемый в играх в качестве основы искусственного интеллекта. Сильное влияние он оказал на программы для игры в Го, хотя находит свое применение и в других играх, как настольных, так и обычных компьютерных (например Total War: Rome II). Так же, стоит отметить, что метод Монте-Карло используется в нашумевшей программе AlphaGo, победившей го-профессионала 9-го дана Ли Седоля в серии из 5 игр.

В данной статье хотелось бы рассказать про версию алгоритма Монте-Карло под названием Upper Confidence bound applied to Trees (UCT). Именно после публикации этого алгоритма в 2006-м году, программы для игры в Го сильно усилили свои позиции и достигли значительных успехов в игре против человека.

Эта статья не для академиков и не для научных сотрудников – им на роду положено написать диссертацию. Эта статья для программистов, ведущих программистов и прочих деятелей области IT, по каким-то причинам поступивших в аспирантуру и ищущих в себе силы для защиты диссера.

Недавно пройдя сей квест до конца, хочу поделиться lifehack-ами, которых мне так не хватало самой. Известно, что опыт приходит после того, как был очень нужен. Обобщаю для хабра свой опыт, разбавляя его советами от коллег из Virtuozzo и Parallels, кандидатами и докторами наук.

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

Благодаря reflection можно:
— Легко создавать редакторы, в том числе интерфейсов, так как есть удобный доступ к мета-информации о всех свойствах ваших объектов;
— Добавить binding для многих скриптовых языков сразу (Lua, Python, JavaScript и т.д.);
— Использовать мета-информацию для автоматической сериализаци;
— Использовать как фабрику объектов, создавая нужные экземпляры, имея лишь строку с именем тип;
— Использовать в качестве более легковесной замены dynamic_cast;
— И прочее прочее прочее, в зависимости от фантазии и потребностей.

Как вы думаете, чего в апельсине больше — кожуры, или, хм, апельсина?



Предлагаю, если есть возможность, пойти на кухню, взять апельсин, очистить и проверить. Если лень или нет под рукой — воспользуемся скучной математикой: объем шара мы помним из школы. Пусть, скажем, толщина кожуры равна от радиуса, тогда , ; вычтем одно из другого, поделим объем кожуры на объем апельсина… получается, что кожуры что-то около 16%. Не так уж мало, кстати.

Как насчет апельсина в тысячемерном пространстве?

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

• во-первых, в тысячемерном гиперапельсине кожуры больше, чем мякоти
• а во-вторых, ее больше примерно в 246993291800602563115535632700000000000000 раз

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

Начнем с этого, пожалуй.

Недавно я ехал на автобусе из Торонто в Нью-Йорк, снаружи автобуса было темно, внутри меня было немного портвейна, спать совершенно не хотелось, и я решил поразбираться с Deep Learning. Скачал Caffe, скормил ему пару картинкок, на которых правильно распознались мяч и банан. Захотелось распознать что-то более интересное, и я вспомнил, что где-то на жёстком диске у меня есть дамп хабрахабра, который я делал, когда проходил курс информационного поиска в ШАДе Яндекса.

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

Под хаброкатом можно прочитать чуть больше подробностей и посмотреть на всех котов.

В статье речь пойдет об одном очень не новом проекте, который создавался совсем в другое время и совсем в других условиях. Это моя старенькая RTS под названием Земля онимодов (Onimod land). Чтобы было сразу понятно, что она собой представляет, можно посмотреть коротенькое видео: