mayton2019

Масствы в Java - достаточно статичные и жесткие чтобы их растягивать. Обычно создают новый массив нужного размера (в твоём случае это удвоенный размер) и старые данные копируют с удвоением.

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

В обоих из них можно изобразить стрелочкой или агрегацию (для классов) или связь child-parent как ссылочный
ключ в таблицах.

В случае с классами достаточно просто описать что поле имеет тот-же тип что и сам класс. Это будет всем понятно.

Это задача на смекалку. Тут на самом деле сортировать не надо. Тут нужен роутинг слов в разные файлы.
В 1 проход делается. Разумеется мы должны предполагать что в 2Гб файле будут не сильно длинные строки.

Допустим для среднего текстового файла 80 символов на строку (стандарт такой был в 20м веке) мы получим
80 файлов.

По смыслу это похоже на сортировку подсчетом. Это когда кардинальность выборки крайне низка. Гендер например.

Если в нерабочее время - то можно было-бы убивать тестовую базу ночью. Копировать все датафайлы продуктовой. И стартовать ее снова. Ну там.. внеся какие-то косметические изменения в конфиг если надо.

Это самый быстрый способ IMHO. Но я его использовал под Oracle. Как будет комфортно для MySQL - чорт его знает.

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

Разработчик геймдева должен знать хорошо классическую механику. Я вот лет 15 назад пытался создать свою игру. Эдакий гибрид танчиков и майнкрафта но не вышло. У меня не хватало просто времени чтобы опробовать свои решения в части например взаимодействия твердых тел. Да и боюсь уже никогда не будет. Семья. Работа.

А в современных играх есть механикка жидкостей (флуидов) газов и таже тканей. Есть фреймворки наподобие PhyzX, Bullet но я-бы за них брался только после того как сам пойму как эта физика работает. Иначе вместо красивой игры можно сделать слайд-шоу и загрузить процессор расчетом молекул. А геймеру что надо? Ему вообще физика собсно не надо. Ему нужна эффектность. Тоесть там где не тянет CPU - надо просто добавить эффект ПОХОЖИЙ на физический.

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

Ваше решение 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 аргумента что функция даст одно значение для них двоих. Для тройного "ША" будет скорее всего ситуация еще хуже. Тоесть еще больше коллизий. Но мы эти коллизии чорта с два найдем просто в силу того что числа слишком большие и переборные методы здесь нам не друзья.