mayton2019

По всем ответам - согласен. Добавлю. В данной постановке точный поиск вообще не работает. Но работает fuzzy - поиск с использованием триграмм. Триграммы - это тройки букв которые должны максимально близко совпасть у шаблона и искомой строки. Чем их больше - тем выше similarity. Похожесть типа.

Вобщем делайте поиск где SIMILARITY > 0.5 или какой-то любой величины. И выводите пользователю строки-кандидаты в порядке ранга похожести. И пускай он сам выбирает.

Для скорости - стройте триграм-индекс. Вот тут для начала почитайте https://www.postgresql.org/docs/current/pgtrgm.html

Для python3

>>> type(34567 << 16)
<class 'int'>

вот этот класс int представляет собой хитрую штуку. Это как-бы аналог целого числа бесконечно большой радрядности.

А JavaScript там по ситуации либо int (32 bit) либо double.

Не знаю что такое тепловая карта но догадываюсь. Возьмите случайным образом бросьте на карту n банкоматов. Потом методом градиентного спуска спустите их по теплу в локальный максимум. Получится первый вариант расклада. Запомните его. И еще таких штук 10 рандомных раскладов. Потом - пускай человек выберет из этих раскладов тот который наиболее приятен глазу. Или введите там еще один критерий. Чтобы в радиусе километра не было соседних банкоматов.

Какой смысл команды dup в JVM байт коде?

Жаль что ты не программировал на калькуляторе МК 60. Это целая эпоха.

Значит есть разные пути к вычислению арифметики. Например если тебе надо возвести в квадрат число 5 на регистровой машине - то ты должен загрузить регистр R1 числом. Потом регистр R2. И потом найти такую команду умножения которая свяжет регистры R1 и R2 и перемножит и сохранит еще где-то результат. В силу современного зоопарка процессоров практически нереально создать такой абстрактный байткод который бы эффективно отображался на опкоды разных железяк. Поэтому решили забить на регистровую машину. И использовать стек как хранилище операндов для операций. Разумеется в JVM есть и аналоги регистров но с ними не выполняются операции. ЕМНИП. Если хошь что-то сложить или вызвать функцию - то положи на стек и там-же получи результат. И если вернуться к возведению числа 5 в квадрат это может быть так

положить 5 на стек.
дублировать
вызвать функцию умножения

На каком-нибудь языке Forth это было-бы тремя командами
5 DUP * .
Результат - на вершине стека.

Это кратко записывается. Но это несет абсолютно ту-же смысловую нагрузку для арифметики.

Почему их только 256 может быть?

А чорт его знает. Так решили. Решили что 256 регистров это капец какой максимум для процедуры или функции. Послушай ради интереса видосы про процессор Эльбрус. Там тоже интересно с регистрами сделано.

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

Я думаю что твое предположение о том какой код соберет JIT не совсем верное.
Вместо спора я предлагаю взять какой-то тестовый сценарий и подсмотреть какой
будет собран код. Я знаю что скептики Java обычно после изучения вопроса глубже
меняют свою точку зрения. Ну по крайней мере перестают считать Java
"медленным покемоном". Java действительно была слоупоком во времена Jdk 1.1.
Но щас это не так.

Несколько лет назад я мерял производительность floating-point вычислений на приложении
которое рендерит зеркальные шары. И разница между С++ и Java была не сильно большая.
10 секунд на сях и 12 секунд на втором языке соотв. Хотя этот тест узкий и он просто
показывает частный случай.