mayton2019

Почти все гео-поисковые системы для хранения геометрии используют либо quad-tree либо R-tree. К чему здесь Mongo - вообще непонятно. Это бд другого типа. Для документов.

Бери деревья и используй. Мало памяти - ну решай это быстрыми дисками или просто покупай больше узлов для параллельных поисков.

Тут тема вопроса - не ассемблер а цифровые устройства и микропроцессорные системы. В частности сумматоры. Тема - специфичная. Не для тостера. А для форумов где сидят дядьки с паяльниками. Вообще удивительно что такое ещё задают.

Похоже это называется Расстояние Манхеттена.
Как пешеход идёт по кварталам.

Кстати автор слегка хитрит. Там ещё есть два пути с таким же числом поворотов.

Нужно ли искать все? И как долго автор хочет искать пока задача не превратилась чисто в комбинаторную?

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

На самом деле эту задачу можно сделать очень разными способами. Деструктивными и нет. Экономными (массив) и неэкономными (зубчатый или двумерный массив). И автор должен конкретизировать как он хочет.

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

Разделение кода на слои также является нужным скилом для c++ ника.

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

А если говорить простыми словами то все подмножество алгоритмов делится на константные O(1) - это поиск в хеш-табличке. Логарифмические O(Log n) - это поиск в дереве или сортированной коллекции. Линейные - любой поиск в произвольнйо коллекции O(n). И дальше идут полиномиальные (это всегда цикл в цикле) экспоненциальные O(exp n). Здесь начинается криптография. И комбинаторные, в формулу которых входит факториал от N или еще апроксимируется O(n^n). Последние как-раз и создают тот самый класс нерешаемых наукой алгоритмов для которых пытаются строить квантовые устройства работающие совсем на других физических принципах.

Тут наверное OpenCV не надо. Просто замерять цвета нескольких точек в течение 3-5 секунд (как фотик наводит резкость) и брать их среднее значение.

Этот алгоритм прост - как автомат Калашникова. А все что простое - работает быстро. Как будет работать OpenCV на Raspberri мне даже страшно представить. Скорее всего плохо т.к. OpenCV проектировалась сразу для сильного железа а Распберри это больше игрушка для энтузиастов чем платформа для видое-обработки.

Пиксельная графика - это художественный прием который не имеет отношения например к инженерной графике.
Грубо говоря абсолютно точно нарисованный круг по пикселям может некрасиво выглядеть в вашей игре.

А если ему срезать углы - то можно достигнуть визуальной красоты. Только с точки зрения математики это уже будет овал или RoundRect.

Против алгоритмов Брезенхема не имею ничего против. Но это про другое.

Автор ну ты капец мотивирующие задачи ставишь. Все структуры данных - с анонимными полями. Ну и как писать алгоритм? Есть tuple с тремя полями. Поле первое без имени .. второе без имени.

Мог бы хоть усилие приложить чтоб оформить.

По сути задача звучит так.

Разработать непозиционную систему счисления для представления любого простого числа наименьшим числом символов системы.

Непозиционная в качестве примера - это римская. I/II/III символы. Или система фибоначчи 1,1,2,3,5,8. В твоём случае символ включает в себя еще и знак плюс-минус.

Книжка странная. Мне кажется она - опускается до уровня детей. И кормит им информацию с ложечки.

Если вы - нормальный инженер It-технологий то можете потреблять пищу в твердом виде. Посмотрите Алгоритмы и - Никлауса Вирта. Это - золотая классика. Написал отец и создатель Паскаля. Тоесть человек который специально и создавал язык программирования для процесса обучения.

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

Если под классического Дейкстру вы подсунете граф с циклами - то он зациклиться и никогда не выдаст ответа.

Что поделаешь. Таков он есть алгоритм. Но с другой стороны. Зачем вам решать задачу поиска кратчайших маршрутов на циклах? Поищите реальный пример из жизни и вы поймете что либо абстракция "не та" либо не тот алгоритм.

Поиск в глубину с мини-максом. Тоже самое в шахматах и шашках и крестиках-ноликах. Меняются только ограничители на то куда можно ставить следующую фигуру. Основное ядро поискового алгоритма - это генерик. Обобщенный алгоритм если можно так сказать.

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

Так может быть не стоит ставить вопрос деления вселенной на ключи и неключи?

Иначе часть структур данных придется выбросить.

Скорее всего ответов будет много.

Если скопление точек - похоже на "рога" на плоскости то под функцию одинаково подходит и косинус, и парабола и гиперболический косинус.

И здесь очень важно понять что четкого ответа не будет.

Данный пример с чтением png - неудачный.
Дело в том что декодирование png не параллелится. Оно будет выполнено на 1 ядре процессора. И это займет 80% времени. Я так думаю. А уже декорированную матрицу RGB - да можно процессить на Opencl разбивая картинку на строки или на фреймы. Но преимущества opencl будут потеряны. Ведь мы уже львиную часть времени простояли ожидая декодирования.

Город похож на город когда дома и кварталы в нем имеют углы - близкие к 90 градусов. Такой вот нечеткий криетрий.

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

Исходно дерево при этом должно остаться без изменеинй?