именно это и имелось в виду 

протестил... как и педполагалось все это дело оч неустойчиво.... т.е. например приходят у меня точки и вдруг происходит резкий всплеск, и аглорит уже пререстает выдавать корректное значения которое он держал до этого... хотелось бы сделать его более устойчивым к таким вещам... и все равно я склоняюсь к теории фильтрации, вот только одна беда - я в ней полный 000... нашел какой-то курс лекций по теориии управления (http://window.edu.ru/window_catalog/files/r24738/5.pdf), вот там на 74 странице описываются фильтры, только там такие страшные формулы, просто нереально разобраться как это можно реализовать...

вообще наверняка есть люди которые разбираются во все этом... где же вы?!))

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

Это сообщение отредактировал(а) maxim1000 - 18.10.2006, 14:24

ммм даа.... тупик какой-та

кстати, пришла мысль:
нужно чётко разделить два случая:
1. характеристики сигнала могут меняться во времени
2. характеристики сигнала постоянны
в первом случае резкий скачёк сигнала и должен восприниматься алгоритмом, как симптом изменения параметров сигнала
во втором случае сама идея "бОльшего доверия последним значениям" неправильна
для второго случая основной проблемой, как мне видится, есть банальное переполнение аккумуляторов переменных S
тогда можно, например, сделать так:
1. после каждых 10 (к примеру) отсчётов считать для них весь набор переменных S
2. тогда для того, чтобы подсчитать S для последних 20 отсчётов достаточно взять среднее арифметическое от этих "10-отсчётных" S и предыдущих (их можно хранить)
3. для 20 отсчётов понадобится ещё одна копия
таким образом, размер требуемой памяти будет пропорционален логарифму количества отсчётов, которое мы захотим учитывать, а то - не так уж и много...

касательно ошибок способас затуханием - нужно хорошенько поэкспериментировать с коэффициентом затухания
если алгоритм слишком чувствителен к скачкам, сдвинуть коэффициент поближе к 1

мой случай наверное все же второй, характеристики сигнала постоянны, но заранее не известны. поэтому действительно, если работать с бесконейной памятью предыдущих точек, то возникает только одна проблема - переполнение. первые два шага твоего алгоритма я понял, т.е. помним суммы пердыдущих 10 отсчетов, знаем суммы текущих 10 отсчетов, находим нечто S'''(10) = (S'(10) + S''(10)) / 2, получаем среднюю сумму по 10 за педыдущие 20 шагов, потом ждем еще 10 шагов, находим среднюю сумму по ним S''''(10) и используем S'''(10) для получения очередной средней суммы по 10 за предыдущие 20 шагов, но на самом деле это будут не предыдущие 20 шагов, а все 30, т.к. S'''(10) вычислялась с учетом самых первых 10. таким образом общая формула примет вид:

S(x, n, m)[k] = { S(x, n, m)[k - m + 1] + ... + S(x, n, m)[k - 1] + x0 + ... + x(n - 1) } / m

где
S - сумма, в скобках ее параметры,
x - это то, чего сумма (т.е. в моем случает это будут суммы x, xx, xy, y),
n - порядок суммы, количество точек по которым она вычисляется,
m - количесто сумм для вычисления очередной средней суммы,
k - номер итерации.

если вычисляются десятками и очередная сумма считается по предыдущим двум, то вот частный случай

S(x)[k] = { S(x)[k - 1] + x0 + ... + x9 } / 2

а вот насчет твоего третьего пункта и логарифмической зависимости не врубился....
для того, что я написал, памяти нужно  M * (максимально_возможная_сумма - 1), чтобы хранить предыдущие суммы и соответственно N * (максимально_возможный_элемент) для хранения текущих отсчетов. как только посчиталась очередная сумма, самая первая считается недействительной и ее вытесняет вновь прибывшая.

так?? или я что-то перепутал или не учел )))

Добавлено @ 11:39 
тока вот это все равно все упирается в количество отсчетов по которому считается сумма (параметр n). есть у меня какое-то значение суммы на каком-то k-ом шаге. считаю сумму на текущем, а у меня, предположим, пришли такие величины!!! (напрер n не хватает чтобы охватить две ступеньки, а точнее начало одной и конец следующей, а хватает только чтобы сам скачек поимать), что после усреднения старой с новой, получится полный бред и все предыдущие вычисления коту под хвост....

короче, думаю ты не это имел ввиду, поясни, пожалуйста что там с логарифмами....

через каждые 10 отсчётов обновляется S для 10 отсчётов
через каждые 20 - для 20
через каждые 40 - для 40
при этом каждое SN использует два последовательных значения S(N/2)
так что для каждой длины анализируемого интервала нужно хранить всего 2 переменных (два последовательных значения S)
а т.к. длины растут экспоненциально, то необходимое количество переменных пропорционально логарифму

и до какого же N1 мне это делать и с какого N2 снимать сумму для проведения расчетов линии тренда? суммы SN то все равно будут возрастать с увеличением N, как это поможет от переполнения?

на этот раз надо использовать средние их значения
т.е. S20=(S10текущее + S10предыдущее)/2
тогда порядок значений сильно меняться не будет...

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

ps
кстати я тут чуток посчитал) в итоге если у меня отсчеты приходять, например, с частотой 50Гц или 20 в секунду, а каждый новый элемент будет меньше единицы и суммироваться будет к double + счетчик на dword, в которое поместится 4294967296 отсчетов, или 214748364,8 секунд или 3579139,4 минут или 59652,3 часов или 2485,5 дней или 6,8 високосных лет..... то я думаю хватит и такого варианта, лишь бы работал, но вначале надо с последним вариантом разобраться....

рост есть и там, и там
разница в го порядке
во втором случае он логарифмический, что очень часто подходит


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

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




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