За последние несколько месяцев несколько человек спросили меня, как работает TinEye и как в принципе работает поиск похожих картинок.

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

Давным-давно в далекой-далекой галактике широко использовалась библиотека MFC, в которой у ряда классов были методы, сравнивающие this с нулем. Примерно так:

class CWindow {
    HWND handle;
    HWND GetSafeHandle() const
    {
         return this == 0 ? 0 : handle;
    }
};

«Это же не имеет смысла» – возразит читатель. Еще как «имеет»: этот код «позволяет» вызывать метод GetSafeHandle() через нулевой указатель CWindow*. Такой прием время от времени используется в разных проектах. Рассмотрим, почему на самом деле это плохая идея.

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

Именно такую картину рисует мое воспаленное воображение при слове “асинхронность”. Конечно, все это слишком эмоционально и не всегда правда. Ведь так?.. Возможны варианты. Некоторые скажут, что “при правильном подходе все будет работать хорошо”. Однако это можно сказать всегда и везде при всяком удобном и не удобном случае. Но лучше от этого не становится, баги не исправляются, а бессонница не проходит.

Так что же такое асинхронность? Почему она так привлекательна? А главное: что с ней не так?

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

Оптический поток (Optical flow) – технология, использующаяся в различных областях computer vision для определения сдвигов, сегментации, выделения объектов, компрессии видео. Однако если мы захотим его по-быстрому реализовать в своем проекте, прочитав про него на википедии или где-нибудь еще, то, скорее всего, очень быстро наткнемся на то, что он работает очень плохо и сбоит при определении сдвигов уже порядка 1-2 пикселей (по крайней мере так было у меня). Тогда обратимся к готовым реализациям, например, в OpenCV. Там он реализован различными методами и совершенно непонятно, чем аббревиатура PyrLK лучше или хуже обозначения Farneback или чего-нибудь в этом роде, да и придется поразбираться со смыслом параметров, которых в некоторых реализациях очень много. Причем, что интересно, эти алгоритмы как-то работают, в отличие от того, что мы написали сами. В чем же секрет?

Последние несколько месяцев я работал над SDK для Android, входящим в платформу управления контентом Nuxeo. Особенно много работы было в последнее время, с приближением официального релиза SDK. Я хочу поделиться несколькими практическими советами по поводу разработки под Android, в частности тестирования и эмуляции. Уже после нескольких дней разработки я понял, что работа с эмулятором Android — не сахар, потому что он чудовищно медленный.

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

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

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

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

Библиотека Qt позволяет делать действительно кроссплатформенные приложения. Единожды написанный код можно откомпилировать под многие операционные системы. Но проблема именно в слове «компилировать», т.к. подразумевается, что необходимо перезагрузиться под целевую систему, иметь в ней настроенную среду разработки, установленный и настроенный зоопарк библиотек. Спасает кросс-компиляция — компиляция, производящая исполняемый код для платформы, отличной от той, на которой исполняется.

Добрый день, Хабрахабр!
Решил написать этот топик на тему скриптов

Что нужно знать?

• С++ на приличном уровне (в уроке будут шаблоны — template)
• Lua, очень легкий скриптовый язык. Советую этот урок.

Почему писать диалоги игры в .cpp файле было большой ошибкой

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

Но есть способ, на голову выше — использование скриптов.

Доброго вечера, дорогие Хабровчане. Мы продолжаем изучение Erlang для самых маленьких.

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

В этой главе мы поднимемся на следующую ступень и рассмотрим модули и функции.

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

Чтобы было интереснее, материал представлю в виде простых задачек. Сразу подчеркну, что я не считаю приведенные примеры просчетами языка. Во многом появляется смысл и логика, если вопрос обдумать. Это скорее случаи, когда может отказать интуиция, особенно если голова забита чем-нибудь еще. Есть и пара примеров вида «Ну чего этому компилятору надо, только что то же самое работало!»

И последнее замечание. Это не будут задачи на внимательность типа «Тут я поставил точку с запятой сразу после for — а никто и не заметил». Проблемы не в опечатках. Все необходимые библиотеки можно считать подключенными — не относящийся к описываемой ситуации код я опускал, чтобы не загромождать статью.

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

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

«Самая важная вещь в языке программирования - его имя. 
Язык не будет иметь успеха без хорошего имени. 
Я недавно придумал очень хорошее имя, 
теперь осталось изобрести подходящий язык.»  
Д. Э. Кнут  

Эволюция C++09: флешбек

После первой спецификации C++, ратифицированной в 1998 году, был взят пятилетний перерыв, который позволил разработчикам компиляторов подстроиться под стандарт. Также такое время «радиомолчания» позволило Комитету получить отзывы относительно документа. В конце этого периода комитет стандартов ANSI выпустил обновлённую спецификацию, содержащую исправления и различного рода улучшения. Эти исправления были задокументированы в первом техническом списке ошибок от 2003 года.

От переводчика: данный текст даётся с незначительными сокращениями по причине местами излишней «разжёванности» материала. Автор абсолютно справедливо предупреждает, что отдельные темы покажутся чересчур простыми или общеизвестными. Тем не менее, лично мне этот текст помог упорядочить имеющиеся знания по анализу сложности алгоритмов. Надеюсь, что он будет полезен и кому-то ещё.
Из-за большого объёма оригинальной статьи я разбила её на части, которых в общей сложности будет четыре.
Я (как всегда) буду крайне признательна за любые замечания в личку по улучшению качества перевода.

Введение

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

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

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

(с) xkcd

Без использования сложных формул и матлаба я постараюсь ответить на следующие вопросы:

• FT, DTF, DTFT — в чем отличия и как совершенно разные казалось бы формулы дают столь концептуально похожие результаты?
• Как правильно интерпретировать результаты быстрого преобразования Фурье (FFT)
• Что делать если дан сигнал из 179 сэмплов а БПФ требует на вход последовательность по длине равную степени двойки
• Почему при попытке получить с помощью Фурье спектр синусоиды вместо ожидаемой одиночной “палки” на графике вылезает странная загогулина и что с этим можно сделать
• Зачем перед АЦП и после ЦАП ставят аналоговые фильтры
• Можно ли оцифровать АЦП сигнал с частотой выше половины частоты дискретизации (школьный ответ неверен, правильный ответ — можно)
• Как по цифровой последовательности восстанавливают исходный сигнал

Я буду исходить из предположения что читатель понимает что такое интеграл, комплексное число (а так же его модуль и аргумент), свертка функций, плюс хотя бы “на пальцах” представляет себе что такое дельта-функция Дирака. Не знаете — не беда, прочитайте вышеприведенные ссылки. Под “произведением функций” в данном тексте я везде буду понимать “поточечное умножение”

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

Добрый вечер, хабрачитатели!

Перед выходом 8+ в 1: наш новый мессенджер под iOS и Android, мне пришлось проделать кое-какую работу по изучению тех мест, куда мы собирались публиковать пресс-релизы. Одним из таких мест стал Хабр.

Мы задались следующими вопросами:

• В какой день недели лучше всего публиковать пост?
• В какое время (интервал времени) лучше всего публиковать пост?
• В какое время года лучше всего публиковать пост?

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

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

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

UPD: схема заменена на вариант с контейнерами из С++11, соавторы — в комментариях ниже

Если в коде на C++ был создан массив объектов с помощью «new[]», удалять этот массив нужно с помощью «delete[]» и ни в коем случае не с помощью «delete» (без скобок). Разумный вопрос: а не то что?

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

В соответствии со Стандартом C++, в этой ситуации поведение не определено. Все предположения – не более чем популярные городские легенды. Разберем подробно, почему.