для каждой точки вычисляется медиана и стандартное отклонение (std) внутри скользящего окна заданного размера (window_size). Точка считается аномалией, если её значение отклоняется от медианы больше, чем на alpha * std
Куда интересней, а чем заменять обнаруженную аномалию? Можно аномалию выкидывать, обрабатывая её затем, как пропуск. А можно ограничиться обычным медианным фильтром или арифметическим сглаживанием, который, возможно, даст лучший результат, чем фильтры примененные на этапе заполнения пропусков. В случае концентрации аномалий преимущественно в прошлом, есть смысл применять несколько вариантов, один из которых выиграет при кроссвалидации.
Образовавшиеся пропуски заполним с помощью TimeSeriesImputerTransform
А вот этот момент хотелось бы узнать подробней. Например, в большинстве случаев предпочитаю заполнять пропуски фильтром Калмана. Но выбор фильтра для меня тут очень интересная тема.
Теперь проявляется вся мощь пайплайна: для масштабирования достаточно передать новые данные в уже настроенные цепочки преобразований
Это, обычно, у меня не срабатывает. Точнее, срабатывает, но только если все временные ряды похожи. На практике же для каждого временного ряда приходится подобрать свой метод прогнозирования, который выиграл кроссвалидацию на конкретном временном ряде.
P.S. Я не DS, а просто разработчик. На DS не тяну, так как тензорное исчисление, математическое программирование и математическую статистику знаю на четверку, а для DS явно требуются знания на пять с плюсом. Чтобы будучи ученым (scientist) общаться хотя бы c к.т.н. экспертом-математиком на одном языке, не задавая глупых вопросов, которые приходится порой задавать мне.
За то, что бы признать 10 тыс. рублей доходом - ФНС биться не «будет».
А за сколько будет? Если я ежемесячно подбрасываю 10 тыс. своему внучатому племяннику, который вообще-то круглый сирота, его могут заставить платить налог?
Лично для меня куда интересней был бы поиск наличия пересечений одного диапазона с одним из множества других. Скорее всего, оптимально это можно сделать с использованием R-Tree, но не исключаю и иные вариант.
Просто не возвращайте соединение в пул, продолжая его использовать. Излишние DISCARD ALL (по сути, последовательность из девяти команд) в данном случае только вредят.
“процесс/соединение живо” ≠ “воркер делает progress”
Зависит от настроек соединения. При правильных настройках для конкретного сценария использования соединение не долго будет висеть открытым.
Heartbeat решает именно это: “если давно не пинговал — считаем мёртвым”, даже если TCP/процесс жив.
Но создает транзакции, модифицирует БД и пишет в WAL, загружая не только сервер, но ещё и его реплики в кластере. Тогда как установив необходимый idle_session_timeout для своей сессии можно добиться того же самого, посылая команды не порождающие транзакции и модификации БД. Например, SHOW.
Есть даже институты переподготовки и повышения квалификации, куда принимают только с дипломом о высшем образовании. В качестве исключения - по академической справке о неоконченном высшем образовании.
есть только последнее
Каким образом диплом экономиста может отменить диплом инженера-схемотехника?
Если вместо (или кроме) абстрактного worker_id фиксировать в таблице pg_backend_pid(), то никакого heartbeat не требуется. Достаточно по pg_stat_activity проверять наличие pid и сравнивать backend_start с временем последней модификации задачи. Если backend_start больше времени модификации задачи или такого pid нет в pg_stat_activity, то процесс умер и блокировки нет.
В моей жизни был так же период работы аналитиком. Для этого мне пришлось получать второе высшее образование - экономическое. На множестве других проектов мне порой самому приходилось искать в команду аналитиков. И опять главным требованием было глубокое понимание проблемной части: экономики, энергетики, логистики, производства и т.п. А уж обучить до необходимого аналитику уровня SQL и Python куда проще, чем, для примера, технологии производства минеральных удобрений или экономической основы формирования цен для ПСДЦ.
Это субъективно и зависит от контекста. При этом я специально указал, как при помощи того же самого udev делать идентификацию не только по serial, но и по devpath. Вы возражаете против свободы выбора?
Тут первая строка - для встроенного в мой ноут второго порта USB3.0. Вторая - для шестого порта внешнего семипортового USB3.0 хаба. Третья - для седьмого порта того же хаба.
Лично для меня идентификация только по by-path не кажется удобной, так как при наличии большого количество устройств не очень-то поймёшь, куда какой воткнул.
Зато, для примера, ESP32-С3 замечательно идентифицируются по серийному номеру, что позволяет давать произвольные имена устройствам.
Bus 001 Device 015: ID 303a:1001 Espressif USB JTAG/serial debug unit
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 [unknown]
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x303a Espressif
idProduct 0x1001 USB JTAG/serial debug unit
bcdDevice 1.01
iManufacturer 1 Espressif
iProduct 2 USB JTAG/serial debug unit
iSerial 3 80:65:99:2D:19:64
На всякий случай, приведу пример использования. Создаем файл /etc/udev/rules.d/91-esp32.rules с содержимым:
Вы заблуждаетесь. В случае императивного языка, результирующий код однозначно определяется исходным кодом и используемым компилятором, включая его опции компиляции. В случае же декларативного языка, результирующий код очень сильно зависит от окружения перед его выполнением.
В случае SQL, план запроса определяется, как минимум, значениями статистик в БД на момент начала выполнения запроса. То есть, планы двух одинаковых SQL запросов, даже на одной и той же БД, могут сильно отличаться друг от друга. И это нормально.
Насколько я понял, описываемое решение применяется в случаях, когда 16 или более прерываний в секунду (раз в 64 мс) - это слишком часто. Я с такими случаями не сталкивался, но исключить их возможность не могу.
Прерывания раз в час (или раз в 71 минуту) уж точно навредить не могут, поэтому просто старшие 32 бита счетчика храним в памяти и оперируем 64-битным значением, которое за время существования нашего МК точно не переполнится.
Если же прерывания по переполнению таймера раз в 64 мс допустимы, то можно использовать 16-битный таймер и тоже 32 бита счетчика в памяти. 48 бит хватит лет на шесть, так что раз в 5-6 лет надо будет перезагружаться, что выглядит некритичным ограничением.
Тогда не получилось, так как рекорд meshtastic сейчас 331 километр.
Куда интересней, а чем заменять обнаруженную аномалию? Можно аномалию выкидывать, обрабатывая её затем, как пропуск. А можно ограничиться обычным медианным фильтром или арифметическим сглаживанием, который, возможно, даст лучший результат, чем фильтры примененные на этапе заполнения пропусков. В случае концентрации аномалий преимущественно в прошлом, есть смысл применять несколько вариантов, один из которых выиграет при кроссвалидации.
А вот этот момент хотелось бы узнать подробней. Например, в большинстве случаев предпочитаю заполнять пропуски фильтром Калмана. Но выбор фильтра для меня тут очень интересная тема.
Это, обычно, у меня не срабатывает. Точнее, срабатывает, но только если все временные ряды похожи. На практике же для каждого временного ряда приходится подобрать свой метод прогнозирования, который выиграл кроссвалидацию на конкретном временном ряде.
P.S. Я не DS, а просто разработчик. На DS не тяну, так как тензорное исчисление, математическое программирование и математическую статистику знаю на четверку, а для DS явно требуются знания на пять с плюсом. Чтобы будучи ученым (scientist) общаться хотя бы c к.т.н. экспертом-математиком на одном языке, не задавая глупых вопросов, которые приходится порой задавать мне.
Жене когда-то присылали в личный кабинет налогоплательщика на сайте ФНС.
А за сколько будет? Если я ежемесячно подбрасываю 10 тыс. своему внучатому племяннику, который вообще-то круглый сирота, его могут заставить платить налог?
Лично для меня куда интересней был бы поиск наличия пересечений одного диапазона с одним из множества других. Скорее всего, оптимально это можно сделать с использованием R-Tree, но не исключаю и иные вариант.
По сравнению, для примера, с утерей накоплений в ценных бумагах или (крипто)валюте - это меньшая из бед.
Доступ к содержимому может и получат, но расшифруют ли его не зная паролей к ключам, использованным для шифрования?
Спасибо, не надо, так как стоимость поддержки такого решения будет астрономической.
Про то и речь, что конкретные задачи возникают чуть ли не каждую неделю
Просто не возвращайте соединение в пул, продолжая его использовать. Излишние DISCARD ALL (по сути, последовательность из девяти команд) в данном случае только вредят.
Зависит от настроек соединения. При правильных настройках для конкретного сценария использования соединение не долго будет висеть открытым.
Но создает транзакции, модифицирует БД и пишет в WAL, загружая не только сервер, но ещё и его реплики в кластере. Тогда как установив необходимый idle_session_timeout для своей сессии можно добиться того же самого, посылая команды не порождающие транзакции и модификации БД. Например, SHOW.
Не складыватся
Есть даже институты переподготовки и повышения квалификации, куда принимают только с дипломом о высшем образовании. В качестве исключения - по академической справке о неоконченном высшем образовании.
Каким образом диплом экономиста может отменить диплом инженера-схемотехника?
Если вместо (или кроме) абстрактного worker_id фиксировать в таблице pg_backend_pid(), то никакого heartbeat не требуется. Достаточно по pg_stat_activity проверять наличие pid и сравнивать backend_start с временем последней модификации задачи. Если backend_start больше времени модификации задачи или такого pid нет в pg_stat_activity, то процесс умер и блокировки нет.
В моей жизни был так же период работы аналитиком. Для этого мне пришлось получать второе высшее образование - экономическое. На множестве других проектов мне порой самому приходилось искать в команду аналитиков. И опять главным требованием было глубокое понимание проблемной части: экономики, энергетики, логистики, производства и т.п. А уж обучить до необходимого аналитику уровня SQL и Python куда проще, чем, для примера, технологии производства минеральных удобрений или экономической основы формирования цен для ПСДЦ.
Это субъективно и зависит от контекста. При этом я специально указал, как при помощи того же самого udev делать идентификацию не только по serial, но и по devpath. Вы возражаете против свободы выбора?
В случае отсутствия серийного номера, как для CH340, действительно приходится ориентироваться на by-path. Но для этого тоже достаточно udev. Например:
Тут первая строка - для встроенного в мой ноут второго порта USB3.0. Вторая - для шестого порта внешнего семипортового USB3.0 хаба. Третья - для седьмого порта того же хаба.
Лично для меня идентификация только по by-path не кажется удобной, так как при наличии большого количество устройств не очень-то поймёшь, куда какой воткнул.
Зато, для примера, ESP32-С3 замечательно идентифицируются по серийному номеру, что позволяет давать произвольные имена устройствам.
На всякий случай, приведу пример использования. Создаем файл /etc/udev/rules.d/91-esp32.rules с содержимым:
Перезагружаем правила udev
Подключаем ESP32-C3 с серийным номером, указанным выше и видим симлинк /dev/gate_control_dev_1
Это решение не применимо, когда пароли для различных сервисов приходится вводить на самых различных серверах, на которые зашел по ssh, vnc или rdp.
Хорошо, если есть возможность аутентификации по ключу или через локальный keytab. А если нет?
Вы заблуждаетесь. В случае императивного языка, результирующий код однозначно определяется исходным кодом и используемым компилятором, включая его опции компиляции. В случае же декларативного языка, результирующий код очень сильно зависит от окружения перед его выполнением.
В случае SQL, план запроса определяется, как минимум, значениями статистик в БД на момент начала выполнения запроса. То есть, планы двух одинаковых SQL запросов, даже на одной и той же БД, могут сильно отличаться друг от друга. И это нормально.
Насколько я понял, описываемое решение применяется в случаях, когда 16 или более прерываний в секунду (раз в 64 мс) - это слишком часто. Я с такими случаями не сталкивался, но исключить их возможность не могу.
Прерывания раз в час (или раз в 71 минуту) уж точно навредить не могут, поэтому просто старшие 32 бита счетчика храним в памяти и оперируем 64-битным значением, которое за время существования нашего МК точно не переполнится.
Если же прерывания по переполнению таймера раз в 64 мс допустимы, то можно использовать 16-битный таймер и тоже 32 бита счетчика в памяти. 48 бит хватит лет на шесть, так что раз в 5-6 лет надо будет перезагружаться, что выглядит некритичным ограничением.
Не равно. Для C это !=
P.S. Извиняюсь, что не уточнил. Последнее время у меня очень много кода, где <> встречается чаще, чем !=