Тема «нужны или не нужны алгоритмы современным разработчикам» на днях в очередной раз всплывала на Хабре и породила множество комментариев. В связи с этим предлагаю следующий опрос.

Сможете ли вы реализовать, пусть и не production ready, этот алгоритм, почти не подсматривая в спецификацию:

UPD: Касательно последнего опроса — было бы очень интересно в комментариях услышать реальные интересные примеры из жизни.

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

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



Мы расскажем об одном из возможных методов реализации табличного элемента управления, обладающего свойствами Log(N)-быстрого 1) первоначального отображения 2) прокрутки на всём диапазоне записей 3) перехода к записи с заданным уникальным ключом. Всё это — при двух ограничениях: 1) записи могут быть отсортированы только по индексированному набору полей и 2) collation-правила базы данных должны быть известны алгоритму.

Изложенные в статье принципы были реализованы автором в проекте с его участием на языке Java.

Всем привет! Социальная сеть ВКонтакте возобновляет свой блог на Хабре.

Первое, о чём хотим рассказать, – чемпионат по спортивному программированию VK Cup 2016 и разбор нескольких интересных задач с прошлого года.

Несколько слов о Чемпионате. ВКонтакте проводит третий VK Cup — чемпионат по программированию среди русскоязычных молодых специалистов, студентов, школьников и просто любителей алгоритмов и структур данных.

К участию в нём приглашаются команды из двух человек (можно участвовать и индивидуально), чей возраст от 14 до 23 лет. Отборочные этапы пройдут с марта по май, а в финал будут приглашены лучшие 20 команд. Финал пройдет в Санкт-Петербурге в июле, лучшие восемь команд будут награждены призами:

1 место — 1048576 рублей
2 местo — 524288 рублей
3 местo — 262144 рубля
4-8 места — 131072 рубля

Соревнование будет проходить на площадке Codeforces, регистрация уже открыта — спешите зарегистрировать команду! Начать своё участие необходимо с квалификационных этапов, которые будут проходить 13-14 и 20-21 марта. Участвовать можно как в двух, так и в любом из них. Все подробности доступны по ссылке на странице Чемпионата.

Продолжаем перевод серии статей об обработки исключений в C++

1 часть
2 часть

C++ exceptions под капотом: поиск верного landing pad

Это уже 15-я глава в нашей длинной истории. Мы уже изучили достаточно много о том, как работают исключения, и даже имеем написанную работающую собственную персональную функцию с небольшим количеством рефлексии, определяющей где находится catch-блок (landing pad в терминах исключений). В прошлой главе мы написали персональную функцию, которая может обрабатывать исключения, но она всегда подставляет только первый landing pad (т.е. первый же catch-блок). Давайте улучшим нашу персональную функцию, добавив возможность выбирать правильный landing pad в функции с несколькими catch-блоками.

Продолжаем перевод серии статей об обработки исключений в С++

1 часть
3 часть

C++ exceptions под капотом: милая персональность

Наша поездка в удивительном путешествии изучения работы исключений еще далека от конца, нам еще предстоит изучить что-то называемое "call frame information", помогающая библиотеке Unwind делать разворачивание стэка, а так же что компилятор пишет в чем-то, называемом LSDA, в которой определяется, какие ошибки метод может обрабатывать. А так же мы уже узнали, что большинство магии происходит в персональной функции, которую мы пока еще не видели в действии. Давайте резюмируем, что мы уже знаем о пробросе и отлове ошибок (или, точнее, что мы уже знаем о том, как брошенное будет перехвачено):

• компилятор транслирует throw объявление в пару cxa_allocate_exception/xca_throw
• __cxa_allocate_exception создает исключение в памяти
• __cxa_throw запускает работу разворачивания и передает исключение в низко-уровневую библиотеку разворачивания, вызывая _Unwind_RaiseException
• Разворачивание стэка использует CFI, чтобы узнать, какая сейчас функция в стеке
• Каждая функция имеет LSDA, добавляя что-то, называемое .gcc_except_table
• Разворачивание вызывает персональную функцию с текущим фреймом стэка и LSDA, которая должна продолжить разворачивать стэк, если текущая функция не имеет обработчиков исключения данного типа.

От переводчика

В мире победили языки высокого уровня и в мирах руби-питон-js разработчиков остается только разглагольствовать, что в плюсах не стоит использовать то или иное. Например, исключения, потому что они медленные и генерируют много лишнего кода. Стоило спросить "и какой же код он генерирует", как в ответ получил мямленье и мычание. А и правда — как же они работают? Ну что ж, компилируем в g++ с флагом -S, смотрим что получилось. Поверхностно разобраться не сложно, однако то, что остались недопонимания — не давали мне спать. К счастью, готовая статья нашлась.

На хабре есть несколько статей, подробных и не очень (при этом все равно хороших), посвященных тому, как работают exceptions в C++. Однако нет ни одной по-настоящему глубокой, поэтому я решил восполнить этот пробел, благо есть подходящий материал. Кому интересно как работают исключения в C++ на примере gcc — запаситесь pocket-ом или evernote, свободным временем и добро пожаловать под кат.

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

При устройстве на работу программистом столкнулся с интересной задачей следующего содержания:

«Напишите программу, которая выводит на экран числа от 1 до 100. При этом вместо чисел, кратных трем, программа должна выводить слово Fizz, а вместо чисел, кратных пяти — слово Buzz. Если число кратно пятнадцати, то программа должна выводить слово FizzBuzz. Задача может показаться очевидной, но нужно получить наиболее простое и красивое решение.»

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

Читая публикации на Хабре нашел пару статей об алгоритмах игры гомоку: эту и эту. В первой статье разобраны различные варианты решения задачи, но нет реализации в виде игры, во второй — игра есть, но компьютер «играет» слабовато. Я решил сделать свой вариант игры гомоку с блэкджеком достаточно сильной игрой компьютера. Публикация о том, что в итоге получилось. Для тех, кто любит сразу в бой — сама игра.

Привет, Хаброжители! У нас вышла новинка:

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

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

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

Когда-то компьютеры были женщинами, калькуляторы работали на электромоторах, вместо учебников были чертежи, а программисты выглядели вот так:


ENIAC girls

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

Одна из них, Бетти, вспоминает:

«В то время у нас были механические калькуляторы, на шестеренках и с электроприводом, которые могли выполнять простейшие арифметические операции. Вы выполняли умножение и записывали ответ, чтобы потом его заново ввести в машину. Мы готовили баллистические таблицы для каждого орудия, примерно для 1800 траекторий. Чтобы вычислить вручную одну траекторию требовалось 30-40 часов просиживания перед столом с листиком и калькулятором. Название моей профессии для баллистического проекта было „компьютер“. Идея была в том, что я не просто выполняла арифметические операции, а принимала решения, что делать на следующем шаге. ENIAC сделал меня, одну из первых „компьютеров“, устаревшей технологией.»

Не так давно в процессе разработки редактора 2D-графики возникла задача разложить матрицу аффинного преобразования на плоскости, на произведение матриц простых преобразований с тем, чтобы отобразить их пользователю и предложить какую-то более-менее адекватную интерпретацию того, что произошло с объектом на канвасе. Честно говоря, эта задача вызвала у меня определенные трудности. Университет я закончил уже давно, и мне было непонятно, а возможно ли это сделать в принципе, учитывая, что исходная матрица могла быть результатом произвольной последовательности сдвигов, масштабов, поворотов, и переносов, причем каждое преобразование могло иметь свой произвольный центр. И, во-вторых, непонятно было, как найти семь параметров, имея всего шесть коэффициентов матрицы. Ключом к решению этой задачи оказалась статья "Разложение матрицы центроаффинного преобразования для нормализации изображения"¹, в которой рассматривается такая же задача, но без учета преобразования переноса и для преобразований относительно центра координат. Далее я фактически просто адаптирую результаты этой статьи с учетом переноса и для произвольного центра преобразований.

От переводчика: части обзора имеют небольшой размер, поэтому решил переводить сразу по две части.

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

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

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

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

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

Немного теории

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

Главная цель бинаризации, это радикальное уменьшение количества информации, с которой приходится работать. Просто говоря, удачная бинаризация сильно упрощает последующую работу с изображением. С другой стороны, неудачи в процессе бинаризации могут привети к искажениям, таким, как разрывы в линиях, потеря значащих деталей, нарушение целостности объектов, появление шума и непредсказуемое искажение символов из-за неоднородностей фона. Различные методы бинаризации имеют свои слабые места: так, например, метод Оцу может приводить к утрате мелких деталей и „слипанию“ близлежащих символов, а метод Ниблэка грешит появлением ложных объектов в случае неоднородностей фона с низкой контрастностью. Отсюда следует, что каждый метод должен быть применен в своей области.

Последние два года вся страна пристально следит за курсом доллара. Новостные выпуски пестрят громкими репортажами о долларе. Все говорят о долларе. А что, если мы на фоне горячего интереса, разберемся с тем, как формируется цена доллара, посмотрим кто и как торгует валютой?! Все результаты, представленные в данной статье, получены на основе официальных торговых данных full orders log (полный журнал заявок), купленные на Московской Бирже. Мы покажем реальные торги изнутри. Параллельно, познакомимся со стандартными методами анализа рынка. Такая аналитика стоит не малых денег и её могут позволить ограниченное число «компаний».

Инструментом для анализа данных будет Java. Анализируемый биржевой инструмент — USDRUB_TOM. Наша задача вытащить любопытные детали из имеющихся данных и попробовать сделать определенные выводы.

WebGL — одна из самых интересных новых технологий, которая способна удивительным образом преобразовать интернет. На базе этой технологии уже создано несколько движков, которые позволяют без лишних усилий создавать удивительные вещи, и наиболее известный из них Three.js. Познакомится с ним было моим давним желанием, и лучший способ сделать это — создать что-нибудь интересное. Первой идей было набросать “воодушевляющую” сцену на Three.js содержащую как большое количество полигонов, источников освещения и частиц, так и имеющую, при этом, какой-то осмысленный контекст. Вскоре, эта идея превратилась в желание создать бесконечный город в который можно было бы погрузиться сквозь браузер.

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

То, о чем я попытаюсь сейчас рассказать, выглядит как настоящая магия.

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

Итак, магия:


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

Алгоритм воронки — это простой алгоритм поиска наипростейшего пути, проходящего через «порталы». Наиболее подробное описание можно найти по ссылке Efficient Triangulation-Based Pathfinding (2)
Здесь же этот алгоритм будет реализован до одури просто. Вместо использования очередей и прочих очешуительных вещей, наша простейшая реализация перезапускает цикл каждый раз, когда обнаруживает очередной угол. Это значит, что некоторые порталы будут опрашиваться таки чаще, чем должны были бы, тем не менее, делая реализацию всяко проще.

Я часто собеседую разработчиков и часто задаю им простой, как кувалда, вопрос — как внутри работает JOIN в SQL? В ответ я обычно слышу бессвязное мычание про волшебные деревья и индексы, которые быстрее. Когда-то мне казалось, что каждый программист специалист должен знать то, с чем работает. Впоследствии жизнь объяснила мне, что это не так. Но мне все еще не понятно, как можно годами теребить базёнку, даже не догадываясь, а что там у нее «под капотом»?

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