Комментарии 12
Без знания теории код не сильно полезен. Ну, у вас он что-то считает. Будет ли он применим не только для топливных датчиков? Нет ли там чего-то гвоздями прибитого?
А кто знает теорию, тому проще написать самому чем адаптировать чужое.
Соглашусь.
Хотелось бы видеть пояснения к алгоритму. Желательно с каким-то матобоснованием.
Тут даже не совсем понятно (не зная C#) - вот мы взяли "стандартное окно", посчитали среднее, посчитали СКО - что дальше? Новое значение СКО будет действовать для следующего окна, или вводится коррекция и пересчет текущего?
Также не понятно будет ли это работать для потокового режима работы - когда у нас еще нет всех данных. Т.е. вот идет поток данных и он "на лету" сглаживается - как тут быть?
В общем, приведет какой-то кусок кода совершенно без объяснения почему именно так.
В общем, приведет какой-то кусок кода совершенно без объяснения почему именно так.
Имхо, это главный недостаток очень многих подобных статей. Возможно, в данном случае автор посчитал, что теория тривиальна и общеизвестна. Однако математика - это
такая штука
что заглянув в любой тихий омут, оттуда запросто можно выскочить с криками "тысяча чертей!!!"
что копать можно почти в любом месте, и там откроется бездонная глубина. Я не претендую на особую глубину... но если интересно чуть поподробнее, то кое-какие идеи ляпнул в соседней ветке
Спасибо, вы кодом, приведённым в статье, подняли мне самооценку)
При усреднении данных происходит их потеря с обоих концов исходного массива.
С философской точки зрения, это совершенно не обязательно. Например, мы заменяем отсутствующие точки на Nan, а затем работаем с сигналом так, будто он бесконечный. После любой фильтрации длина ряда
остается такой же, как была
Точнее, у нас есть еще одна настройка - это разрешенный процент пропусков в окне. Если она задана равной нулю (т.е. пропуски запрещены), то алгоритм работает по классике: длина ряда уменьшается на половину окна на обоих концах. Фишка в том, что эту настройку можно менять от 0 до 99.9999%, и получать результат, оптимальный для текущей задачи
Идея в том, что обработка пропусков внутри ряда и на его границах идет по совершенно одинаковым алгоритмам
Подробнее
Вот пара статей, где можно об этом почитать (раз, два), а вот тут можно взять их полные тексты. Опенсорсная программа для Винды, в которой эти идеи реализованы, лежит вот тут. Но, там внутри есть не только сглаживание, а еще дохрена всякой другой ерунды, поэтому порог вхождения -
не пожелаешь врагу
это конечно лишь мое маргинальное мнение... но учитывая, что я не только автор проги, но и ее самый активный пользователь (с 30-летним стажем), советую все же прислушаться ;-)
А исходники к этой программе лежат вот тут. Но, WARNING-WARNING-WARNING: там все написано а) на фортране и б) научными сотрудниками, а не программистами. Поэтому слабонервным лучше посмотреть основные идеи (например, там же в архиве WinABD_Help.zip закопана справка к программе, она чуть подробнее, чем упомянутые статьи) и сделать самостоятельно ;-)
А кто знает теорию, тому проще написать самому чем адаптировать чужое.
Именно так ;-)
Простейшим решением является добавление одной или нескольких точек близких к уже вычисленным данным.
Так у Вас будет смещение, если на краю ряда присутствует заметный тренд. Сглаженный ряд загнется к горизонтали (кстати, на Вашем графике "Результат работы алгоритма" оно хорошо видно слева). Чтобы этого избежать, можно
Ваш комментарий навел на мысль. Есть же понятие "выбросов", которые нужно откидывать и "доверительного интервала" (те же "три-сигмы", например).
Т.е., условно говоря так: берем окно, считаем сигму. Дальше откидываем те точки, которые выходят за границы доверительного интервала, по оставшимся считаем среднее.
Но тут надо сразу оговориться, что все это будет работать только в случае линейной зависимости. Для нелинейных искажение линии тренда могут оказаться слишком велики - чем более нелинейно и больше окно, тем больше искажения в сторону спрямления линии тренда. Там лучше будет работать экспоненциальное (двойное, тройное...) сглаживание.
Ну, или если заморочиться, то можно приспособить фильтр Ходрика-Прескотта хотя он не очень прост в реализации.
А в целом, на небольших окнах, выбросы неплохо режутся обычной медианой.
Но тут надо сразу оговориться, что все это будет работать только в случае линейной зависимости.
Так ведь никто не запрещает считать тренд в окне одной ширины, сигму в другом и т.д. Чтобы подобрать должную адаптивность на случай нелинейности тренда (и аналогично в других ситуациях). Даже больше скажу, мы сами обычно именно так и делаем. То есть, настройки каждой процедуры подгоняются под свойства сигнала индивидуально. А итоговый алгоритм строится путем последовательного применения этих всех процедур.
А в целом, на небольших окнах, выбросы неплохо режутся обычной медианой.
Дьявол, как обычно, в соотношении амплитуды тренда и выбросов. Мы поэтому чаще всего работаем по итеративной схеме. Причем, если на некотором шаге мы ищем выбросы, то на этой стадии все остальное, что есть в сигнале,
считается вредной гадостью
Которая мешает эти выбросы идентифицировать максимально качественно.
В ходе "чистки" этой "гадости", в частности, убираются тренды и др. Только после этого каким-либо способом строится собственно детектор выбросов.
А вот дальше ключевой момент: построенный под спойлером детектор выбросов применяется не к сигналу, очищенному от "гадости", а к исходному ряду (который с трендами и т.д.). Итого мы, с одной стороны, создаем максимально комфортные условия для работы детектора выбросов (и тогда не так уж важно, как именно он устроен), а с другой - после выбраковки выбросов получаем ничем не искаженный сигнал. Перефразируя одну известную присказку сомнительного происхождения, в нем убраны только выбросы, все выбросы, и ничего, кроме выбросов ;-)
Чуть подробнее
эта идея описана вот в этой статье (PDF тут).
Но, мне-таки легко давать такие советы, работая с уже лежащими в базе данных рядами. Чтобы прикрутить эти идеи к real-time, наверняка придется изобретать какие-то трюки или от чего-то отказываться...
...можно приспособить фильтр Ходрика-Прескотта
Лично мое мнение - что любые многокомпонентные модели такого рода почти всегда дают худшее качество обработки (декомпозиции), чем комбинация гораздо более простых нативных алгоритмов, применяемых, в идеале, итеративно. Наиболее очевидная причина в том, что входящие в комбинированную модель составляющие обычно не ортогональны. Что сразу же влечет целую кучу багов. Ну и просто реальная погрешность оценки параметров у комбинированной модели почти всегда много хуже. Тут фишка в том, что внутримодельные оценки точности результатов (которые любая правильная прога всегда печатает по окончании расчетов) в 99% случаев завышены,
причем чаще всего многократно
Формальная причина в том, что условия применимости почти любой матмодели не соблюдаются с достаточной строгостью почти никогда. Но что еще важнее, эти погрешности по определению не включают ошибку, связанную с неправильным выбором самой модели. А чем сложнее модель, тем сложнее именно эту ошибку оценить независимо.
Фактически те оценки погрешности, которые дает нам любая модель, надо трактовать, как условные: ЕСЛИ тренд действительно линейный, то погрешность коэффициента "a" вот такая... А если нет? Именно поэтому мы никогда не можем оценить тренд, экстраполировать его вперед и сказать "ошибка прогноза = 0.00000xxx", несмотря на то, что программа экстраполяции линейного тренда вывела на печать ровно "0.00000xxx". Ну или точнее сказать-то можем, только потом будет стыдно ;-) И это будет вовсе не ошибка кривой программы, а сугубо наша ошибка (приняли условную оценку за безусловную).
За подробностями
опять-таки отошлю к разделам I3 и I4 файла WinABD_Help.chm, который лежит вот тут.
При работе с "элементарными" (тривиальными) микро-моделями получить реалистичную оценку погрешности значительно проще. А это, имхо, едва ли не важнее, чем уменьшить эту погрешность. Собственно, я тут только что пытался высказываться на эту тему вот в этом комменте.
С другой стороны, далеко не все задачи требуют "ловли блох", когда затрата суперусилий для улучшения результата на пару десятков процентов будет оправданна. В тех случаях, когда речь не идет о критически важных моментах, наверное лучше (и проще) взять готовенький "черный ящик" и прикрутить его к своей системе, не особо парясь - что там внутри. Но это только Вы можете сами решить: никакой посторонний со стороны тут ничем не поможет...
Мне в свое время приходилось немного заниматься чисткой GPS данных. Там основная проблема в том, что нет никакой линейности и вообще никакой модели. И при этом, чем меньше скорость, те выше уровень шума. Стоя на месте вы вообще не поучите точку - позиция будет постоянно "гулять" ("дрейф позиции"), причем, с достаточно большей амплитудой (до десятков метров порой). А фильтровать надо 5 параметров - 3 координаты, скорость (которая в современных приборах определяется отдельно, по допплеровскому смещению частоты) и направление. Это то, что приходит с прибора в виде непрерывного потока данных.
Много чего перепробовал, но на 100% удовлетворительного решения так и не нашел, особенно в отношении дрейфа - направление и скорость тоже дрейфуют, зацепиться не за что.
Правда, сейчас все это уже в прошлом, так что интерес остался чисто теоретический.
Извиняюсь за оффтоп, но
может быть, что-нибудь посоветуете?
Есть два временных ряда (два датчика), просто в виде меток времени (относительных, отсчёт от момента родачи питания). Метки времени сигнализируют о возникновении события, которое регистрируется датчиками. Датчики никак не связаны, имеют свою частоту опроса (частоты, вообще говоря, могут быть не кратны; период может слегка плавать). Соответственно, интервал времени между двумя зарегистрированными событиями у датчиков может отличаться. Некоторые события могут быть зарегистрированными одним датчиком, но пропущены другим (обычно таких немного, но может случиться пропуск нескольких подряд). Количество событий достаточно большое (сотни).
Можете посоветовать способы корреляции таких рядов (хотя бы названия методик или в какую сторону копать)?
У нас в институте есть такой А.А.Любушин, у него один из основных коньков - это как раз поиск корреляций между точечными процессами. Очень похоже на Вашу задачу.
Между прочим
его методика анализа микромейсмического шума примерно за год до Тохоку (японское мегаземлетрясение 2011г) показала очень сильные аномалии в районе будущего очага, и он это все опубликовал еще до землетрясения. Фактически, это наполовину прогноз: место и сила будущего события оцениваются достаточно хорошо. Но, к сожалению, для практического использования такой прогноз пока не пригоден, так как время землетрясения прогнозируется на уровне "ожидается в течение года" (такие ограничения у методики).
Так вот, как раз на днях А.А. выложил свою программу для поиска корреляций между точечными потоками событий. Пересылаю его сообщение из
нашей внутриинститутсуой рассылки
Уважаемые коллеги!
Хочу обратить ваше внимание на программу оценки взаимного влияния 2-х точечных процессов. Вот описание метода в форме инструкции пользователя на русском языке:
https://alexeylyubushin.narod.ru/Software_for_Monitoring_Systems/LinShares/LinShares_RUS.pdf
а вот сама программа в виде загрузочного модуля (exe-файл):
http://alexeylyubushin.narod.ru/Software_for_Monitoring_Systems/LinShares/LinShares.zip
Эта программа (матрицы влияния) является упрощенным вариантом более общей программы для анализа связей между несколькими сейсмическими последовательностями (1994):
https://alexeylyubushin.narod.ru/LinearModel_InteractionProcesses.pdf
Эта программа дает прекрасный инструмент для анализа связей между каким-то точечным процессом, типа последовательности землетрясений, и характерными временными точками протекания какого-нибудь важного временного ряда, типа локальных максимумов амплитуд огибающих или локальными экстремумами свойств временных рядов систем мониторинга.
Программа была использована в следующих недавних статьях:
1) для анализа связей между локальными экстремумами свойств глобального низкочастотного сейсмического шума и последовательностью землетрясений с магнитудой не ниже 7 (2022):
https://alexeylyubushin.narod.ru/Global_Seimic_Noise_Prop.pdf
2) для анализа связей между точками локальных максимумов отклика свойств сейсмического шума в Японии на неравномерность вращения Земли и последовательностью землетрясений с магнитудой не ниже 6 (2023):
https://alexeylyubushin.narod.ru/Seismic_hazard_indicators_Japan.pdf
3) для анализа связей между локальными экстремумами отклика вейвлет-корреляций флуктуаций глобального магнитного поля (сеть INTERMAGNET) на неравномерность вращения Земли и последовательностью землетрясений с магнитудой не ниже 7 (2024):
https://alexeylyubushin.narod.ru/Wavelet-based_correlations_of_the_global_magnetic_field.pdf
4) для выделения прогностических свойств локальных максимумов мгновенных амплитуд тремора земной поверхности в Японии, вычисляемых с помощью разложения Гильберта-Хуанга (2024):
https://alexeylyubushin.narod.ru/Prognostic_properties_amplitudes_maxima_earth_tremor.pdf
5) для выделения прогностических свойств локальных максимумов квадратичных когерентностей между показаниями 2-х крутильных маятников Кавендиша на базе 3000 км (Москва и Новосибирск) (2024):
https://portal.ifz.ru/journals/ntr/103-1/fulltext/02-NTR-103-1.pdf
Добавлю еще про оценки сейсмической опасности в Японии по свойствам низкочастотного сейсмического шума, представленных в презентации (обновляемой ежемесячно) по адресу:
https://alexeylyubushin.narod.ru/Prognostic_properties_seismic_noise_Japan.pdf
Там использование этой программы представлено на слайдах 12-18, из которых наиболее важен результат на слайде 16, из которого следует, что сейчас Японские острова находятся в стадии повышенной сейсмической опасности.
С уважением, А.А. Любушин.
Не уверен, что там решается в точности Ваша задача, но идеи очень близкие. Посмотрите, наверняка что-нибудь почерпнете. Если возникнут вопросы насчет
прямого использования алгоритмов/программ в каких-то продуктах
то у нас в научной среде обычно это приветствуется при условии ссылки на автора. Ну или если возникнут сомнения, всегда можно напрямую к автору обратиться за разъяснениями. Пишите в личку, я попробую вас связать
P.S.
Извиняюсь за оффтоп, но (...)
Лично мое мнение, что оффтоп - это когда Вы без предупреждения вставляете неудачную обидную шутку, не имеющую прямого отношения к вопросу. За такое тут и правда иногда минусуют... Но чтобы назвать офтопом вопрос по временным рядам в посте про временные ряды?!??
var windowSize = Math.Max(1, baseWindowSize + (int)(stdDev / 10));
здесь точно надо сложить количество точек со средним отклонением данных? А если точек будет 10, а среднее отклонение 500?
Функция скользящего среднего для регенерации на графике