mayton2019

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

Нужна функция предикат или перегруженный оператор сравнения. Вот посмотри как тут пишут
https://stackoverflow.com/questions/2758080/how-to...

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

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

Ты можешь открыть транзакцию и сделать два инсерта в разные таблички. И с точки зрения БД
это будет иметь смысл атомарного действия.

Или ты другое хотел?

Когда говорят о базе данных, то 99% имеется в виду классическая реляционная БД типа Postgres/MySQL e.t.c.
Такие базы данных создавались для эффективного соединения кортежей и сортировок. Длина DataRow
при этом обычно не больашя (до 8К целый блок таких строк). Эта цифра имеет корни еще в 20м веке.
И если заставить их хранить html (обычно 5-100К) то такая деятельность может быть не очень
удобная для БД. Это как микроскопом гвозди забивать. Очень умная система будет использоваться как
файловое хранилище. Возникает идея - просто взять что-то ориентированное на файлы. Например S3,
BlobStorage, GoogleDrive. Это было-бы дешевле с точки зрения стоимости владения и бэкап делать
проще.

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

Многофакторка как раз и создана чтобы повысить безопасность на базе
имеющихся тенических средств (телефоны и аппаратные генераторы ключей).

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

Скорее всего такого алгоритма нет. Размер структуры будет зависеть
от разрядности платформы и от типа компиллятора и возможно от всяких
опций типа #pragrma pack. Тоесть получается нехилый квест.

Технически, тебе достаточно sizeof для решения твоих прикладных задач.

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

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

Я-бы переделал табличку. Пускай мета-данные по продуктам лежат в виде битовых полей.

create table product(
  ....
  params_group1 BINARY(100),
  params_group2 BINARY(100),
  params_group3 BINARY(100)
)

И дальше булевыми (bitwise) операциями как тут пишут https://dev.mysql.com/doc/refman/8.0/en/bit-functi... делать поиски продуктов по маске свойств.

Несколько мыслей. Первое. Скорее всего утилита зависает здесь
TcpStream::connect(&ip)
но ты должен это сам проверить и доказать во время подачи вопроса в хабр. Логгированием или профилированием неважно. Короче приходи - чуть более подготовленным чем просто с зависающей программой.

Второе. Сам по себе TCP протокол не бесплатный. Каждый новый сокет аллоцирует память в виде буфера
для отработки опций протокола (восстановление стрима с учетом потерянных пакетов) и этот буфер
где-то регулируется. Поищи. Проверь также скорость работы твоего приложения. Как быстро он отрабатывает
ответ от молчаливых портов которые ничего не отвечают. Это - тоже протокольная ситуация и ее надо как-то
обработать. Грубо говоря не доверять дефолтным таймингам.

Третье. Возможно некоторые промышленные утилиты-сканеры такие как nmap не используют создание
сокетов. Они могут работать на уровне IP протокола просто посылая SYN-пакеты и обрабатывая ответы
асинхронно. Это такая хитрость которая позволяет создать сокет без буфера. Это не честно с точки
зрения полноценного протокола но достаточно чтобы проверить что ACK пришел. Вот почитай какие
возможности у RUST есть в части IP-программирования.

Фильтр Гаусса ничего не знает о цвете. Он просто применяется к матрице вещесвтенных чисел.
Поэтому обычно картинку в формате RGB переводят в трех-слойную вещественную матрицу { double, double, double }
и фильтр Гаусса применяют трижды для каждого слоя. И результат потом снова сводят в RGB.

Есть миллиард хитростей как делать это в целых или в вещественных числах или как использовать SIMD, Parallel
computing e.t.c. но ты сделай сначала самый простой и работающий вариант а потом уже оптимизация.

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

На codewars есть опция выбора языка. Можно взять Rust. И там можно решать задачи разной сложности. И после решения сравнить свой исходник с другими (более успешными обычно).

На регулярной основе - я-бы загружал этот файл в базу данных. И там через update обновлял бы поле 90 на 100.
А потом сохранял-бы обратно в CSV файл.

Если задача одноразовая ... ну есть масса утилит типа sed/awk/perl они это делают за 2 минуты.

С помощью DNS.

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

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

Нужно делать одну таблицу и с ней работать. Самый простой вариант - обычно самый надежный и долговечный.

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

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

Для блочной игры типа Minecraft можно применять Octree https://en.wikipedia.org/wiki/Octree

Практически везде в С и других языках применяются хеш-мапы и красно-черные деревья. Они
закрывают 90% всех твоих потребностей. Вот изучи их и используй. Все прочие экзотические
структуры данных - надо обсуждать применительно к каждому случаю. Многие из них
являются просто композицией уже известных. Например LRU-лист это хеш-мапа и связный список.

Автор вот ты написал СДНФ или СКНФ. Это означает что ты уже читаешь булеву алгебру. И ты уже прошел
основы булевой алгебры. Я не помню где это написано. Честно не помню. Но разве тебя не удивляет что в
математике целое число можно представить в виде суммы других чисел. Или гладкая функция - представима
в виде суперпозиции других гладких функций.

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

Практически такое решение будет очень небезопасным. Обычно вебу дается минимум доступа к БД и то
через всякие сервисы и прослойки. А вы прям открываете вообще все что только есть. Это я думаю - плохой
дизайн по безопасности. И пользователь может грохнуть целую таблицу случайно.

Графические инструменты для работы с БД есть. Например JBeaver. Универсален и удобнее веба.