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

Вниманию читателей «Хабрахабра» представляется перевод статьи Хану Коммалапати и Тома Кристиана об внутреннем устройстве .NET. Существует альтернативный вариант перевода на сайте Microsoft.

В статье рассматривается:

• Системный домен (SystemDomain), Домен общего доступа (SharedDomain) и домен по умолчанию (DefaultDomain)
• Представление объекта и другие особенности организации памяти
• Представление таблицы методов
• Распределение методов

Используемые технологии: .NET Framework, C#

Содержание

1. Домены создаваемые начальным загрузчиком
2. Системный домен
3. Домен общего доступа (разделяемый)
4. Дефолтный домен
5. Загрузчик куч
6. Основы типов
7. Экземпляр объекта
8. Таблица методов
9. Размер базового экземпляра
10. Таблица слотов метода
11. Описатель метода
12. Карта таблиц виртуальных методов интерфейсов и карта интерфейса
13. Виртуальное распределение
14. Статические переменные
15. EEClass
16. Заключение

«Инструкция создания функционального приложения», часть 1.

«Мне кажется, что понимаю функциональное программирование на базовом уровне, и я даже писал простые программы, но как мне создать полноценное приложение, с реальными данными, с обработкой ошибок и прочим?»

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

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

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

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

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

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

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

Предисловие

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

Поддерживаются следующие типы данных:
— Все фундаментальные типы С++
— std::string
— std::vector где T — все что угодно из этого же списка
— Любой перечислимый тип

Привет, Geektimes!

Представляем цикл статей, в котором рассмотрим, как с нуля и без пайки реализовать управляемое из облака недорогое IoT-устройство с огромными потенциалом. За основу возьмем «чистый» микрочип ESP8266, о котором недавно уже писали. Используем свежую DeviceHive-прошивку и напишем простенькое веб-приложение для обращения к cloud-серверу. К микрочипу подключим простое устройство, управлять которым можно будет с помощью пары кликов в браузере.

Перед вами первая статья цикла, из которой мы узнаем, какое именно оборудование нам понадобится.

Совсем недавно состоялся публичный релиз первой версии DeviceHive-прошивки для ESP8266. Цель наших статей — помочь каждому желающему реализовать с помощью DeviceHive собственное IoT-решение максимально дешево, быстро и без лишних сложностей.

Нам понадобится всего пять вещей:

• плата с распаянным ESP8266;
• USB ->UART-переходник;
• источник питания;
• провода;
• сам девайс, который мы хотим подружить с облаком.

Общая стоимость первых четырех пунктов не превысит $ 5. Какое устройство выбрать для экспериментов — решайте сами.

Давайте рассмотрим каждый пункт подробнее.

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

• однопоточный асинхронный;
• многопоточный, создавать по потоку на соединение;
• многопоточный, с пулом потоков на QThreadPool и QRunnable.

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

Программный рендеринг (software rendering) — это процесс построения изображения без помощи GPU. Этот процесс может идти в одном из двух режимов: в реальном времени (вычисление большого числа кадров в секунду — необходимо для интерактивных приложений, например, игр) и в «оффлайн» режиме (при котором время, которое может быть потрачено на вычисление одного кадра, не ограничено настолько строго — вычисления могут длиться часы или даже дни). Я буду рассматривать только режим рендеринга в реальном времени.

У этого подхода существуют как недостатки так и достоинства. Очевидным недостатком является производительность — CPU не в состоянии конкурировать с современными видеокартами в этой области. К достоинствам стоит причислить независимость от видеокарты — именно поэтому он используется как замена аппаратного рендеринга в случаях, когда видеокарта не поддерживает ту или иную возможность (так называемый software fallback). Существуют и проекты, цель которых — полностью заменить аппаратный рендеринг программным, например, WARP, входящий в состав Direct3D 11.

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

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

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

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

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

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

• Правило заполнения пикселей (filling convention)
• Точность
• Коррекция перспективы при интерполяции аттрибутов (perspective-correct interpolation)

Я рассмотрю три подхода к растеризации:

• «стандартный» алгоритм, использующий наклон граней
• целый ряд алгоритмов, основанных на использовании уравнений граней полигона (traversal-алгоритмы)
• алгоритм растеризации в однородных координатах

Так же в конце будет ссылка на проект, который является примером реализации, оттуда же будут и примеры кода.

Я хотел бы рассказать вам об утилите, с которой вы сможете забыть о боли создания документации для Web API. О том как это сделать прошу всех под кат.

Столкнулся с ситуацией, когда мои коллеги для организации локального персистентного key-value хранилища используют SQLite, MemcacheDB, Redis игнорируя встраиваемые хранилища такие как LevelDB, Sophia, HamsterDB и т.д.

Я разбил статью на две части:

1. небольшое введение в api LevelDB;
2. использование LevelDB, для хранения временных рядов.

От переводчика: Джефф Прешинг (Jeff Preshing) — канадский разработчик программного обеспечения, последние 12 лет работающий в Ubisoft Montreal. Он приложил руку к созданию таких известных франшиз как Rainbow Six, Child of Light и Assassin’s Creed. У себя в блоге он часто пишет об интересных аспектах параллельного программирования, особенно применительно к Game Dev. Сегодня я бы хотел представить на суд общественности перевод одной из статей Джеффа.

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

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

В одном из своих проектов мне потребовалось распознавание символов и мой выбор остановился на tesseract ocr. На Хабре уже была подобная статья, но на данный момент она не актуальна, во время установки не получилось в точности повторить инструкции автора. В данной статье рассказывается о процессе установке Tesseract OCR под MinGW.

Содержание

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

Введение

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

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

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

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

Продолжение:
Пишем свой упрощенный OpenGL на Rust — часть 2 (проволочный рендер).
Пишем свой упрощенный OpenGL на Rust — часть 3 (растеризатор)

Наверное, мало кто на хабре не в курсе, что такое Rust — новый язык программирования от Mozilla. Уже сейчас он привлекает много интереса, а недавно наконец вышла первая стабильная версия Rust 1.0, что знаменует собой стабилизацию языковых возможностей. Мне всегда импонировали системные ЯП, а уж идея системного языка, предлагающего безопасность превосходящую языки высокого уровня, заинтересовала еще больше. Захотелось новый язык попробовать в деле и, заодно, интересно провести время, программируя что-нибудь увлекательное. Пока думал, что бы такого на расте написать, вспомнился недавний цикл статей про компьютерную графику, который я лишь бегло просмотрел. А очень интересно было бы попробовать все-таки написать все эти красивости самостоятельно. Вот так и родилась идея этого хобби-проекта, а также данной статьи.

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

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


Here is the Rust, which i hope to get at the end. (игра слов, Rust по-английски «ржавчина»)

Содержание

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

Введение

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

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

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

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

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

Всем привет!

Две недели назад в Москве прошла очередная встреча CodeFreeze. Нашим гостем стал Евгений Кривошеев, признанный российский эксперт в области архитектуры программных систем, консультант из Scrumtrek/Skilltrek. Евгений прочитал офигеннейшую лекцию по архитектуре, как он любит и умеет.



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

• Точки зрения на систему, или Почему мы слепнем при проектировании
• Адресация ключевых рисков, или Гордыня убивает
• Учитываем контекст, или Как не долбиться в закрытую дверь

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