«Глубина!» Здесь водятся акулы и спруты. Здесь тихо — и давит, давит, давит бесконечное пространство, которого на самом деле нет.
В общем-то, она добрая, глубина. По-своему, конечно. Она принимает любого. Чтобы нырнуть, нужно немного сил. Чтобы достичь дна и вернуться — куда больше. В первую очередь надо помнить — глубина мертва без нас. Надо и верить в неё, и не верить.
Иначе настанет день, когда не удастся вынырнуть. — С. Лукьяненко, «Лабиринт отражений»

Было дело, как-то после школы приятель потащил меня в компьютерный клуб, куда привезли шлем виртуальной реальности. Напялить его на голову и побродить 15 минут в Duke Nukem 3D стоило каких-то бешеных денег, наверное, как 10 часов игры на обычном компе в клубе.
Мой приятель одел шлем, но секунд через тридцать он заорал и сорвал его с головы. В тот день я так и не осмелился (или денег не хватило) попробовать новинку. Прошло 20 лет.

Google, Facebook, Samsung, Valve, HTC, Sony, Microsoft, NASA — все уделяют пристальное внимание виртуальности. Ждем хитрого хода от Apple.

Я тут подсуетился и сделал подборку полезных материалов, хочу обратиться к разработчикам, кто уже имел опыт разработки игр/софта для ВР, поделитесь впечатлениями.

Пару недель я разбирался со всякими «реальностями» (Бодрияр со своей гиперреальностью отдыхает), с историей шлемов виртуальной реальности и с философской базой (привет Лему, Кастанеде, Бартлу и Дацюку). То, что накопал, постарался законспектировать и поделиться с хабрачитателями. И стартануть флэшмоб по переводу книги Ричарда Бартла «Дизайн виртуальных миров».

«Пусть она оставалась доступной не всем, но интеллектуальная элита присягнула на верность новой империи. Глубине»

Статья предназначается для всех любителей старой-доброй Total Annihilation и ее открытой реализации в виде SpringRTS + Balanced Annihilation.

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

Итак, суть виджета (т.е. расширения) — сообщить игроку в той или иной форме о том, что т.н. воздушный экран, состоящий из множества самолетов, выполняющих команду «патруль», атакован врагом с земли. Обычно такие атаки в разгаре битвы (8 на 8 игроков) не очень заметны и можно легко прохлопать, как противник таким образом уничтожит до 70% самолетов, если отвлечься на что-то сиюминутное.

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

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

Данная статья посвящена работе по исследованию возможности обучить простейшую (относительно) нейронную сеть «слушать» музыку и отличать «хорошую» по мнению слушателя от «плохой».

Цель

Научить нейронную сеть отличать «плохую» музыку от «хорошей» или показать, что нейронная сеть на это неспособна (данная конкретная ее реализация).

Перевод поста Джона Маклуна (Jon McLoone) "10 Tips for Writing Fast Mathematica Code".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе.

---

Пост Джона Маклуна рассказывает о распространенных приемах ускорения кода, написанного на языке Wolfram Language. Для тех, кто заинтересуется этим вопросом мы рекомендуем ознакомиться с видео «Оптимизация кода в Wolfram Mathematica», из которого вы подробно и на множестве интересных примеров узнаете о приемах оптимизации кода, как рассмотренных в статье (но более детально), так и других.

---

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

1. Используйте числа с плавающей точкой, и переходите к ним на как можно более ранней стадии.

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

У большинства вычислительных программных систем нет такого понятия, как точная арифметика — для них 1/3 это то же самое, что и 0,33333333333333. Это различие может играть большую роль, когда вы сталкиваетесь со сложными и неустойчивыми задачами, однако для большинства задач числа с плавающей точкой вполне удовлетворяют нуждам, и что важно — вычисления с ними проходят значительно быстрее. В Mathematica любое число с точкой и с менее чем 16 цифрами автоматически обрабатывается с машинной точностью, потому всегда следует использовать десятичную точку, если в данной задаче скорость важнее точности (например, ввести треть как 1./3.). Вот простой пример, где работа с числами с плавающей точкой проходит почти в 50,6 раза быстрее, чем при работе с точными числами, которые лишь затем будут переведены в числа с плавающей точкой. И в этом случае получается такой же результат.

Почему формальное определение цвета то ли есть, то ли нет, и связано ли это с тем, что его дал тот самый Шрёдингер? Что имел в виду Вейнберг, когда назвал свою революционную статью «Геометрия цветов»? Почему у цветового треугольника два угла, хотя интуитивно кажется, что должен быть один? Почему обычный детский рисунок показывает, что у автора всё в порядке с цветовосприятием, и зачем художник-академист всю жизнь учится его отключать? Почему в цветовом пространстве находятся кластеры, но они не находятся? Почему любая женщина знает о явлении метамерии окрасок, а ученые всё время забывают? Сколько должно быть цветовых каналов у хорошего фотоаппарата? А у монитора? А почему ответ разный? А красок у принтера?

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



Лектор — Дмитрий Николаев, заведующий сектором зрительных систем в Институте проблем передачи информации им. А.А. Харкевича РАН. Кандидат физико-математических наук, защитил диссертацию на тему «Алгоритмы цветовой сегментации, применимые в условиях сложного освещения сцены».

Вот некое простое значение:


И мы знаем, как к нему можно применить функцию:


Элементарно. Так что теперь усложним задание — пусть наше значение имеет контекст. Пока что вы можете думать о контексте просто как о ящике, куда можно положить значение:


Теперь, когда вы примените функцию к этому значению, результаты вы будете получать разные — в зависимости от контекста. Это основная идея, на которой базируются функторы, аппликативные функторы, монады, стрелки и т.п. Тип данных Maybe определяет два связанных контекста:

data Maybe a = Nothing | Just a

Позже мы увидим разницу в поведении функции для Just a против Nothing. Но сначала поговорим о функторах!

Говорят, что идеи ценятся дороже любых драгоценностей и предметов искусства и при грамотном использовании могут принести миллионы долларов. Говорят, что если к вам в голову пришла интересная идея, то её нельзя никому рассказывать, а надо найти богатого инвестора и продать идею ему за большие деньги. Говорят, что идею надо обязательно запатентовать, иначе богатые инвесторы украдут идею и не заплатят денег. Говорят, что те кто так сделал — сейчас сказочно богаты, купили себе остров и живут там как в сказке. Говорят… А кто говорит-то? Да все вокруг! Друзья, коллеги, знакомые, родственники. А так ли это на самом деле?