Введение

Numenta NuPIC — открытая реализация алгоритмов, моделирующих процессы запоминания информации человеком, происходящие в неокортексе. Исходные коды NuPIC на github

В двух словах, назначение NuPIC можно описать как «фиговина, выявляющая, запоминающая и прогнозирующая пространственные и временные закономерности в данных». Именно этим большую часть времени занимается человеческий мозг — запоминает, обобщает и прогнозирует. Очень хорошее описание этих процессов можно найти в книге Джеффа Хокинса «On Intelligence» (есть русский перевод книги под названием «Об интеллекте»).

На сайте Numenta есть подробный документ, детально описывающий алгоритмы и принципы работы, а также несколько видео.

Где-то год назад я опубликовал цикл лекций («Логика мышления») «Искусственный интеллект как совокупность вопросов» . За время, прошедшее с тех пор, удалось достаточно существенно продвинуться вперед.
На днях мне довелось выступать на семинаре по ИИ, который в Санкт-Петербурге проводит Алексей Потапов, за что ему глубокий респект. Доклад был о природе обобщения, что это за задача, как мозг реализует обобщение во всех его проявлениях и примеры обобщения, касающиеся зрительной системы человека. Так получилось, что в основном разговор шел о тех разработках, на которых я сосредоточен последний год. Так что, если кому-то, кто смотрел «Логику мышления» интересно проследить в какую сторону идет развитие моего направления, то это можно сделать по записи этого выступления.

Я хотел бы поделиться нашим опытом использования Go в течение двух лет в продакшне Iron.io. Мы одна из первых компаний, ставших использовать Go (golang) в высоконагруженных сервисах. Когда в Iron.io было принято решение об использовании этого языка, мы не знали, чего ожидать в долгосрочной перспективе, но до сих пор все идет отлично.

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

Вооруженные жидким азотом оверклокеры неоднократно показывали, что современные чипы могут стабильно работать на частотах в разы выше номинальных, обеспечивая соответствующий рост производительности. Тем не менее, прогресс в области «гонки гигагерц» остановился давно и надежно. Первый «Pentium 4» с частотой больше 3 ГГц появился в далеком 2002 году, почти 10 лет назад. За прошедшие годы нормы техпроцессов уменьшились со 180 до 32 нм, но даже это не позволило существенно поднять штатные рабочие частоты. Все упирается в огромное тепловыделение элементов цифровой логики.

В основе «проблемы тепловыделения» лежит глубокая связь между информационной и термодинамической энтропией, а также второе начало термодинамики, запрещающее уменьшение общей энтропии замкнутой системы. Любое вычисление, уменьшающее энтропию информационную, обязано приводить к увеличению энтропии термодинамической, то есть к выделению тепла. Рольф Ландауэр в 1961 году показал [pdf], что уничтожение одного бита информации должно приводить к выделению не менее k∙T∙ln 2 джоулей энергии, где k – постоянная Больцмана и T – температура системы. Само по себе эта энергия невелика: для T=300K она составляет всего 0.017 эВ на бит, но в пересчете на процессор в целом суммарная энергия вырастает уже до величин порядка одного Джоуля за каждую секунду работы, то есть порядка одного Ватта [Компьютерра №538]. На практике этот теоретический минимум умножается на ненулевое сопротивление и прочие неидеальности реальных полупроводников. В результате мы получаем процессоры, которые по тепловыделению обгоняют утюги.

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

Некриптографические хеш-функции

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

Критерии, которые важны для некриптографических хеш-функций:

В прошлый раз я рассказывал о теореме Байеса и приводил простой пример – наивный байесовский классификатор. В этот раз мы перейдём к более сложной теме, которая развивает и продолжает дело наивного байеса: мы научимся выделять темы при помощи модели LDA (latent Dirichlet allocation), а также применим это к рекомендательным системам.

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

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

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

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

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

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

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

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

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

Каждый год 31 декабря David Eppstein публикует обзор препринтов за прошедший год, посвященных структурам данных и алгоритмам, опубликованным на arxiv.org. По ссылкам можно познакомиться с материалами за 2010 и 2011 (мой перевод) годы.

Раздел cs.DS развивается хорошими темпами: в этом году появилось 935 препринтов по алгоритмам и структурам данных, в то время как за 2011 их было 798. Раздел пока не дотягивает до сотни в месяц, хотя в июле (98 препринтов) этот порог был очень близок.

Это мой личный список из десятка препринтов, которые кажутся мне особенно интересными. Как обычно, я не вношу в него мои собственные работы и некоторые другие, о которых я писал раньше. Кроме того, здесь нет результатов (например, более быстрый алгоритм нахождения максимального потока), не появлявшихся на arxiv.org.

Вот они, в хронологическом порядке:

В пятничном номере NY Times опубликована статья о значительных успехах, который демонстрируют в последние годы разработчики алгоритмов для самообучаемых нейросетей. В глубоких структурах есть несколько скрытых слоёв, которые традиционно тяжело было обучать. Но всё изменилось с использованием стека из машин Больцмана (RBM) для предварительной тренировки. После этого можно удобно перенастраивать веса, применяя метод обратного распространения ошибки (backpropagation). Плюс появление быстрых GPU — всё это привело к существенному прогрессу, который мы наблюдаем в последние годы.

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

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

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

По результатам исследованиям работы программистов около 20% времени тратиться на непосредственное написание кода и около 80% времени — на просмотр старого, его анализ. Исходя из данной предпосылки текстовый редактор в первую очередь должен предоставить удобные средства навигации по коду. Большая часть описанных фич как раз имеет дело с навигацией и анализом.

В данной статье я постараюсь продемонстрировать максимум удобных в ежедневном применении возможностей редактора Emacs для языка Python, и более конкретно для редактирования Django проектов.

Как говорится в пословице: «обещанного три года ждут». Хотя три года и не прошло, но уже изрядно много с моей предыдущей статьи «Emacs для начинающих: введение». Я не буду «растекаться мысью по древу» а постараюсь максимально кратко показать как работают различные фичи Emacs в применении к Python.

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

Сразу предупрежу, что на API 15 описанный способ не работает, там маркет приложения не скачивает, хотя и ставится.

Сначала краткое описание процедуры:

• создаём виртуальный девайс на основе Google API образа;
• запускаем эмулятор девайса шаманским образом;
• удаляем «лишние» пакеты;
• достаём пакет с маркетом из имеющегося телефона через USB-кабель;
• закачиваем пакет с маркетом;
• финальное шаманство.

Все происходит в линуксе, но в других операционках всё абсолютно так же.

Здравствуйте.

В контексте анализа данных из твиттера возникла задача обработки хештегов. Нужно было взять хештег и разбить его на отдельные слова (#habratopic => habra topic). Задача казалась примитивной, но, получается, я ее недооценил. Пришлось перебрать несколько алгоритмов пока не было найдено то, что надо.

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

Цель статьи рассказать о своем поиске «идеального» редактора для python кода, о том почему выбрал emacs и кратко о том как я его (emacs) настроил для работы с python.

Небольшая предистория: Разработкой на python я занимаюсь уже более двух лет и все это время пытался подобрать оптимальный редактор. Что я только не использовал за это время — mcedit, nano, gedit, netbeans, eclipse, а также некоторые другие платные варианты (демо версии). Но всегда чего то нехватало, где то автокомплита, где то подсветки, где то банально неудобно. Какой то период (около 10 месяцев) использовал Eclipse, но его прожорливость в ресурсах, зависания доводили до белого каления. Когда ошибки eclipse мне окончательно надоели, я начал поиски такого редактора который стал бы отличным помошником в работе.
Вооружившись google начал искать «идеальный» редактор.