mayton2019

Зачем делать безсмысленный makeStep? Пускай он возвращает булево значение.

boolean makeStep(Graph &graph, ValuesTable &table) { .... }

Не было отрицательных свойств среди вершин - значит пускай вернет true.
Тогда будет стоп алгоритма. И не надо будет
делать дополнительных пере-расчетов.

Такая грамматика уже создана. Называется язык Prolog.

Сразу скажу что сама затея создания словесных экспертных систем обречена на провал.
Растущая комбинаторная сложность и сложность задавания вопросов этой системе
свела на нет все усилия лет 30 назад.

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

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

( x1 >= x > x2, y1 >= y > y2 )

Это дает возможновть в любых координатах в int, double e.t.c. считать плотно рядышком стоящие
прямоугольники не пересекающимися вообще.

Если этот код компилируется С++ компиллятором - то тогда нет причин для беспокойства.
А если твой препод такой нудный - то спроси до какой степени он хочет переписывать?
Самое простое что приходит на ум - заменть ASCIIZ строки на std::string. Попробуй везде
сделай такое. Вот это

void output_res(char* mas_str, int* arr, char character, int occurrences)

заменить на

void output_res(string mas_str, int* arr, char character, int occurrences)

Потом strtok, strlen, printf заменить на методы string или cout.operator<< соотвественно.

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

Файловая система - самый дешевый способ хранения инфы. Если других требований нет - почему бы и нет?

Можно попробовать автоматизировать сбор фамилий и отчеств. У них вроде регулярные окончания.
А между ними - соотв. будет имя.

Текстовый поиск. Не?

Можно взять белый софит и поставить на него светофильтр нужного цвета.

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

Нужна функция предикат или перегруженный оператор сравнения. Вот посмотри как тут пишут
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 например.