mayton2019

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

Ваше решение O(ln(n)) - это очень хорошее решение. Пускай оно и будет.

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

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

Вобщем если ты где-то уже работаешь и вы используете конкретную БД - то бери и читай по ней.

Я в своё время тоже искал теоретическую литературу по оптимизации SQL. Нет толком ничего. Есть Ден Тоу. Настройка SQL для профессионалов. Он пытается подогнать под оптимизацию свою теорию. Считает селективности и кардинальности для суб-запросов и рисует "облачки" - диаграммы пытаясь вывести формулу cost. Но это всё не работает. Это разбивается о практику. Ни одна практика Oracle/PG/MSQL/MySQL не подрверждает эффеткивности диаграмм Тоу. Вобщем я зря потратил время на чтение этой книги. И тебе не советую.

Бери конкретные книги от вендора и по ним смотри.

И в твоём вопросе не хватает еще одного хеш-тега.

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

Это две задачи на каком-то этапе противоречат друг другу. Есть график (кривая Шипилева) который это демонстрирует.

Я могу понять вероятность возникновения либо события A, либо события B. Очевидно, что это сумма их вероятностей. Но вот с произведением всё никак не могу разобраться.

Ты ошибся.

Если вероятность события P(A) = 0.6 и P(B) = 0.7 то по твоей логике мы получаем величину больше 1.0 после суммирования. А это невозможно. Значит что-то не так.

Суммируется не ВЕЛИЧИНА вероятности. А ищется вероятность
- совместного наступления независимых событий
- появления хотя-бы одного из двух независимых событий или двух одновременно

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

Этот датчик ведь не создавался для криптографии. Следовательно он будет подвержен дефектам. Например будет часто предсказуем. А если не подключен - будет постоянно выдавать 0 например. Или для 80% кейсов (температурных режимов) он будет выдавать известное распределение целых чисел. Гауссово распределение с мат-ожиданием в точке 60 градусов.

Всё это - потенциальные уязвимости для функции seed.

Mp3 кодек оперирует комплексами когда звук сжимает. И вообще ВСЁ что с рядами Фурье. JPEG-сжатие.

Физика-радиоэлектроника любит комплексы. Соотв любые задачи симуляции радиоэлектроники потянут за собой это.

В математике как обычно. Если ты не смог посчитать корни квадратного уравнения при D < 0 значит ты - школьник. Любой математик всегда скажет что корень из отрицательного норм извлекается. Соотв корни - комплексные. И соотв тебе еще рано в математику т.к. ты не понял важного обобщения. Вообще ВСЕ числа в математике комплексные. К действительным мы прибегаем лишь в частных случаях (дискретная математика например) когда именно делаем акцент на этом.

Щас потихоньку начинают копать Quantum Computing. Там понятное дело тоже фреймворки и языки будут но предметная область такая хитрая что обычные подходы к ней не годятся. Тут точно нужен хороший физик математик.

Или какой-то вариант потеряется?

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

По поводу вопроса. Да. Скорее всего какой-то вариант потеряется в силу свойства хеш-функций. Это свойство сюрьекции. Что существует какие-то 2 аргумента что функция даст одно значение для них двоих. Для тройного "ША" будет скорее всего ситуация еще хуже. Тоесть еще больше коллизий. Но мы эти коллизии чорта с два найдем просто в силу того что числа слишком большие и переборные методы здесь нам не друзья.

Сервлет это Java-аналог cgi-скрипта. Сервлет - архаизм. Древний и достаточно бесполезный. Хотя в стеке технологий веба вы еще часто можете его видеть везде где есть такие контейнеры как JBoss, Tomcat, Web-Sphere. Все они понимают сервлет как актор который может обслуживать GET/POST/PUT запросы и что-то возвращать.

В современных технологиях шаблонизаторов сервлет уже является ненужным звеном и его можно выбросить. Для асинхронного веб-сервера netty ЕМНИП сервлет тоже не нужен.

В любом языке или системе программирования всегда есть функция которая получает из буквы ее код таблицы ASCII (или в наше время Unicode). Все английские и служебные символы будут в диапазоне от 32 до 127. Русские - соотв не попадают в этот диапазон.

SELECT ascii('x');

Проверить все буквы в строке - дело техники. Или другая задача.

Программа будет писаться в приложении "Embarcadero Dev-C++"

Я думаю что это не имеет значения для вопроса. Хорошее приложение не должно зависеть от сред. И вы это должны понимать и изучать собственно язык и библиотеки. А визуальные среды здесь вообще непричем.

Реализация работы нескольких процессоров одновременно.

Я здесь немного выпадаю из тапок. Потому что у меня на 2-м курсе был курсовик - что-то вроде написания эмулятора процессора с ограниченным набором команд. И я помню как это было тяжело. Особенно в отладке. Там еще были другие цели которые я впрочем не помню.

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

Данный вопрос безсмысенно обсуждать только в разделе АЛГОРИТМЫ.

Дело в том что в каждом языке программирования есть своя реализация хеш-таблиц со своими преференциями.
Например в Java создается по умолчанию пустая табличка с 16 buckets и с фактором загрузки 0.75.

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

Для случая автора число 42. Мы считаем остаток от деления на 16 это будет 10. Тоесть мы запишем в 10 бакет. А после того как в табличку зайдет большое число ключей и и соотношение ключей и емкости станет больше чем 0.75 - будет создана новая таблица с 32 бакетами и старые данные будут скопированы туда с реогранизацией ключей. Это тяжеловатая процедура поэтому изначально хеш-таблицу рекомендуется создавать уже с заранее известным capacity. Если хотите хранить 6 млрд социальных номеров людей планеты земля - то создавайте соотв такую таблицу. Тогда реорганизации не будет. И load factor можно сделать близким к 1.0.

(Старая таблица с 16 бакетами после этой процедуры будет уничтожена)

Звуковые волны - это области высокого-низкого давления в 3д пространстве. Кроме того они слишком быстро меняют форму и полярность чтобы их отображать. Вы можете изобразить их только в виде остановки времени.

Для рисования чего-либо в объеме используют объемные пикселы (voxels) но при этом нужно сделать кубическую сетку данных для каждого кубика. Тут объем информации достаточно велик. Посмотрите как работает софт для томографов. Он примерно решает ту-же задачу. Отображает объем через информацию о десатке срезов исследуемого объекта. У вас срезом - будет воздух и звуковая колонка или источник звука.

Перетащил это всё на MongoDB с такой структурой:

Справочники остались в MySQL.
.......
Какие есть идеи?

Думаю попробовать перенести структуру на PostgreSQL аналогично MongoDB и использовать

Дружище. Так жеж не делается в мире Документно-ориентированных БД! В монге ты делаешь не таблицы. А хранилища документов. Где каждый документ - самодостаточен и полностью хранит в себе всю информацию. Грубо говоря никаких СПРАВОЧНИКОВ и СВЯЗНЫХ таблиц у тебя быть не должно. И нельзя джойнить документы. И нельзя джойнить документы с таблицами MySQL.

Почитай про модель АГРЕГАТОВ в противовес реляционной модели. Это можно найти в книжках типа NoSQL и еще я находил это в доках по Cassandra.

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

Вот те кто клятвенно обещают самые безопасные хранения кошельков - должны предъявить обществу ссылку на свой криптовалютный кошелек с приличным балансом. И это будет самое красноречивое proof of security.

Я полностью поддерживаю использование УЛУЧШАТОРОВ типа SonarQube, PMD и прочие которые просто позволяют указать мне на явные ошибки типа potenrial null pointer de-referencing.

Но вот в части - написать по другому - я-бы сказал что это открытый вопрос. Ставить ТЗ нельзя так чтобы "сделать на выходе хоть что-нибудь". При таких критериях мы получим просто рандомный шум который тем не менее компилируется. Типа "бей посуду - я плачу". Но автору такое не надо.

Тогда давайте зададим вопрос. А что собсно надо автору? Приведу пример который я часто использую. Решения задач на codewars. Они разные. Но обычно в топе висят 2-3 штуки которые поражают своей краткостью и различностью парадигм. Например в топе висит одно решение с хвостовой рекурсией а другое с циклом. И я не могу решить которое мне больше нравится. Нравятся оба. Но скорее всего при разработке code beautifier я-бы не стал вообще копать 2 направления. Достаточно было-бы просто поставить задачу сделать код меньше. Я думаю что все согласятся что меньше строк - меньше надо будет скроллить вниз. Особенно эти дело любят Джависты. Как накидают своих бинов с геттерами-сеттерами ойойой. 80% кода - нечитаемый шлак. Ну да ладно. А насколько меньше? Есть обфускация. Это сознательне выпиливание смыслов из всех идентификаторов. Вобщем переменные можно называть $1,$2 e.t.c. и это тоже работает. Но ... согласитесь это путь в никуда.

Поэтому. Чтобы улучшать мы должны САМИ задать вектор улучшения. Парадигмы например. Мы хотим код тяготеющий к функциям или к объектам с методами? Мы хотим код с детальным дебагом (каждый оператор в своей строчке) или нам пойдет исходник как у Джона Кармака. Весь С++ исходник в 1 длинную строку. Мы хотим код на конечных автоматах? Или на комбинаторах? Мы хотим больше перформанс но хуже читаемость (вспоминаем знаменитую Кривую Шипилёва) или наоборот?

Вобщем думайте над вектором улучшения.