Когда элементов будет обработано 2001, окно с 1002 по 2001 будет расположено в индексах с 1 по 1000. Давайте покажу. Текущее окно подчёркиваю снизу стрелкой ^.
К тому времени, как массив заполнится до конца, у нас, помимо актуального окна, смещающегося к концу, появится почти полная копия этого же окна в начале:
Почти полная, потому что элементы с 1001 по 1999 — это 999 элементов, то есть как раз на один меньше, чем нужно. Но следующим шагом мы допишем этот элемент в конец и снова получим полноценное окно длины 1000, начинающееся с первого элемента массива:
Ну. Массив длины 1999. Сначала заполняю первые 1000 индексов. Потом при поступлении очередного значения записываю его в i-ю и (i+1000)-ю позиции. При такой организации процесса у меня всегда есть непрерывный подмассив, содержащий последние 1000 элементов (см. пример для N=3 в моём комментарии выше). С этим непрерывным подмассивом делаю что хочу.
Медиана — не очень практичный пример (для медианы проще держать две кучи), а вот, например, FFT — вполне.
Насчёт быстрее — это надо проверять. Но сдвиги подразумевают, что время обработки не размазано равномерно, а раз в сколько-то итераций "тормозит" — подозреваю, для потоковой обработки это нежелательно.
"Недостаток: сложность непрерывной обработки данных" — он ведь и для циклического массива присущ. Если функция обработки ожидает указатель на данные, идущие подряд в памяти — вызвать её нельзя. А это, например, BLAS/LAPACK и функции из прочих быстрых библиотек.
Если бы мне нужно было уметь очень быстро обрабатывать текущий буфер, я бы сделал массив длины с записью в два места сразу. Пример для N=3:
Одним-единственным ботом обойтись неудобно, если нужно одновременно чатиться с несколькими клиентами. Нужно как-то организовать в мессенджере множество чатов для агента. Можно было бы через группы с одним ботом сделать, но тогда их на каждого агента придётся индивидуальные плодить.
Подключить другой мессенджер можно. Нужно реализовать соответствующий фронтенд (клиентский или агентский). Можно по образцу телеграмного посмотреть, как он должен работать.
LLM-ка будет встраиваться в зависимости от того, как именно вы хотите её использовать. Подозреваю, что это будет изменение в бэкенде — классификация и либо отправление в очередь заявок как обычно, либо автоответ.
Я в шоке не столько от того, какой это глупый сексистский поток сознания, сколько от того, что Хабр постит это в свои соцсети. Хабр, ты норм? Может, хватит слово «айтишник» в унизительное превращать?
1) LoadBalancer приводит трафик на поды, поднятые ингресс-контроллером (т. е. непосредственно в контейнеры с nginx/traefik/...), а они уже смотрят на существующие в системе ингрессы и роутят куда нужно.
2) Если мы подняли сервис, балансировка будет происходить только если обращаться по урлу, соответствующему всему сервису — <имя сервиса>.svc.cluster.local. Но помимо такого урла Kubernetes создаёт урлы для всех подов сервиса, чем мы и пользуемся, обращаясь напрямую в statefulset-0.mongodb-service.default.svc.cluster.local. Такие урлы с фиксированными именами подов мы можем использовать для конфигурирования базы данных.
Не совсем понял. Чтобы получить произведение каждого разряда на множитель, вам уже нужно операций. В любом случае нужно умножить каждый разряд одного числа на каждый разряд другого.
Он легко обосновывается через арифметику по модулю! Берем число, скажем, 123. Нам нужно выяснить, равен ли нулю его остаток от деления на три. Раскладываем по десятичным разрядам и пользуемся свойством, что :
Когда элементов будет обработано 2001, окно с 1002 по 2001 будет расположено в индексах с 1 по 1000. Давайте покажу. Текущее окно подчёркиваю снизу стрелкой ^.
Сначала заполняем пустой массив:
Дальше, поскольку нам нужны только последние 1000 элементов, единичку можно затирать:
К тому времени, как массив заполнится до конца, у нас, помимо актуального окна, смещающегося к концу, появится почти полная копия этого же окна в начале:
Почти полная, потому что элементы с 1001 по 1999 — это 999 элементов, то есть как раз на один меньше, чем нужно. Но следующим шагом мы допишем этот элемент в конец и снова получим полноценное окно длины 1000, начинающееся с первого элемента массива:
Ну. Массив длины 1999. Сначала заполняю первые 1000 индексов. Потом при поступлении очередного значения записываю его в i-ю и (i+1000)-ю позиции. При такой организации процесса у меня всегда есть непрерывный подмассив, содержащий последние 1000 элементов (см. пример для N=3 в моём комментарии выше). С этим непрерывным подмассивом делаю что хочу.
Медиана — не очень практичный пример (для медианы проще держать две кучи), а вот, например, FFT — вполне.
Почему?.. По-моему, расходы памяти просто в два раза больше и всё.
Насчёт быстрее — это надо проверять. Но сдвиги подразумевают, что время обработки не размазано равномерно, а раз в сколько-то итераций "тормозит" — подозреваю, для потоковой обработки это нежелательно.
"Недостаток: сложность непрерывной обработки данных" — он ведь и для циклического массива присущ. Если функция обработки ожидает указатель на данные, идущие подряд в памяти — вызвать её нельзя. А это, например, BLAS/LAPACK и функции из прочих быстрых библиотек.
Если бы мне нужно было уметь очень быстро обрабатывать текущий буфер, я бы сделал массив длины
с записью в два места сразу. Пример для N=3:
Так я занимаю O(N) памяти, имею запись за O(1) и всегда имею на руках актуальный срез данных, расположенный в памяти линейно.
Нет, не рассматривал. Звучит интересно.
Привет!
Одним-единственным ботом обойтись неудобно, если нужно одновременно чатиться с несколькими клиентами. Нужно как-то организовать в мессенджере множество чатов для агента. Можно было бы через группы с одним ботом сделать, но тогда их на каждого агента придётся индивидуальные плодить.
Подключить другой мессенджер можно. Нужно реализовать соответствующий фронтенд (клиентский или агентский). Можно по образцу телеграмного посмотреть, как он должен работать.
LLM-ка будет встраиваться в зависимости от того, как именно вы хотите её использовать. Подозреваю, что это будет изменение в бэкенде — классификация и либо отправление в очередь заявок как обычно, либо автоответ.
Хороший старт!
В статью бы пару примеров кода, чтобы глазу было за что зацепиться.
Интерактив с названием статьи ?
Вы проверили этот подход на своей компании? Без описания личного опыта «плюсы сильно перевешивают минусы» не звучит достаточно веско.
Я в шоке не столько от того, какой это глупый сексистский поток сознания, сколько от того, что Хабр постит это в свои соцсети. Хабр, ты норм? Может, хватит слово «айтишник» в унизительное превращать?
Конкретно у меня нет, но материалов по теме много. Вот кто-то поддерживает Kubernetes-оператор для Кассандры, вот большая статья про подводные камни.
1) LoadBalancer приводит трафик на поды, поднятые ингресс-контроллером (т. е. непосредственно в контейнеры с nginx/traefik/...), а они уже смотрят на существующие в системе ингрессы и роутят куда нужно.
2) Если мы подняли сервис, балансировка будет происходить только если обращаться по урлу, соответствующему всему сервису —
<имя сервиса>.svc.cluster.local. Но помимо такого урла Kubernetes создаёт урлы для всех подов сервиса, чем мы и пользуемся, обращаясь напрямую вstatefulset-0.mongodb-service.default.svc.cluster.local. Такие урлы с фиксированными именами подов мы можем использовать для конфигурирования базы данных.А можно ссылку на Гиппарха? Интересно почитать
Ну, сами исследования все давно опубликованы, моя оригинальная тут только подача. Хотел написать с тех пор, как статья про алгоритм за
вышла.
Вы не согласны с тем, что это факт, или с тем, что он занимательный?)
Не совсем понял. Чтобы получить произведение каждого разряда на множитель, вам уже нужно
операций. В любом случае нужно умножить каждый разряд одного числа на каждый разряд другого.
Он легко обосновывается через арифметику по модулю! Берем число, скажем, 123. Нам нужно выяснить, равен ли нулю его остаток от деления на три. Раскладываем по десятичным разрядам и пользуемся свойством, что
:
При работе разработчиком каждый день нужно до чего-то догадываться!