Мой первый успех в литературе случился в 17 лет. Тогда я стал призёром олимпиады по русскому языку среди абитуриентов в вузы с сочинением: “Почему еврей Розенталь устанавливает правила русского языка”.

Пару статей назад я уже рассматривала один из алгоритмов Бойера-Мура, с помощью которого можно было найти подстроку в строке.

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

Предлагаю сразу использовать его на примере задачи «Majority Element» с leetcode.

Условие здесь: https://leetcode.com/problems/most-frequent-even-element/description/

Кстати, у меня есть телеграм-канал, где пишу подходы к решениям всяких задачек с LeetCode, там больше разборов конкретных задач, чем здесь, потому что не всегда нужна статья. В общем, если интересно - жду здесь - t.me/crushiteasy :)

Возвращаемся к Муру!

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

Не супер очевидно, но это число занимает больше половины элементов массива, т.е.

В прошлой статье мы забыли упомянуть FOV (Field of view). По сути это угол обзора, в котором все лучи лежат равномерно с разницей, допустим, в ~1⁰.

К текущей статье мы успели заменить мелкую ячейку памяти настроек cell1, на банк настроек памяти bank12, bank2, bank1 (в зависимости от процессора).

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

Ещё изменился внешний вид нашего псевдо-3D движка, теперь он более аккуратный...

Привет, меня зовут Рома. Я работаю в KTS на позиции Python backend-разработчика. 

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

Классификация лабиринтов

Приветствую вас! Меня зовут Денис, я разрабатываю игры на Unity, и сегодня я расскажу о том, как устроена генерация лабиринтов в игре, которая находится на данный момент в разработке.

Это не коммерческий проект (хотя есть планы по выпуску игры в Google Play), а мой личный, так что в конце статьи вас ждёт технодемка.

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

Допустим, у нас есть массив чисел с плавающей запятой, и мы хотим их суммировать. Можно наивно подумать, что их достаточно просто сложить, например, на Rust.

Однако это запросто может привести к произвольно большой накопленной погрешности. Давайте проверим:

naive_sum(&vec![1.0; 1_000_000]) = 1000000.0
naive_sum(&vec![1.0; 10_000_000]) = 10000000.0
naive_sum(&vec![1.0; 100_000_000]) = 16777216.0
naive_sum(&vec![1.0; 1_000_000_000]) = 16777216.0

Ой-ёй… Что произошло? Проблема в том .что следующее 32-битное число с плавающей запятой после 16777216 — это 16777218. Так что при вычислении 16777216 + 1, значение округляется до ближайшего числа с плавающей запятой, имеющей чётную мантиссу, то есть снова до 16777216. Мы зашли в тупик.

К счастью, есть более совершенные способы суммирования массива.

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

Привет любителям микро-кодирования. Вот вам кое-что невероятное: крошечный движок raycasting (метод “бросания лучей”) и генератор городов, который помещается в отдельный 256-байтовый HTML-файл.

Привет всем любителям size coding, сегодня я расскажу о чём-то потрясающем: крошечном движке трассировки лучей (raycasting) и генераторе города, умещающихся в автономном файле HTML размером 256 байтов.

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

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

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

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

Внимание! В статье много картинок.

CE поддерживает 69 языков, более двух тысяч компиляторов и широкий спектр архитектур, включая x86, arm, risc-v, avr, mips, vax, tensa, 68k, PowerPC, SPARC и даже древний 6502.

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

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