mayton2019

Это переменная которая хранит код ошибки предшествующей команды. Обычно 0 - это ок. А другое число говорит о неудаче.

Скорее всего надо запустить компиллятор и оценить масштаб трагедии. И после этого писать новое сообщение в тостер.

Я сильно сомневаюсь в наших "прогнозах" здесь в условиях отсутствия информации.

Автор не правильно формулирует задачу.

Я предлагаю словарь Python все таки оставить словарем и не искать натянутых аналогий. База данных (в общем понимании этого слова) это RDBMS с поддержкой ACID.

В противном случае, и ощипанный петух будет человеком.

Я бы предложил 2 шага.
1) построить гистограмму для всех X,Y координат раздельно. Выбрать локальные минимумы. Это будут линии таблицы. Но не точно.

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

На данном этапе (полностью отсутствуют требования) ты можешь брать любой сервер. Tomcat. Jetty. Но я слышал что игроделы для hi-load используют Netty. Хотя он не такой удобный.

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

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

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

Не все что считается мат-статистикой надо обзывать машинным обучением. Первые два пункта - вообще не требуют ML.

Третий - настольно сложен и непонятен в своей постановке что его надо просто очень долго обсуждать. Что на входе и что на выходе.

Чтоб не было как в анекдоте про "штурман прибор 100"...

Когда снимаю рекламу клубники со сливками - то обычно вместо сливок льют клей или краску.

А на картинке - скорее всего обычное печенье только под фотошопом. Всяко дешевле фоткать и фотошопить чем 3d модель создать.

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

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

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

Вопрос поставлен неправильно.
Чтоб оптимизировать odbc - надо 100% знать что именно он является узким местом. Я бы начал с анализа исполнения и извлечения данных локально на сервере. ДБА здесь поможет. И если ваша задаче связана с ETL - почитайте про техники. Может экспорт в csv файл с загрузкой в с++ приложение будет быстрее. Может репликация бд или миграция.

По усредненному цвету

Исключения I/O - одни из самых сложных п принятии решения. Это связано с тем что сеть - это часть внешнего мира. Того на который ты не влияешь. В чем может быть причина? На каждый класс ошибок и на каждый источник данных должна быть таблица принятия решений. Например ты знаешь что в каждый четверг данный rest сервис имеет возможный регламент обновлений. Выдавай на UI плитку с сообщением о регламенте и проси повторить через какое то время. А другий рест сервис просто висит на слабом канале. И к нему надо применять RetryLogic. Молча. Просто другого выхода нет.

Общих рекомендаций нет.

Надо сортировать по расстоянию Левенштейна (levenshtein) от выражения "test" до поля email.

Тут нужны не документы и рисовалка, а графовая БД, наподобие Neo4j.

А разве это возможно? Git позволяет изменить только последние коммиты, схлопнув их в 1 коммит (amend).

Или можно полностью создать новый репо и перенести туда все изменения по 1 штуке.

Сделайте дополнительный appender который пишет в json формате и настройте на эти файлы кибану. И тогда будет решена проблема многострочности.

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