MarkovJunior — это вероятностный язык программирования, в котором программы являются сочетаниями правил перезаписи, а инференс выполняется при помощи распространения ограничений. MarkovJunior назван в честь математика Андрея Андреевича Маркова, придумавшего и исследовавшего то, что сейчас называется алгоритмами Маркова.

В 2017 году мы написали пост о том, как храним миллиарды сообщений [перевод на Хабре]. В нём мы рассказали о том, как начали с использования MongoDB, но потом выполнили миграцию данных в Cassandra, потому что искали надёжную, устойчивую к сбоям базу данных, имеющую относительно низкую стоимость обслуживания. Мы знали, что будем расти, так и произошло!

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

Спустя почти шесть лет мы многое изменили; изменился и способ хранения сообщений.

Введение

Поначалу кажется, что создать игру от первого лица без движка или графического API практические невозможно. В этом посте я расскажу, как это сделать при помощи алгоритма под названием ray casting.

Моя цель — показать, что сложную задачу можно разбить на более простые части, и если я всё сделаю правильно, то у вас появится ощущение, что вы сами открыли, как работает игра.

Для начала разберёмся, как работает алгоритм, а затем построчно напишем его. Затем мы пересмотрим код, добавим несколько возможностей и оптимизируем его размер. Я постарался сделать пост максимально доступным и дружелюбным, но вам поможет приличное знание программирования, Rust и основ геометрии.

Мы начали с вопроса: откуда GPT-2 знает, когда использовать слово an, а не a? Выбор зависит от того, начинается ли следующее за ним слово с гласной, однако GPT-2 может прогнозировать только одно слово за раз.

У нас по-прежнему нет полного ответа, однако мы нашли нейрон MLP в GPT-2 Large, который необходим для прогнозирования токена " an". Также мы выяснили, что веса этого нейрона соотносятся с эмбеддингом токена " an", что позволило нам найти другие нейроны, прогнозирующие конкретный токен.

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

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

Я создал прототип ракетной атаки! Для этого понадобилась хитрая математика, о которой будет рассказано в этой статье.

Мы поговорим о кубических кривых Безье, шуме Перлина и rotation minimizing frames.

Пусть Manifest v3 и ограничил возможности браузерных расширений, но я считаю, что они далеко не исчерпаны. Чтобы доказать это, создадим расширение Chrome, крадущее максимально возможное количество данных.

Мы добьёмся двух целей:

• Исследуем грани возможного для расширений Chrome
• Продемонстрируем, что вы подвержены опасности, если не будете аккуратны с тем, что устанавливаете.

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

В первой части поста мы начали реализацию с нуля GPT всего в 60 строках numpy.

Во завершающей части мы загрузим в нашу реализацию опубликованные OpenAI веса обученной модели GPT-2 и сгенерируем текст.

В этом посте мы начнём реализацию с нуля GPT всего в 60 строках numpy. Во второй части статьи мы загрузим в нашу реализацию опубликованные OpenAI веса обученной модели GPT-2 и сгенерируем текст.

На примере любопытного небольшого прототипа я захотел проверить, сколько труда потребуется при использовании ИИ для создания максимально возможного количества графики 2,5D-игры в жанре point and click.

Было понятно, что искусственный интеллект без проблем справится с задниками, поскольку игра, фактически, остаётся по большей мере в 2D, но с персонажами ситуация чуть более сложная. Мне понадобится крайне быстрый конвейер работы, позволяющий использовать данные захвата движения, поэтому создание анимаций не окажется узким местом. Я должен был найти способ перенести сгенерированную ИИ графику в форму, которая приемлема для захвата движения.

Мне показалось, что лучше всего будет сгенерировать концепты персонажей при помощи ИИ, а затем смоделировать их в 3D.

Я работаю в игровой индустрии уже более двадцати лет, и в основном занимаюсь моделированием персонажей и фонов. Поэтому будет интересно проверить, позволит ли ИИ мне работать быстрее. И насколько?

В 2017 году появилась компания NYCTrainSign, которая изготавливала реплики таймеров обратного отсчёта, показывающие, сколько осталось до прибытия следующего поезда Нью-Йоркского метро.


Однако этот таймер не вешался на потолок, а ставился на стол в качестве стильного украшения дома.

Человек, отвечавший за маркетинг, успешно смог привлечь интерес к проекту. Помню множество постов в Facebook* и Instagram*, демонстрирующих потенциальную пользу вывески для кафе и пиццерий, посетители которых могли видеть, когда им нужно выходить, чтобы попасть на поезд.

Однако под флёром Instagram* скрывались посредственные технические решения и недопустимо высокие затраты на производство. [* Запрещены в России.]

В начале 2018 года компания перестала отвечать под постами в соцсетях, а приобретённые таблички получили очень немногие покупатели. Компания порекомендовала покупателям оспорить платёж, чтобы попробовать вернуть свои деньги.

Предположим, вы программист и у вас есть два числа. Вы хотите узнать, какое из чисел больше. Если оба числа имеют одинаковый тип, то почти в любом языке программирования решение будет тривиальным. Для этой операции обычно даже есть специальный оператор <=. Вот пример на Python:

>>> "120" <= "1132"
False

Сравнение двух чисел на Brainfuck оставим в качестве упражнения для читателя.

Ой. Ну, строго говоря, это строки, а не числа, а строки обычно сортируются лексикографически. Но это всё-таки числа, хотя и представленные в виде строк. Это может показаться глупым, но такая проблема очень распространена в интерфейсах пользователя, например, в списках файлов. Именно поэтому нужно отбивать числовые имена файлов нулями (frame-00001.png) или использовать описания, сохраняющие лексикографический порядок, например, ISO 8601 для дат.

Впрочем, я отклонился от темы. Предположим, числа действительно представлены числовыми типами. Тогда всё просто и <= отлично работает:

>>> 120 <= 1132
True

Но так ли это?

Представьте: рабочий день в компании, занимающейся обработкой платёжных поручений. Возникла критически важная задача дата-инжиниринга, которую нужно выполнить. В этом случае я тот самый дата-инженер, которому нужно решить задачу, но у меня недостаёт информации, необходимой для завершения модели данных. Я услышал информацию на совещании. Её обсуждали на standup-митинге. У меня есть несколько запутанных текстовых заметок, но я не могу вспомнить технических подробностей, которые необходимы для завершения работы. Никто не может ответить на мой вопрос. И тут меня озаряет: во время митинга мне нужно было делать заметки вручную.

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

В 2005 году консоль Xbox 360 была выпущена в виде двух моделей: Core и Pro. Core — это дешёвая модель, позволявшая запускать игры с оптического диска, а Pro содержала жёсткий диск на 20 ГБ, чего в то время было более чем достаточно для хранения скачиваемого контента и другой дополнительной информации. Жёсткий диск всегда был опциональным аксессуаром, но быстро стал необходимостью для геймеров, желавших сохранять свои профили и скачивать контент с Xbox Live. Недостаток заключался в том, что жёсткие диски под брендом Xbox 360 были дорогими. На момент выпуска консоли диск на 20 ГБ стоил $99! Судя по старому руководству по ценам AnandTech за ноябрь 2005 года, за $57 можно было купить для PC жёсткий диск на 80 ГБ. Накопитель для Xbox 360 продавался с большой наценкой.

Моддеры начали исследовать возможность использования сторонних жёстких дисков, чтобы задёшево получить большой объём хранилища. К сожалению, вскоре они выяснили, что так просто эту проблему не решить.

Самый популярный вопрос о моём эмуляторе Windows retrowin32 (после «Зачем вообще это нужно?») — это вопрос о том, как он работает. Сегодня ответ кажется мне очевидным, но прежде чем я разобрался, он представлял для меня огромную загадку. Поэтому я постараюсь объяснить так, чтобы вам тоже стало понятно.

Обычно я запускаю большинство программ на своём ноутбуке с Windows 10, нажимая клавишу <Win>, после чего ввожу несколько букв имени программы, а затем жму Enter. На моём мощном ноутбуке (SSD и 32 ГБ ОЗУ) этот процесс обычно занимает лишь время, необходимое мне для ввода символов, то есть считанные доли секунды.

Обычно.

Однако иногда он занимает больше, намного больше. Порядка десятков секунд. Торможения непредсказуемы, но недавно мне удалось записать трассировку Event Tracing for Windows (ETW) одной из таких задержек. При помощи людей в Twitter я смог проанализировать трассировку и понять, почему на запуск «Блокнота» требуется примерно минута.

Прежде чем приступать к описанию анализа, мне нужно сделать два заявления: 1) у меня есть достаточное понимание проблемы, но нет решения, и 2) если вы наблюдаете аналогичные симптомы, это не значит, что их причина та же, но я дам советы о том, как понять, в ней ли дело.

Формат данных YAML чрезвычайно усложнён. Он задумывался как удобный для человека, но в стремлении к этой цели сложность настолько увеличилась, что, по моему мнению, его разработчики достигли противоположного результата. В YAML есть куча возможностей выстрелить себе в ногу, а его дружелюбие обманчиво. В этом посте я хочу продемонстрировать это на примере.

Данный пост является нытьём и он более субъективен, чем мои обычные статьи.

Да

Десятки лет мы задавались вопросом: «Запустится ли на этом устройстве Doom?». Теперь мы наконец можем задать вопрос иначе: «Запустится ли этот код в Doom?»

В статье я продемонстрирую, что в Doom можно запускать любые конечные вычисления, если не учитывать ограничения размеров уровня. Я не доказал, что Doom полон по Тьюрингу (см. ниже).

Система отлично работает с «ванильным» релизом Doom 2 (v1.9) для MS-DOS. Никаких модов и тому подобного не требуется!

Я люблю подобные проекты. Меня вдохновляют эзотерические машины в других играх, например, в Minecraft и RollerCoaster Tycoon.

В 2020 году Adobe прибила Flash Player, но я не захотел, чтобы мои Flash-игры пропали навечно.

С разными промежутками я делал игры всю свою жизнь, но людям особенно нравилась серия Hapland, поэтому я решил, что неплохо было бы исправить их для релиза в Steam. Можно нарисовать графику получше, повысить частоту кадров и разрешение, а может, и добавить новых секретов и тому подобного.


Hapland 2

Проблема в том, что игры Hapland по большей части созданы на Flash. Графика нарисована во Flash, код написан во Flash, все анимации выполнены в таймлайне Flash. Технология Flash стала их плотью.

Как же мне их улучшить?

Github Copilot оказался для меня невероятно полезным. Часто он может волшебным образом читать мои мысли и давать полезные рекомендации. Больше всего меня удивила его способность верно «угадывать» функции/переменные по соседнему коду, в том числе и из других файлов. Это может происходить только в том случае, если расширение copilot отправляет ценную информацию из соседнего кода в модель Codex. Мне стало любопытно, как это работает, поэтому я решил изучить исходный код.

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