Trust-region метод (TRM) является одним из самых важных численных методов оптимизации в решении проблем нелинейного программирования (nonlinear programming problems). Метод базируется на определении региона вокруг лучшего решения, в котором квадратичная модель аппроксимирует целевую функцию.

Методы линейного поиска (line search) и методы trust-region генерируют шаги с помощью аппроксимации целевой функции квадратичной моделью, но использую они эту модель по-разному. Линейный поиск использует её для получения направления поиска и дальнейшего нахождения оптимального шага вдоль направления. Trust-region метод определяет область (регион) вокруг текущей итерации, в котором модель достаточно аппроксимирует целевую функцию. В целях повышения эффективности направление и длина шага выбираются одновременно.

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

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

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

Уважаемые читатели, в этой статье я хочу рассказать о таком важном средстве многозадачного программирования среды .NET, как многопоточность. Данная статья содержит начальные сведения, и предназначена для быстрого освоения азов многопоточности на языке C#. Однако не буду разглагольствовать о преимуществах параллельного выполнения задач, и перейду к примеру кода.

Метод BFGS, итерационный метод численной оптимизации, назван в честь его исследователей: Broyden, Fletcher, Goldfarb, Shanno. Относится к классу так называемых квазиньютоновских методов. В отличие от ньютоновских методов в квазиньютоновских не вычисляется напрямую гессиан функции, т.е. нет необходимости находить частные производные второго порядка. Вместо этого гессиан вычисляется приближенно, исходя из сделанных до этого шагов.

Существует несколько модификаций метода:
L-BFGS (ограниченное использование памяти) — используется в случае большого количества неизвестных.
L-BFGS-B — модификация с ограниченным использованием памяти в многомерном кубе.

Метод эффективен и устойчив, поэтому зачастую применяется в функциях оптимизации. Например в SciPy, популярной библиотеки для языка python, в функции optimize по умолчанию применяется BFGS, L-BFGS-B.

Если вы пишете не казуалку под веб и не беспощадный суровый рогалик, без сохранения данных на диск не обойтись.
Как это делается в Unity? Вариантов тут достаточно — есть класс PlayerPrefs в библиотеке, можно сериализовать объекты в XML или бинарники, сохранить в *SQL*, можно, в конце-концов, разработать собственный парсер и формат сохранения.
Рассмотрим поподробнее с первые два варианта, и заодно попробуем сделать меню загрузки-сохранения со скриншотами.

Будем считать, что читающий дальше базовыми навыками обращения с этим движком владеет. Но при этом можно не подозревать о сущестовании в его библиотеке PlayerPrefs, GUI, и ещё в принципе не знать о сериализации. С этим всем и разберёмся.
А чтобы эта заметка не стала слишком уж увлекательной и полезной, ориентирована она самый неактуальный в мобильно/планшетно/онлайновый век вариант — сборку под винду (хотя, конечно, более общих моментов достаточно).

• Кстати, пару недель назад на Хабре была статья, где автор упомянул, что Unity3D проходят в курсе компьютерной графики на кафедре информатики питерского матмеха. Занятный факт, немало говорящий о популярности движка.
  Хотя насколько это в целом хорошая идея — на мой взгляд, тема для дискуссии. Может быть, обсудить это было бы даже интереснее вопросов сериализации =)

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

Несколько лет назад Джоел Коэн сказал мне, что парадокс Браеса может стать хорошей темой для моей колонки в «Computing Science». Я засомневался. Опубликовано уже немало обсуждений этого парадокса, в том числе потрясающие статьи самого Коэна, а также книга Тима Рафгардена (обзор которой я написал для American Scientist). Я не считал, что смогу добавить что-то новое к дискуссии.

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

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

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


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

Дорогие разработчики, вы чувствуете себя неуютно, потому что вы быстро пишете только на восьми языках для трех семейств устройств? Вздрагиваете ли вы, едва заслышав о переходе на очередной фреймворк? Откладывали ли вы любимый проект из-за того, что не могли определить, какая облачная платформа подойдет лучше всего?
Возможно, у вас тоже паралич разработчика. Бойтесь! Это не лечится.

Богатство доступных программистам опций сегодня просто чудовищно. Мы задохнулись под тем, что извергает рог изобилия. Последние несколько лет я зарабатывал на том, что писал на Java, Objective-C, C, C++, Python, Ruby, JavaScript, PHP (прошу прощения) с разными вариантами SQL/баз данных (MySQL, PostgreSQL, MongoDB, BigTable, Redis, Memcached и другими). Нравится ли это мне? Черт побери, нет. По большей части я просто чувствую вину за то, что не делал ничего на Erlang, Clojure, Rust, Go, C#, Scala, Haskell, Julia, Scheme, Swift или OCaml.


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

На данный момент существует много компаний нуждающихся в системах аналитики, но дороговизна и чрезмерная сложность данного ПО в большинстве случаев вынуждает отказаться от идеи построения собственной аналитической системы в пользу простого всем известного экселя. Также дополнительные расходы на обучение сотрудников, поддерживание дорогих систем хранения данных и т.д. И тут на помощь могут прийти Open Source решения — их не так много, но есть очень достойное ПО, одним из которых которых является RapidMiner.

Перевод статьи Джеффа Прешинга (Jeff Preshing) How to Write Your Own C++ Game Engine.

Как написать собственный игровой движок на C++

В последнее время я занят тем, что пишу игровой движок на C++. Я пользуюсь им для создания небольшой мобильной игры Hop Out. Вот ролик, записанный с моего iPhone 6. (Можете включить звук!)

Hop Out — та игра, в которую мне хочется играть самому: ретро-аркада с мультяшной 3D-графикой. Цель игры — перекрасить каждую из платформ, как в Q*Bert.

Hop Out всё ещё в разработке, но движок, который приводит её в действие, начинает принимать зрелые очертания, так что я решил поделиться здесь несколькими советами о разработке движка.

С чего бы кому-то хотеть написать игровой движок? Возможных причин много:

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

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

Книга, что попалась не так давно на глаза, объединяет в себе оба мира: в ней, с одной стороны, описаны интересные в совокупности алгоритмические приемы; результат же работы — настольная игра «Yavalath» на приложенной картинке — был издан и пользовался достаточно широкой для абстрактной игры популярностью.

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

Игровой процесс может быть очень сложной задачей. Некоторые игры, например, «Змеи и лестницы», достаточно прямолинейны, однако такие игры, как SpaceChem и Factorio могут быть невероятно сложной проверкой работы мозга.

Каждой игре, от простой до сложной, очень важно объяснить игроку, как в неё играть. Неважно, бросает ли он кубики или решает сложные математические уравнения — главное, чтобы игрок понимал, как работает игра.

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

В практиктических приложениях ТАУ часто необходимо точно и качественно идентифицировать объект управления. В этой статье речь пойдет об идентификации объекта управления частотным методом. Данный метод применим, когда есть возможность физически протестировать объект управления синусоидальным входным воздействиямем, изменяя частоту в широком диапазоне. Если это условие соблюдено, то результат, как правило, оправдывает самые оптимистичные ожидания.

«Всякие звания (дворянина, купца, мещанина, крестьянина и пр., титулы — княжеские, графские и пр.) и наименование гражданских чинов (тайные, статские и проч. советники) уничтожаются...»

Об уничтожении сословий и гражданских чинов
Декрет ВЦИК и СОВНАРКОМа от 10.11.1917 года, ст. 2

---

Как-то же я обходился без этого раньше...

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

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

Статья посвящена языку ассемблер с учетом актуальных реалий. Представлены преимущества и отличия от ЯВУ, произведено небольшое сравнение компиляторов, скрупулёзно собрано значительное количество лучшей тематической литературы.

Постановка задачи

Это вторая, итоговая статья. Напоминаю цель: есть двигатель постоянного тока. Задача — разработать, собрать и протестировать устройство, позволяющиее реализовать контур управления с заданием тока применительно к этому двигателю. Желаемое время переходного процесса на застопоренном двигателе (без противо-ЭДС) — не более 10мс.

Текст разбит на две статьи:

• 1. Измерение сопротивления и индуктивности двигателя
• 2. Разработка управляющего контура

Напоминаю, как выглядит макет управляющего железа:

Цель поста — в максимально простой форме описать основные этапы разработки с помощью фреймворка LÖVE, на примере классической игры atari-автоматов Asteroids.

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

До настоящего времени в арсенале средств высокоуровневого языка программирования Python отсутствовали модули для численного преобразования передаточных функций элементов САУ из частотной области во временную.

Поскольку функции обратного преобразования Лапласа широко используются при анализе динамических систем контроля измерения и управления, использование Python для указанных целей было весьма затруднительно, поскольку приходилось использовать менее точное обратное Фурье преобразование [1].

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

Работу над модулем ещё в 2007 году начал Fredrik Johansson [2], и, благодаря помощи многих участников проекта, в настоящее время mpmath приобрёл возможности серьёзного математического пакета.