d'Ivan

Это называется кластеризация. Вам надо разбить данные на 3 кластера. Метод ближайших соседей, упомянутый выше, подходит.

Все-таки все эти методы кластеризации разработаны для более общего случая. А у вас тут данные одномерные и численные уже - так что все совсем просто.

Во-первых, данные надо отсортировать, если уже не. А дальше у вас тут 2 переменные - (i,j) - первый и последний элемент в средней группе.i>0,j<n-1.

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

Но вообще можно, наверно, просто взять 2 максимальных промежутка между соседними числами и по ним разделить. В примере выше этот метод отлично разбивает на 3 группы: 1-103, 999-1001, 9000-9500

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

let [dataRu,dataEn] = await Promise.all([getProductsDataRu(urls),getProductsDataEn(urls)])

зачем там реализуют разные модули, типа кеша, вроде в каком-то даже увидел конвеер исполнения команд, предсказатели переходов. И прочие. К примеру кеш, тлб, зачем он там нужен. если все как бы просиходит внутри машины?

Фронт-енды QEMU реализуют большую часть наблюдаемого поведения моделируемого ими процессора. Одно большое исключение -- это процессорный кеш: QEMU не моделирует поведение процессорного кеша. TLB во многих архитектурах доступен для прямого чтения/записи через команды процессора, нельзя сказать что он "внутри машины".

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

Покажи пример, обсудим конкретику?

Ассоциативная память. Если там внутри делается таблица адресов, виртуальных адресов. То к примеру для адресного пространства 4гб, будет 2^32 это будет в 32 раза дольше.

Это какие-то очень странные допущения и прикидки, а то, что они не учитывают такие параметры как размер TLB и его ассоциативность, показывает их безосновательность.

Короче, в итоге для поиска адреса в супер жесткой виртуальной машине, будет до 32 операции сравнений по словарю, потом суммарно где же в кешах каждого уровня, куча прочих проверок .... .

Нифига. В QEMU есть два уровня TLB -- один, моделируемый процессорным фронт-ендом, второй -- собственный TLB QEMU softmmu независимый от эмулируемого процессора, поиск по которому встроен в генерируемый JIT (который в QEMU называется TCG) код. Собственный TLB QEMU прямого отображения, т.е. поиск в этом TLB -- это всегда проверка одного элемента массива и загрузка одного отображения в случае успеха. Например вот так генерируется код для этого на хосте x86. В случае неудачи происходит вызов функции поиска в архитектурно-зависимом TLB. Вот так этот вызов генерируется, а вот пример его реализации во фронт-енде. Поскольку этот TLB моделирует конкретную архитектуру его ассоциативность может варьироваться в широких пределах, или он может вообще отсутствовать. В случае промаха или отсутствия TLB поиск может либо продолжаться дальше в таблицах страниц, например так, либо фронт-енд генерирует исключение доступа к памяти, например так.

В итоге операций при поиске трансляции для виртуального адреса может быть гораздо больше чем 32, которые ты предположил, в случае промахов, но цена промахов амортизируется тем, что чем более они дороги, тем более они редки. Но, конечно, задача намеренно обращающаяся к никогда не повторяющимся страницам памяти будет иметь очень низкую производительность при выполнении в QEMU softmmu.

Как-то так

хватит школьных знаний

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

Идея простая.
Асинхронные приложения - это набор пар "операция - обработчик", где операция - это некоторый длительный процесс (скажем, вводы/вывод), который не требует постоянного внимания со стороны кода. Когда операция завершается, выполняется её обработчик. Этот обработчик может планировать другие операции, и так далее.

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

Соответственно, await-вызов сохраняет текущий контекст корутины, и планирует новую длительную операцию. Какую - зависит от того, что идёт после await. Эта операция представлена тем или иными awiatable значением (Future, Task и т.п.).

Рабочий цикл (loop, его также называют реактор) просто проверяет текущие операции. Как только одна из них завершилась, он выполняет её обработчик. А потом продолжает проверять остальные активные операции.

Ключевой момент - выполняет обработчик, а только потом проверяет остальные операции. Т.е. если обработчик планирует операцию через await - это не проблема, она будет выполняться наравне с остальными. А вот если обработчик просто делает что-то длительное, он не возвращает управление циклу, и не даёт выполняться остальным операциям.

asyncio.sleep() планирует ничего не делающую операцию, которая завершится успехом через заданное время. Поэтому её выполнение не мешает циклу-реактору. Просто ещё один await вызов, который приостанавливает текущую корутину и возвращает управление реактору.

time.sleep() ничего не знает о реакторе и асинхронных операциях. Она приостанавливает выполнение обработчика, не прерывая его и не отдавая контроль реактору. Поэтому на время time.sleep() (или любой длительной синхронной операции) спит вся программа.

Это не фильтр и даже не фотография. Это векторное изображение, где каждый объект автор окрасил в желаемый цвет.
https://www.shutterstock.com/ru/image-vector/horiz...

Ну и дополню:

• сделать/перекрасить такое же векторное изображение можно в любом векторном редакторе — Adobe Illustrator, Corel DRAW, Inkscape и др.;
  
• обрабатывать растровые изображения (фото) можно в Adobe Photoshop, Lightroom, Corel Painter и др.
  

Если вообще не знаете ничего, то поищите уроки по созданию желаемого эффекта и пробуйте повторить в той программе, которую использует автор.

Поудаляй все базы графаны и прометеуса. Это вернет компоуз в некое нулевое состояние с которого ты начинал.

Для решения любой проблемы нужно смотреть в суть этой проблемы. Напишите

$response = json_decode($response, true);
var_dump($response);
$arResult = json_decode($response, true);
var_dump($arResult);

Смотрите на результат и делайте выводы.