Сергей Соколов

В отличии от программирования и подобных специальностей существуют три базовых способа изучить искусство управления:
1. вуз
2. специальные курсы + сертификация
3. госты+стандарты+книги для расширенного понимания первых двух

p.s.
Alexander Lamdan утверждает, что

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

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

Раз тут уже посчитаны приоритеты вычисления - просто рекурсивно проходишься по каждому узлу, вычисляя его.

ключ 49 бит - log(66^8) - пусть для простоты 8байт, значение 32 байта (у тебя там hex строка)
только на значения тебе нужно 30 терабайта на каждый триллион - 32*10^12 и даже в идеальном случае еще 16тб на индекс ключа (чем больше оптимизируешь хранение тем больше операций на чтение и запись каждой)

Недавно была статья на хабре про тесты производительности работы mssql с похожими ключами миллионы записей

Я бы предложил схему с самописным индексом (мне кажется тут колхозить идеальнее всего).
* делишь ключ на 2 части (если бы ключ был не такой равномерный, то нужно было бы брать хеш от него), например по 4 байта
* младшие 4 байта (они наиболее равномерно будут распределены) - это номер блока в общем хранилище (на 1 триллион примерно 9кб, рекомендую. 16кб или 32кб, ssd на таких кластерах идеально работают), с массивом элементов: каждый из которых это вторые 4 байта ключа (старшие байты) + 32 байта искомое значение
для 16кб блока итоговое хранилище будет 70 тб - 2^32*16кб, можно прямо в дисковое устройство писать без файловой системы, по дискам пусть какой-нибудь рейд 0 раскидывает
* последняя запись в 16кб блоке - ссылка на дополнительное хранилище переполнений неравномерного распределения, его можно организовать как хочешь, на отдельном носителе

Итого на каждый запрос ты делаешь ровно одно чтение 16кб блока с диска, в полученном массиве ищешь нужный ключ и получаешь значение (если нет значит переполнения из-за неравномерного заполнения индекса, топать в дополнительное хранилище), кстати можно читать по секторно в процессе поиска, тогда если диск сумеет это оптимизировать будет 2х профит. Запись то точно так же - 1 чтение 16кб и запись 1 сектора диска, дозапись в массив. Кстати, если контролировать порядоковый номер ключевого значения (а что то мне говорит там будет простой перебор всех паролей) то будет последовательная запись блоков на диск, для hdd это идеальная ситуация. Иначе всю оперативную память используешь как самодельный lazy write буфер, при переполнении записываешь его на диск, отсортировав согласно дисковым устройствам и отсортировав порядок номеров секторов (тогда либо понимать как работает рейд либо самому раскидывать по дискам), операционные системы и контроллер диска это умеют но у них кеш маленький.

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

Добавь еще один уровень, будет 2 чтения по 8-16кб (когда ты не на 2 части делишь ключевое значение а на 3, первая часть ссылается на список ссылок на вторую часть, которые уже ссылаются на блоки с третьей частью), можно уменьшить этот оверхед но мне кажется скорость в твоей задаче важнее, ведь она упадет в два раза.
Универсальные базы данных делают многоуровневые древовидные индексы (это настраивается) и ради удобства и универсальности ты теряешь в скорости.

setCells((current) => current.map((entry) => ({
    ...entry,
    win: arr.includes(entry.id)
})));

const converter = {
  "m":{
    "cm":{k:0.01	},
    "in":{k:0.254	},
    "ft":{k:0.3048	},
  },

Тут можно улучшить. Если посмотреть на этот JSON документ с "прищуром". То можно увидеть
полносвязный граф. Например узел футов ("ft") имеет свое ребро в направлении дюймов ("in").
И все другие также.

Нужно ли нам описывать так много цифр? Я-бы предложил одну таблицу. Все меры длины отобразить на метры.
Тогда формула перехода ft -> in будет всегда идти через метрическую систему. ft -> m -> in.

А ребра графа мы все равно сможем получить но уже путем вторичных расчетов если надо.

Задача подростка учиться, что бы зарабатывать не 500р в день, а 500р в час хотя бы.

Схема подключения/соединения/коммутации "чего-то" (с "чем-то"|и "чего-то")?

Профессионализм не в том, чтобы взять очень умное слово, а в том, чтобы придумать однозначное и понятное название, которое будет понятно даже не профессионалу.

Вопрос снят, во время перерисовки компонента, создается новый ТестДебаунс, поэтому надо вынести его за компонент.

Если не используется сборщик, то лучше его взять. Могу посоветовать esbuild. Не знаю вашей задачи, можно и vite, у него под капотом esbuild

Если используете уже что-то, хоть тот-же webpack. То нужно понять почему не работает. Указано ли "type": "module" в package.json

Если нет возможности использовать сборщик, то вот обходной путь, но это такое себе:

config.js

export const options = {
  foo: 'bar'
}

main.js

import("./config.js").then((res) => {
  const { options } = res;
  console.log(options.foo);
});

Или даже так:

const initApp = async () => {
  const { options } = await import('./options')

  console.log(options)
}

initApp()

Привяжи их к одному стейту и будет тебе два тех же

На практике такие метрики могут означать лишь одно вы тренируете и тестируете на одних и тех же данных. Первое место для проверки

test_dataset = ASDataset(client_file="raw/client_train_raw.txt", imposter_file="raw/imposter_train_raw.txt", \
    transforms=preprocess)
train_dataset = ASDataset(client_file="raw/client_test_raw.txt", imposter_file="raw/imposter_test_raw.txt", \
    transforms=preprocess)
train_dataloader = DataLoader(train_dataset, batch_size=128, shuffle=True)
test_dataloader = DataLoader(test_dataset, batch_size=128, shuffle=True)

второе место для проверки естественно сам класс DataLoader.
ну и третье сами файлы что бы по запарке они не содержали одно и тоже содержимое.

В каком случае возможны такие метрики ну например данные на которых вы учитесь в них входная переменная это температура в цельсии а то что нужно "предсказать" температура в фаренгейтах. Ваши тестовые данные по структуре такие же но сам датасет алгоритм никогда не видел. На тех данных что алгоритм тренировался он благополучно выучит школьную формулу перевода из цельсии в фаренгейты и справится со 100 точностью. По простой причине в данная проблема состоит только из детерминистической составляющей, т.е вариативность отсутствует. (Данный пример специально примитивен. Это может и Unsupervised Learning это может задача где на вход "features" пойдут десятки переменных и.т.д лишь бы отсутствовала вариативность). Подобные примеры как этот будут выдавать такие метрики.