На этот раз я добрался до бинауральных записей, в частности, ритмов или т.н. биений (как наиболее предрасположенных к мифологизации). Тема интереснейшая, сравнительно хорошо изученная в психоакустике и нейрофизиологии и при этом ставшая основой многочисленных псевдонаучных спекуляций.



Ещё каких-то 4-5 лет назад рунет спасали от пандемии аудионаркотиков, которые ушлые псевдо барыги сбывали доверчивым торчкам-аудиофилам через многочисленные лендинги. До этого, в начале нулевых, люди, читавшие Кастанеду и Ошо, тоннами закупали волшебные компакт диски с одухотворенными и изменяющими сознание песнопениями. Сегодня ситуация не слишком отличается. Гуру, пророки и прочие великие сенсеи из хиреющего new age сообщества выкладывают на ютуб каналы всё те же волшебные записи, обещая при прослушивании одновременное исцеление от всего. Во всех перечисленных случаях распространители аудио счастья в качестве главного “волшебного”, “действенного” и “активного” ингредиента называют наличие бинауральных биений.

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

«Есть запахи, которые вы не можете ощущать, длины волн света, которые вы не видите, звуки, которые вы не можете услышать,… есть мысли, о которых вы не можете думать.»

Привет, Хабр.
Помните офигенную статью «Вы и ваша работа» (+219, 1928 в закладки, 328k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Давайте ее переведем, ведь мужик дело говорит.

Это книга не просто про ИТ, это книга про стиль мышления невероятно крутых людей. «Это не просто заряд положительного мышления; в ней описаны условия, которые увеличивают шансы сделать великую работу.»

Кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru

Глава 24. Квантовая механика

(за перевод спасибо Нате Блянкинштейн)

Большинство физиков в настоящее время считают, что у них есть базовое описание Вселенной [хотя в настоящее время они признают, что 90-99% Вселенной находится в форме «темной материи», о которой они не знают ничего кроме того, что она испытывает гравитацию]. Вы должны понимать, что во всей науке есть только описания того, как что-то происходит, и ничего о том, почему это происходит. Ньютон дал нам формулу, выражающую как работает гравитация, и он не делал никаких гипотез ни о том, чем она является, ни через какую среду она работает, не говоря уже о том, почему она работает. На самом деле он даже не верил в «дальнодействие».

Причины обсуждать квантовую механику, КМ, такие:

1. это фундаментальная физика,
2. она имеет много неожиданных интеллектуальных следствий и
3. дает ряд моделей для работы.

В конце XIX — начале XX века физика столкнулась с рядом проблем. Среди них были следующие:

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

Как сказано в Википедии:

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

Будьте осторожны

• Шаблоны проектирования — не «серебряная пуля».
• Не пытайтесь внедрять их принудительно, последствия могут быть негативными. Помните, что шаблоны — это способы решения, а не поиска проблем. Так что не перемудрите.
• Если применять их правильно и в нужных местах, они могут оказаться спасением. В противном случае у вас будет ещё больше проблем.

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

Здравствуйте. Сегодня речь пойдёт про Conan — современный менеджер зависимостей для C/C++. Если Вы уже активно работаете с ним, то навряд ли найдёте что-нибудь новое для себя. Иначе — прошу под кат.

Для начала немного несуществующих деревень и сёл

Сальтолово
Ничичи
Каверная Голяна
Придориусловка
Старотипенки
Кюканово
Кутюшевка
Верхний Стед
Сабаревка
Зеленокировка
Хадонские Выселки
Старый Куля
Октяга
Ржиново
Черемошно
Голодионово
Александрово-Полейково
Подлопаново
Малое Сусовое
Горы-Чусалы
Чубравяково

---

Зачем и почему

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

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

В качестве нейросети я решил воспользоваться torch-rnn, которую достаточно легко установить и настроить. Список городов и сел я нашел тут (можно скачать все в формате csv). С csv пришлось немного повозиться, чтобы привести ее к utf-8, после чего я запихнул ее в нейросеть и оставил на пару часов. Когда тренировка модели закончилась я взял небольшой сампл и получил следующий результат:

Ключевое слово mutable относится к малоизвестным уголкам языка С++. В то же время оно может быть очень полезным, или даже необходимым в случае, если вы хотите строго придерживаться const-корректности вашего кода или писать лямбда-функции, способные изменять своё состояние.

Пару дней назад Eric Smolikowski написал в своём твиттере:

«Я часто спрашиваю программистов на собеседовании насколько хорошо (по 10-бальной шкале) они знают С++. Обычно они отвечают 8 или 9. И тогда я спрашиваю что такое „mutable“. Они не знают. :)»

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

Часть 1
Часть 2
Часть 3

Люди иногда спрашивают, почему код, скомпиливанный в LLVM иногда генерирует сигналы SIGTRAP, когда оптимизация была включена. Покопавшись, они обнаруживают, что Clang сгенерировал инструкцию «ud2» (подразумевается код X86) — то же, что генерируется __builtin_trap(). В этой статье рассматривается несколько вопросов, касающихся неопределённого поведения кода на C и того, как LLVM его обрабатывает.


В этой статье (первой из трёх) мы попытаемся объяснить некоторые из этих вопросов, чтобы вы могли лучше понять связанные с ними компромиссы и сложности, и возможно, изучить немного больше тёмные стороны С. Мы выясним, что C не является «высокоуровневым ассемблером», как многие опытные программисты на C (особенно те, кто сфокусирован на низком уровне) предпочитают думать, и что C++ и Objective-C напрямую унаследовали множество таких проблем.

Необходимое предисловие: я решил попробовать современный формат несения света в массы и пробую стримить на YouTube про deep learning.

В частности, в какой-то момент меня попросили рассказать про attention, а для этого нужно рассказать и про машинный перевод, и про sequence to sequence, и про применение к картинкам, итд итп. В итоге получился вот такой стрим на час:

Я так понял по другим постам, что c видео принято постить его транскрипт. Давайте я лучше вместо этого расскажу про то, чего в видео нет — про новую архитектуру нейросетей для работы с последовательностями, основанную на attention. А если нужен будет дополнительный бэкграунд про машинный перевод, текущие подходы, откуда вообще взялся attention, итд итп, вы посмотрите видео, хорошо?

Новая архитектура называется Transformer, была разработана в Гугле, описана в статье Attention Is All You Need (arxiv) и про нее есть пост на Google Research Blog (не очень детальный, зато с картинками).

Поехали.

Статья предназначена для тех, кто только собирается сесть на велосипед и тех, кто ездит, но не очень много, в своё удовольствие, чтобы просто размяться или для перемещения на дачу, рыбалку, работу.

Тип велосипеда

И первый вопрос, который возникает: велосипед какой компоновки выбрать? Обычно покупают примерно такого плана, то есть, так называемые, горные велосипеды или шоссейные:


Но всегда ли такой выбор будет правильным?

«Почему ж всё так плохо?» — каждый раз я задаюсь этим вопросом, когда приходится иметь дело с очередным кодом, продуктом или API, созданными для внутренних нужд в непрофильной организации.

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

И деньги ничего не решают: ужасный код и ужасные продукты пишут как маленькие бедные ВУЗы, у которых денег хватает только на рабский труд аспирантов, так и крупные и богатые компании, включая IT-компании, включая зарубежные: несколько раз сталкивался с кодом, который писали зарубежные подрядчики и каждый раз от него хотелось рыдать и биться головой об стену.

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

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

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