Представляю вниманию DIY сканер на базе Android смартфона.

При проектировании и создании сканера, в первую очередь, интересовало сканирование крупных объектов. Минимум – фигура человека в полный рост с точность – хотя бы 1-2 мм.

Данные критерии успешно достигнуты. Успешно сканируются объекты при естественном освещении (без прямого солнечного света). Поле сканирования определяется углом захвата камеры смартфона и расстоянием, на котором лазерный луч сохраняет достаточную для детектирования яркость (днем в помещении). Это фигура человека в полный рост (1.8 метров) с шириной захвата в 1.2 метров.

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

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

Цель статьи – рассказать о тупиковых ветках и проблемах, собранных на пути к созданию окончательной рабочей версии.

Не так давно я возился со своей роботележкой, пытаясь водрузить на нее ANDROID смартфон. Моей, то есть его задачей, было сделать тележку эволюционно продвинутой. Чтобы она, так сказать, чувствовала мир его сенсорами, смотрела его глазом (камерой), слышала микрофоном и ругалась по громкой связи. Ресурсов AVR, понятное дело, на это уже не хватало и поэтому бывший на телеге микроконтроллер переехал на уровень ниже, куда-то в район спинного мозга управлять моторчиками и разными безусловными рефлексами.

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

camera = Camera.open();

Особенно, как вы видите, в тех частях, где я пытался работать с камерой. Это было очень обидно, потому что я прочитал в интернете и усвоил множество уроков работы с андроидом и камерой здесь, здесь, здесь и даже здесь. Там ничего не зачеркивалось. И называлось заурядно Camera API. Все там было просто и логично. Но Google упрямо толкал меня к какому-то Сamera2 API.

Я туда посмотрел и просто опупел от количества разных коллбэков, билдеров, хэндлеров и луперов на каждую строчку демонстрационного кода. Было совершенно непонятно с какой стороны к этому подступиться, если ты обычный любитель, а не android developer. Причем в сети даже на сегодня статей на тему Сamera2 API чуть, хотя вышло это обновление вроде как, аж четыре года назад. Но всё что я нашел, это статью в Хакере в 2016, пост в трех частях от украинских братьев того же года, двойной пост на Хабре в 2017 и статью Understanding Camera2 от японского мегагика Томоаки Имаи. И это я ещё имею в виду какую-то структурированную и оформленную информацию, а не раскиданные в интернете обрывки кода типа, «смотрите, как я могу» и простыни в стиле, «посмотрите код плиз, у меня ничего не работает».

А теперь, если вам всё ещё интересно зачем мне потребовалось пилить свой пост на эту тему
уже в 2019, то добро пожаловать под кат.

Около года назад я опубликовал свою статью Как спастись от «зайцев». Инструкция по борьбе с ультрафиолетом в которой достаточно подробно рассказал про ультрафиолет, его воздействие на ткани человека и способы лучевой защиты. Однажды на досуге я задумался над тем, в какой форме чаще всего приходится сталкиваться с «рукотворным» (т.е. не из спектра Солнца) ультрафиолетом. Вышло, что наиболее популярный УФ — это мягкий УФ и флуоресценция, которую он способен вызывать. Наиболее популярный вариант у моих дружков — это просвечивать друг друга и потом спрашивать у меня, что значит тот или иной цвет пятна на коже, и не грибок ли это. Чтобы раз и навсегда этот вопрос закрыть представляю очередной туториал. На этот раз, по диагностике кожных заболеваний ультрафиолетом лампы Вуда. Так что если интересно, как с помощью «дискотечного ультрафиолета» можно определить наличие чесотки/грибка на ногах/лишая (в том числе у любимого котика), а также про то, как лампа с aliexpress за 5$ может помочь диагностировать рак кожи и бороться с борщевиком — читаем под катом. Только наукоёмкое самоделие, с пожеланием крепкого здоровья в Наступающем 2020 году!
Закинь в закладки, %username% :)

В продолжение своей вчерашней статьи на Geektimes хочу рассказать подробнее про реализацию оцифровки и кодирования звука на микроконтроллере STM32.

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

Прошу под кат.

КДПВ «Ой, всё».

Мало шансов, что сей лонгрид станет живительным источником мудрости интеллектуалам, искушенным в тайнах гадания на картах Карно и познавшим потаенный смысл Третьей Нормальной Формы. Но если вы зачем-то трогали руками arduino, в кладовке пылится паяльник, понимаете, почему у батарейки один плюс, а у С++ два, то вас не смогут оставить равнодушными поистине волшебные и удивительные чудеса. Итак, имею удовольствие рекомендовать вам номера сегодняшнего представления бродячего цирка «Саман с Самшитом»:

• Добавление RAM и ROM в ATtiny13!
• Искусственный интеллект в микропроцессор — про и контра, или спящая красавица — ну она не дура ли?
• Или все таки dura lex sed lex?
• Как добавить ножек в ATtiny13?
• Пару слов о пятом измерении: как впихнуть невпихуемое?
• Распиливание напополам не-девствениц с перемешиванием содержимых половин (с гарантией восстановления).
• Номер «Кормление страждущих» (см. более ранний случай насыщения пяти тысяч человек пятью ячменными хлебами и двумя рыбами).

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

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

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

Для справки: на сайт AUTO.RIA.com, в день добавляется около 100 000 фото.

Датасаентисты давно уже знают и умеют решать подобные задачи, поэтому мы с dimabendera написали эту статью именно для программистов. Если вы не боитесь словосочетания «сверточные сети» и умеете писать «Hello World» на питоне — милости просим под кат…

• Распознавание номеров. Практическое пособие. Часть 1

Продолжаем рассказ о том как распознавать номерные знаки для тех кто умеет писать приложение «hello world» на python-е! В этой части научимся тренировать модели, которые ищут регион заданного объекта, а также узнаем как написать простенькую RNN-сеть, которая будет справляться с чтением номера лучше чем некоторые коммерческие аналоги.
В этой части я расскажу как тренировать Nomeroff Net под Ваши данные, как получить высокое качество распознавания, как настроить поддержку GPU и ускорить все на порядок…

Продолжение поста про интернет-магазины электронных компонентов, инструментов и прочих ардуин.

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).

Продолжаем знакомство с методами многомерной оптимизации.

Далее предложена реализация метода наискорейшего спуска с анализом скорости выполнения, а также имплементация метода Нелдера-Мида средствами языка Julia и C++.

Джефф Хокинс — ветеран Силиконовой долины, посвятивший последнее десятилетие изучению загадок человеческого мозга, организовал встречу с компанией DeepMind — одной из ведущих ИИ-лабораторий в мире.

Ученые из DeepMind, принадлежащей материнской компании Google — холдингу Alphabet, хотят создавать машины, способные делать все, что может делать мозг. Хокинс основал небольшую компанию с одной целью — выяснить, как работает мозг, а затем воссоздать его, исходя из полученных знаний.

Информации по Sphinx не так много, как хотелось бы. Лишняя статья не помешает.
Первые шаги в освоении Sphinx мне помогли сделать статьи Создание ознакомительного поискового движка на Sphinx + php и Пример Sphinx поиска на реальном проекте — магазин автозапчастей Tecdoc Советую начать с них.

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

• Словоформы. Выдача по «винты» и «винтов» должна быть одинаковой.
• Поиск по фрагменту слова.
• Поиск нецелых чисел. Разделитель точка и запятая.
• Буква Ё
• Типичные ошибки. Например «Аммортизатор».
• Синонимы. Регулятор и ESC.
• Язык. mAh и мАч, В и V, AAA латиницей и кириллицей.
• Слово из букв и цифр. 10х15х4, 6000mAh

На одном личном проекте на C++ мне потребовалось получать информацию о типах объектов во время выполнения приложения. В C++ есть встроенный механизм Run-Time Type Information (RTTI), и конечно же первая мысль была использовать именно его, но я решил написать свою реализацию, потому что не хотел тянуть весь встроенный механизм, ведь мне нужна была лишь малая часть его функционала. А еще хотелось попробовать на практике новые возможности C++ 17, с которыми я был не особо знаком.

В этом посте представлю пример работы с парсером libclang на языке Python.

Вкратце: статья будет полезна тем программистам, кто уже заинтересовался релевантным поиском и прочитал статьи по стартовой установке сфинкс поиска, погонял на тестовых примерах и таких же синтетических задачах. Часто эти примеры не дают ответа на вопрос, а как же ощутить реальную пользу от поискового модуля Sphinx в сравнении с другими более простыми вариантами поиска. Примеры кода в статье — на php+smarty, Sphinx 2.0.1-beta, база данных — mysql, исходники и дамп структуры базы выложены отдельным архивом в подвале. В статье описан пример использования таких особенностей сфинкса, как:

• Создание единого конфиг файла для windows development и linux production
• SetMatchMode(SPH_MATCH_EXTENDED2) и почему SPH_MATCH_ANY и другие не подходят для реального поиска
• SetSortMode(SPH_SORT_RELEVANCE), SetFieldWeights — сортировка по релевантности и установка весов для полей индекса
• SetLimits(0,20) — ограничение вывода результатов
• AddQuery, RunQueries — построение мультизапросов
• SetFilter, ResetFilters — добавление фильтрации в мулльтизапросе для ограничения получаемых данных
• Wordforms — использование синонимов и преодоление ограничений для нестандартных словоформ, как «C#»

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

Перевод поста Стивена Вольфрама (Stephen Wolfram) "Mathematical Notation: Past and Future (2000)".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации

---

Содержание

Резюме
Введение
История
Компьютеры
Будущее
Примечания
— Эмпирические законы для математических обозначений
— Печатные обозначения против экранных
— Письменные обозначения
— Шрифты и символы
— Поиск математических формул
— Невизуальные обозначения
— Доказательства
— Отбор символов
— Частотное распределение символов
— Части речи в математической нотации

---

Стенограмма речи, представленной на секции «MathML и математика в сети» первой Международной Конференции MathML в 2000-м году.

---

Резюме

Большинство математических обозначений существуют уже более пятисот лет. Я рассмотрю, как они разрабатывались, что было в античные и средневековые времена, какие обозначения вводили Лейбниц, Эйлер, Пеано и другие, как они получили распространение в 19 и 20 веках. Будет рассмотрен вопрос о схожести математических обозначений с тем, что объединяет обычные человеческие языки. Я расскажу об основных принципах, которые были обнаружены для обычных человеческих языков, какие из них применяются в математических обозначениях и какие нет.

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

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

Традиционная математическая нотация представляет математические объекты, а не математические процессы. Я расскажу о попытках разработать нотацию для алгоритмов, об опыте реализации этого в APL, Mathematica, в программах для автоматических доказательств и других системах.

Обычный язык состоит их строк текста; математическая нотация часто также содержит двумерные структуры. Будет обсуждён вопрос о применении в математической нотации более общих структур и как они соотносятся с пределом познавательных возможностей людей.

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