Машины Тьюринга, Поста, Минского, алгоритмы Маркова, рекурсивные функции Клини были придуманы в первой половине двадцатого века в результате попыток формализовать понятие алгоритма. Эти математические модели до сих пор успешно применяются для решения задач разрешимости и алгоритмической сложности, но бесполезны для моделирования поведения сетевых протоколов или компонентов операционной системы. В докладе представлены некоторые современные подходы к моделированию вычислений, которые используются в индустрии при разработке сложных информационных систем.



Лекцию в марте прошлого года прочитал на факультете компьютерных наук Ростислав Яворский, доцент департамента анализа данных и искусственного интеллекта. На факультете Ростислав Эдуардович ведет курсы «Введение в программирование», «Компьютерная алгебра», «Неклассические логики и представление знаний».

Привет. Как и планировалось в прошлом посте об ограниченных машинах Больцмана, в этом будет рассмотрено применение RBM для предобучения обыкновенной многослойной сети прямого распространения. Такая сеть обычно обучается алгоритмом обратного распространения ошибки, который зависит от многих параметров, и пока не существует точного алгоритма выбора этих самых параметров обучения, как и оптимальной архитектуры сети. Разработано множество эвристик, позволяющих сократить пространство поиска, а также методик оценки качества выбранных параметров (например, кросс-валидация). Мало того, оказывается, и сам алгоритм обратного распространения не так уж хорош. Хотя Румельхарт, Хинтон и Вильямс показали сходимость алгоритма обратного распространения (тут еще более математическое доказательство сходимости), но есть небольшой нюанс: алгоритм сходится при бесконечно малых изменениях весов (т.е. при скорости обучения, стремящейся к нулю). И даже это не все. Как правило, этим алгоритмом обучают небольшие сети с одним или двумя скрытыми слоями из-за того, что эффект обучения не доходит до дальних слоев. Далее мы поговорим подробнее о том, почему же не доходит, и применим технику инициализации весов с помощью обученной RBM, которую разработал Джеффри Хинтон.

Предисловие

Об этом руководстве

Добро пожаловать в первую из четырех частей обучающего руководства по основам Linux, разработанного чтобы подготовить вас к сдаче экзамена Linux Professional Institute 101. В нем вы познакомитесь с bash (стандартной оболочкой командного интерпретатора в Linux), узнаете о большинстве возможностей таких стандартных команд Linux, как ls, cp и mv, разберетесь в инодах, жестких и символьных ссылках, и многом другом. К концу этого руководства у вас сформируется некий фундамент знаний, и вы будете готовы к изучению основ администрирования Linux. К концу всего курса (8 частей), у вас будет достаточно навыков, чтобы стать системным администратором Linux и пройти сертификацию LPIC Level 1 от Linux Professional Institute, если конечно захотите.

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

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

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

Каждый процесс расходует память и каждое переключение между ними требует дополнительных циклов процессора, а также приводит к вымыванию L-кэшей

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

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

TKGate ( tkgate.org ) — это симулятор цифровых схем на базе Verilog с открытым исходным кодом. Он работает в ОС Linux. Симулятор написан на связке C и Tk/Tcl. Автором проекта является Jeffery P. Hansen (неактивен). Сейчас разработкой занимается наш соотечественник Андрей Скворцов. На прошлой неделе после шестилетнего (!) перерыва в разработке вышла новая версия симулятора TKGate-2.0. Вот так выглядит TKGate:

• Официальный сайт проекта tkgate.org
• Репозиторий проекта на Bitbucket: bitbucket.org/starling13/tkgate/branch/2.0

Под катом более подробный разбор TKGate.

Оглавление

1. Введение (vim_lib)
2. Менеджер плагинов без фатальных недостатков (vim_lib, vim_plugmanager)
3. Уровень проекта и файловая система (vim_prj, nerdtree)
4. Snippets и шаблоны файлов (UltiSnips, vim_template)
5. Компиляция и выполнение чего угодно (vim-quickrun)
6. Работа с Git (vim_git)
7. Деплой (vim_deploy)
8. Тестирование с помощью xUnit (vim_unittest)
9. Библиотека, на которой все держится (vim_lib)
10. Другие полезные плагины

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

• Автоматическое сохранение и восстановление последней сессии проекта так, что после повторного открытия, мы получим редактируемый в прошлый раз файл(ы), с теми же настройками и положением
• Хранение информации о проекте, такой как автор проекта, лицензия, версия и так далее. Все эти данные можно будет добавлять в шаблоны и сниппеты
• Корневой каталог проекта строго определен. Это упростит использования других инструментов, на пример xUnit, дебагеры, генераторы документации и т.д.
• Отдельный, принадлежащий только проекту каталог .vim и файл .vimrc, аналогичный пользовательским версиям. Теперь настройки и плагины проекта будут хранится в нем

Здравствуй, Хабр!


Решил написать статью о своем опыте работы с IR на Cubieboard.

Не так давно заказал себе это замечательное устройство (заказывал специально для будущего домашнего сервера, и, следовательно, использовать на ней только серверную ОCь) Выбор пал на Cubian (http://cubian.org/) в виду того, что строить свой велосипед пока не хочется.

Предполагалось развернуть на кубике nginx, php5, samba, mocd и несколько своих сервисов для управления блоком реле.
В ходе изучения кубика решил попробовать настроить IR на прием команд с пульта от старого TV тюнера, решение в виде lirc развернуть не получилось, стал искать другие решения, ничего доброго не нашел.

Написал свое решение, которым теперь делюсь с вами.

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

Всем привет. Как-то на просторах Интернета мне попался интересный американский проект. Суть проекта в том, что можно выращивать различные агрокультуры, используя не почву, а, так сказать, симбиоз рыб с растениями. Получается замкнутый цикл. Вы кормите и выращиваете рыб, их продукты жизнедеятельности, растворённые в воде, являются питательной средой для растений. А эти растения, получая питательные вещества для роста из воды, очищают её. Весь процесс повторяется по кругу. Данный метод называется «аквапоника».

Здравствуйте, уважаемые хабровчане!

Нашему издательству вновь требуется помощь зала по вопросу издания амбициозной книги.

Эта непростая книга называется «Создание микросервисов», автор — Сэм Ньюмен.

Привздохнув, произнесла:
«Как же долго я спала!»

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

Все примеры относятся к Linux, хотя многие из них справедливы для других *nix систем, я просто взял за основу самую активно развивающуюся ОС, к тому же ту, которая у меня перед глазами и где я могу быстро проверить предлагаемый код.

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

Определения препроцессора (preprocessor definitions) часто используются в С++ проектах для условной компиляции выбранных участков кода, например, платформозависимых и т.п. В этой статье будут рассмотрены, видимо, единственные (но крайне сложные в отладке) грабли, на которые можно наступить при проставлении #define-ов через флаги компилятора.

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

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

Хорошо в плане поддержки JSON живётся программистам на Javascript — по какому-то невероятному стечению обстоятельств там JSON входит в спецификацию самого языка: есть JSON — есть объект. Удобно. Неплохо дело обстоит и в языках, где JSON не входит в сам язык, но поддерживается стандартной библиотекой (Python, Ruby): импортируешь модуль — и готово.

Жизнь программистов на С++ никогда не была особо простой — поддержки JSON у нас нет ни на уровне языка, ни в стандартной библиотеке. И не будет, возможно, никогда. «Тоже мне проблему нашел!» — скажут мне опытные коллеги — «Её там и не должно быть, С++ поставляется без „батареек“. Для решения этой задачи мы...» и вот здесь они разделятся на два лагеря:

1. «Мы используем большой фреймворк (boost, Qt, POCO, другой), который применяется во всех наших проектах и умеет 150 000 разных вещей, в том числе и JSON.»
2. «Мы придерживаемся подхода в котором для каждой задачи применяется своя легковесная библиотека. В частности, для JSON мы уже 150 000 лет назад выбрали отличную библиотеку %JSON_LIB%, которая прекрасно работает.»

Да, всё так и есть. Вот только…





Давайте немного помечтаем.

А что, если бы JSON вошел в стандартную библиотеку нового стандарта С++? Что, если бы он был написан в терминах С++11\14 и без требований обратной совместимости со старыми стандартами языка? Что, если бы синтаксис этого модуля попытались бы сделать максимально приближенным к родному для JSON использованию «а-ля Javascript», но в том же время сохранить дух С++ (эффективность, минимальное потребление памяти, совместимость с STL)? Что, если бы его можно было включить в проект одним инклюдом и не беспокоиться о его сборке и линковке? Как бы это всё выглядело и работало?

И у нас есть ответ на этот вопрос! Давайте посмотрим на JSON-библиотеку для С++ написанную в соответствии со всеми этими принципами, ну и вообще написанной людьми для людей, а не чужими для хищников, как это обычно бывает.

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

Когда известно, что случайная величина y зависит от чего-то (например, от времени или от другой случайной величины x) линейно, т.е. по закону y(x)= Ax+b, то применяется линейная регрессия (так в прошлой статье мы строили зависимость числа регистраций от числа просмотров). Для линейной регрессии коэффициенты A и b вычисляются по известным формулам. В случае регрессии другого вида, например, экспоненциальной, для того чтобы определить неизвестные параметры, необходимо решить соответствующую оптимизационную задачу: а именно, в рамках метода наименьших квадратов (МНК) задачу нахождения минимума суммы квадратов (y(x_i) — y_i)².

Итак, вот данные, которые будем использовать в качестве примера. Пики посещаемости (ряд Views, красный пунктир) приходятся на моменты выхода статей. Второй ряд данных (Regs, с множителем 100) показывает число читателей, выполнивших после прочтения определенное действие (регистрацию и скачивание Mathcad Express – с его помощью, к слову, вы сможете повторить все расчеты этой и предыдущих статей). Все картинки — это скриншоты Mathcad Express, а файл с расчетами вы можете взять здесь.

Сравнительно недавно была статья «Полуавтоматическая регистрация юнит-тестов на чистом С», в которой автор продемонстрировал решение задачи с использованием счётчиков из Boost. Следуя этому же принципу, была предпринята (успешная) попытка повторить данный опыт уже без использования Boost из соображения нелогичности наличия в проекте на C зависимости от Boost, да ещё и в таком небольшом объёме. При этом в тестах присутствовали вспомогательные директивы препроцессора в большом количестве. И всё бы так и осталось, но практически на завершающей стадии был найден альтернативный способ регистрации, который позволяет полностью избавится от дополнительных действий. Это C89-решение для регистрации тестов и чуть более требовательное к системе сборке решение для регистрации наборов тестов.

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

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

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

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

Это первая и основная статья из упомянутого цикла и она представляет собой введение в систему документирования исходных текстов Doxygen, которая на сегодняшний день, по имеющему основания заявлению разработчиков, стала фактически стандартом для документирования программного обеспечения, написанного на языке C++, а также получила пусть и менее широкое распространение и среди ряда других языков.

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

Год назад знакомые попросили сделать меня сайт с динамическим контентом. Тогда о Web я знал чуть больше чем ничего, но попробовать было интересно.

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

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

Фрактальное пламя (или фрактальные искры, англ. fractal flame) – алгоритм, предложенный Скоттом Дрейвсом (Scott Draves) и использующий для построения изображений системы итерируемых функций (СИФ). Благодаря разным значениям seed для генератора псевдослучайных чисел можно получить множество разнообразных «картин». Хотя фрактальность в них просматривается далеко не всегда, результаты получаются очень интересными.

Под катом – краткое описание основных моментов реализации алгоритма.