В январе 2017 года команда из Курантовского института математических наук и Facebook AI Research выложила в открытый доступ препринт статьи под названием «Wasserstein GAN».

Основное отличие этой статьи от большинства публикаций предлагающих очередное улучшение для Генеративных Состязательных Сетей заключается в фундаментальной теоретической базе. Авторы не просто демонстрируют очередной набор удачных изображений, порождённых GAN’ами, но и объясняют эффективность данного подхода с точки зрения теории. И в центре этой теории как раз и лежит расстояние Вассерштейна.

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

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

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

Согласно тесту Тьюринга, если что-то плавает как утка, крякает как утка и летает как утка, то это что-то — утка. Но что делать, если при этом она не работает без батареек?

Если в вашем приложении объект пришёл к вам по референсу на базовый класс, но ведёт себя не так, как вы ждёте от базового класса, то у вас в приложении нарушен один из принципов SOLID — Liskov Substitution. Ошибка частая и не сразу заметная.

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

Япония дала миру многие интересные идеи. В области управления вы наверняка вспомните Kanban и Kaizen. Kanban изначально был системой организации конвейерного производства и процессов его снабжения, а затем был подхвачен IT-сообществом и превращён в прекрасный инструмент управления IT-процессами.

Kaizen – философия постоянного улучшения процессов, философия мелких ежедневных изменений к лучшему. Kaizen является одним из необходимых принципов построения Kanban-систем, но и в Scrum есть место для постоянного совершенствования. И это, конечно же, Ретроспектива.

Если бы по телевизору показывали рекламу языка C++, наверняка, в ней бы было что-то вроде:

«С добавлением move-семантики вы получаете бесплатное увеличение производительности за счёт избавления от нецелесообразных операций копирования. Просто перекомпилируйте свой проект новой версией компилятора с поддержкой 11 или 14 стандарта и радуйтесь ускорению работы программы!».

Стоит ли верить такой рекламе?

Одна из главных задач Scrum-мастера – помочь команде разработки стать настоящей командой. Часто «командой» называют просто рабочую группу: людей, собранных вместе для работы над каким-то продуктом или проектом. Команда – тоже группа людей, работающих вместе. Но у неё есть ряд отличий от рабочей группы, и два самых главных из них – синхронизация целей и командная ответственность.

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