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

unsigned long long BasicRandGenerator() {
    unsigned long long randomVariable;
    // some magic here
    ...
    return randomVariable;
}

С дискретными величинами все интуитивно понятнее. Функция распределения дискретной случайной величины:


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

Распределение Бернулли

1. Вступление

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

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

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

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

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

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

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

Но если для нас действительно важно качество кода, который пишут люди, работающие вместе с нами, то попробовать все же стоит!

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

Работа посвящена погрешностям округления, возникающим при вычислениях у чисел с плавающей запятой. Здесь будут кратко рассмотрены следующие темы: «Представление вещественных чисел», «Способы нахождения погрешностей округления у чисел с плавающей запятой» и будет приведен пример компенсации погрешностей округления.

В данной работе примеры приведены на языке програмиирования C.

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

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

Эта статья адресована тем, кто имеет отношение к разработке программного продукта. Понимание принципов управление процессом разработки не менее важно, чем фактические знания технологий программирования. Статья не адресована только тем, кто хочет стать или работает руководителем проекта (Project Manager), Понимание принципов управления принесет пользу на любой должности и в любой команде.

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

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

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

А заниматься мы будем механикой. Именно решение задач механики и побудило меня разбираться с тензорным исчислением. И поговорим мы об уравнениях Лагранжа 2 рода, которые применяются для анализа движения сложных механических систем. Эти уравнения имеют вид, хорошо известный большинству специалистов в данной области


где s — число степеней свободы механической системы; — обобщенная координата; — кинетическая энергия механической системы; — обобщенная сила.

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

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

Что же, начнем!

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

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

Несказанно рад, что читателям понравилась предыдущая статья. Сразу сделаю оговорку — просто рассказать о таком ёмком понятии как тензор не получится — велик объем информации. Могу обещать, что к концу цикла мозаика сложится.

А в прошлый раз мы остановились на том, что рассмотрев представление вектора в косоугольном базисе, и определив, что он представляется двумя разными (ковариантными и контравариантными) наборами координат, получили общие выражения для скалярного произведения, учитывающие изменение метрики пространства. Таким образом, мы весьма осторожно подошли к понятию тензора

Тензор — математический объект, не изменяющийся при изменении системы координат, представленный набором >своих компонент и правилом преобразования компонент при смене базиса.

Скалярное произведение — это хорошо. Но как же быть с остальными операциями? Как они связываются с геометрией пространства и представимы ли в тензорном виде? Разумеется представимы, ведь векторы — это… тензоры! И скаляры — это тоже тензоры. Привычные нам математические объекты лишь частные примеры более общего понятия, коим является тензор.

Вот об этом мы и поговорим под катом.

Содержание

1. Что такое тензор и для чего он нужен?
2. Векторные и тензорные операции. Ранги тензоров
3. Криволинейные координаты
4. Динамика точки в тензорном изложении
5. Действия над тензорами и некоторые другие теоретические вопросы
6. Кинематика свободного твердого тела. Природа угловой скорости
7. Конечный поворот твердого тела. Свойства тензора поворота и способ его вычисления
8. О свертках тензора Леви-Чивиты
9. Вывод тензора угловой скорости через параметры конечного поворота. Применяем голову и Maxima
10. Получаем вектор угловой скорости. Работаем над недочетами
11. Ускорение точки тела при свободном движении. Угловое ускорение твердого тела
12. Параметры Родрига-Гамильтона в кинематике твердого тела
13. СКА Maxima в задачах преобразования тензорных выражений. Угловые скорость и ускорения в параметрах Родрига-Гамильтона
14. Нестандартное введение в динамику твердого тела
15. Движение несвободного твердого тела
16. Свойства тензора инерции твердого тела
17. Зарисовка о гайке Джанибекова
18. Математическое моделирование эффекта Джанибекова

Введение

Это было очень давно, когда я учился классе в десятом. Среди довольно скудного в научном плане фонда районной библиотеки мне попалась книга — Угаров В. А. «Специальная теория относительности». Эта тема интересовала меня в то время, но информации школьных учебников и справочников было явно недостаточно.

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

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

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

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

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

Конечно, ответы на эти вопросы зависят от конкретного приложения, предъявляемых к нему требований и накладываемых ограничений, поэтому универсальный ответ найти, по всей видимости, невозможно. В этой статье мы расскажем, как мы искали свои ответы на эти вопросы в процессе разработки мобильного клиента Parallels Access для iOS и Android, какие архитектурные решения были приняты и что в итоге получилось.

Хочу сразу предупредить, что букв в этом посте много, но дробить тему на куски не хотелось. Поэтому запаситесь терпением.

Год назад я закончил Московский Авиационный Институт и получил квалификацию «Инженер». Но поскольку к тому времени я уже год отработал программистом и знал, что в этой области буду работать и в дальнейшем, получение «корочки» не стало для меня чем-то переломным, в отличие от моих многих одногруппников. Знания, полученные на 4-5 курсах, казались мне довольно интересными и расширяющими кругозор, но не слишком полезными для работы программистом. Однако есть несколько тем, которые мне помогли и в работе. Про одну из них я и хочу рассказать, и имя ей — методы наведения летательного аппарата.

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

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

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

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

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

Этот пост является вольным переводом ответа, который Mark Eichenlaub дал на вопрос What's an intuitive way to understand entropy?, заданный на сайте Quora

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

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

Осторожно: статья может долго грузиться — много картинок.
Автор: Михаил Антоненко.

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

Исследование, проведенное Software Engineering Institute, показывает, что программисты делают 15-20 распространенных ошибок. Добавив такие ошибки в чеклист, вы можете быть уверены, что заметите их в момент появления и поможете от них избавиться надолго.

Чтобы вам было от чего отталкиваться, вот вам список типичных пунктов: