Средняя температура

[AndyJ]

Цитата:

Может лучше умножать среднее на $N-1$, а результат суммирования делить на $N$ ?

Значит в одной из тех немногих цифр в "хранилище" должны хранить еще и "счетчик" N... И обрабатывать его "переполнение" (цифры большие, но не бесконечные и я не должен беспокоиться что через 3-5 лет произойдет переполнение буфера и "градусник" сломается и покажет не реальное число - например +400 градусов).

[Emergency]

AndyJ в сообщении #1535457 писал(а):

Значит в одной из тех немногих цифр в "хранилище" должны хранить еще и "счетчик" N... И обрабатывать его "переполнение"

Я не знаю зачем Александрович предлагает считать среднюю температуру за много лет - это бесполезная для быта информация.
А вот усреднять 10 последних дней не сложно $T_t(10)=(9T_{t-1}(10)+T_t)/10$
$T_t$ - текущая дневная температура
$T_t(10)$ - средняя температура за 10 дней, включающая сегодня
$T_{t-1}(10)$ - средняя температура на вчерашний день.
Понятно, что формула не точная и точность падает при больших скачках дневной температуры, зато в ней требуется запоминать лишь одно число - $T_t(10)$.

[AndyJ]

Цитата:

$T_t(10)$ - средняя температура за 10 дней, включающая сегодня

А где мы ее возьмем? У тебя всего доступно 3-5 "цифровых ячеек в памяти", которых хватит на чуть более высокую точность чем дает градусник. Например не 0.1 градус, а 0.0001.
Этой точности хватит чтобы сохранить некие "коэффициенты", но не хватит чтобы удержать 10 дней статистики.

Похоже моя задача сводится к "смягчению колебаний" температуры... Над этим сейчас и бьюсь в экселе, пытаясь "смягчить график", удерживая не больше 3х последних значений и некоторого плавающего/формульного коэффициента в 4й ячейке.

[Emergency]

AndyJ в сообщении #1535482 писал(а):

Похоже моя задача сводится..

К поиграться и забыть.

[AndyJ]

Цитата:

К поиграться и забыть.

Почему-же? Нет конечно...

(Оффтоп)

Я над этой темой работаю уже больше 3 лет (забрасывал на долго)! Конечно же тему "градусника" придумал конкретно для этой темы чтобы проще было пояснить остальным ТЗ. На самом деле это часть одного довольно сложного проекта. Раньше даже сделал нечто подобное. Куда более кривые формулы, одна из цифр хранила счетчик, который я принудительно сбрасывал каждые 100 срабатываний, было введено понятие "сезонов", которые менялись каждые 100 срабатываний. И получал явный "рывок" на графике "между сезонами". Причем эта формула часть куда более сложной формулы, которая тоже криво работала из-за нее, но в 70-80% случаев работала сносно. Тема настолько "чесалась"(нашел новое применение) что я наконец решился даже на ЭТОМ форуме совета попросить (на некоторых других, включая сайберфорум ответа не было - там чистые "кодеры", а не "математики" - долго планировал сначала поискать знакомых с кафедры "прикладной математики" в моем городе)

Пока что результаты уже получаются (в екселе) вполне сносными. Но там данных мало вмещается. И тестовые формулы крайне простые (чистый рандом в диапазоне или рандомное небольшое смещение от прошлого значения). Поэтому пишу программу-тестер на нормальном языке (JS) - с графиком, компонентами смены режимов, возможностью наложить результаты от разных режимов... Благодаря ЭТОМУ форуму по другому взглянул на задачу и смог зайти "с другой стороны". Раньше меня интересовало именно "среднее", а теперь скорее "сглаженное среднеее". Хочу протестировать на "сильно зашумленной синусоиде" или y=x*x+rand() - по идее должен ее "почистить".

[zykov]

AndyJ в сообщении #1535494 писал(а):

Я над этой темой работаю уже больше 3 лет

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

Если надо получить точное среднее по прямоугольному окну, то без кольцевого буфера на обойтись.
Но если достаточно какого-то приближения, то можно что-то поэкономичнее в плане памяти соорудить.
Как уже предлагали, можно в качестве приближения использовать усреднение с экспоненциальными весами.
Алгоритм тут простой. Хранится всего одно число, как текущее состояние. Обновляется линейно как $s=(1-k)x_i+k s$. Коэффициент $k<1$ близок к 1 и определяет длину усреднения (чем ближе к 1, тем больше окно усреднения). Можно параллельно несколько таких счётчиков вести с разными $k$. (Примерно $k=1-\frac{1}{\Delta T}$.)

А вообще в обработке сигналов используют IIR фильтры. Состояние может быть не одним числом, а вектором из нескольких чисел. Новое состояние вычисляется линейно из предыдущего состояния и небольшого количества нескольких последних входов $x_i$ (для них понадобится коротки кольцевой буфер).
Линейные коэффициенты подбираются исходя из требований к фильтру.

-- 19.10.2021, 21:16 --

Насчёт IIR, то можно попробовать соорудить фильтр у которого форма окна будет поближе к прямоугольной, чем у экспоненциального окна.
Хотя не знаю, так ли тут важна именно прямоугольность. Может экспоненциальной формы вполне достаточно.

[AndyJ]

Цитата:

Есть некоторая последовательность чисел (например температура по дням). Нужно в каждый момент выдать несколько других последовательностей примерно усредняющих исходную последовательность с разными длинами истории. При этом хотелось бы алгоритм с небольшим требованием по памяти (чтобы не хранить в кольцевом буфере всю историю какой-то изрядной длины).

Вы правильно поняли!
Температура может сильно "прыгать" вокруг некого среднего. Например летом средняя около 25 - ночью падает до 20, днем поднимается до 30. Если делать замеры каждый час то получим "волну". А нам надо запомнить "примерное среднее", а не 24 измерения в сутки. Логично получить "успокоенную волну".

К осени среднее упадет, а значит будет уже не около 25, а около 15. По сути, "успокоенная волна" никуда не делась, а просто приблизилась к нулю.

В результате всегда можно узнать "какая средняя температура за неделю" - и получить осенью 15, а летом 25... чтобы знать, например "пора ли готовить шубу?" не глядя на то что "сейчас 22 - это просто холодное лето, а не теплый замер осенью" )))
Позднее попробую в формулу еще и нечто похожее на "разброс по Гаусу" встроить )))

Проблема в том что для классических методов выявления "среденарифметического", в моей задаче сильно урезано "хранилище данных". В идеале до 3-5 значений или чуть более уточненных "коэффициентов", которые можно встроить в формулу для получения этого "среднего".

...ладно... ХВАТИТ МЕНЯ ОТВЛЕКАТЬ! У меня уже есть формула и советы (пока) по этой задаче НЕ НУЖНЫ... Теперь пытаюсь "отладочный проект на JS" под эту формулу сделать - буду тестировать на разных данных и с разными коэффициентами. Если на сработает, еще раз обращусь... ВСЕМ СПАСИБО за советы!

Цитата:

Линейные коэффициенты подбираются исходя из требований к фильтру.

Примерно так и делаю циклический список на 3 значения и цифра зависящая от прошлого среднего. И набор "множителей" для получения максимально сглаженного среднего. За одно множителями можно управлять "влиянием древней истории" на текущее среднее и пытаться игнорировать резкие всплески (10-12-10-200-11)

[zykov]

AndyJ в сообщении #1535494 писал(а):

На самом деле это часть одного довольно сложного проекта.

Общий метод понятен. А вот конкретные требования как раз определяются спецификой проекта, про который ничего не написано.

[Mihaylo]

Советник такого рода "надень шубу или шорты" - плохой советник. Ибо нужен прогноз погоды, а не исторические значения. Ну и часто от советника хотят мнение по поводу не текущего момента, а прогноз на завтра, на 10 дней вперед и т.д.