Боюсь, все же адекватного сравнения не получится, поскольку что бы что-то сравнивать надо установить критерии по которым будет идти сравнение.
Предположим, что это время за которое алгоритм обрабатывает N параметров и коэффициент сжатия Z — отношение числа параметров на входе к числу параметров на выходе.
Измерив эти данные, мы сможем сказать кто круче по времени, а кто по сжатию. Но эта информация на практике нам будет не интересна, поскольку в Инфоконте с систем контроля мы получаем поток данных, размер которого изначально не определен. За одну итерацию может поступить как 1, так и 10 000 параметров(так работают системы контроля на предприятии, отправляют данные по изменению).
Т.е. на практике мы имеем входные потоки данных различной длинны. Если ставить тесты, то потребуется ряд экспериментов, по результатам которого можно определить среднее время обработки н-ого числа параметров.
Другой параметр — это коэффициент сжатия. Если для gzip'a он будет постоянным, то для swingdoor будет существовать зависимость от длины ряда. Например, возможен ход процесса, когда данные меняются не значительно, тогда большую часть из них можно отсечь. Если такие данные подавать непрерывно, то будут сохранено меньше точек, если бы подавали эти данные маленькими кусками, поскольку первая и последняя точка коридора должна быть сохранена.
Ну вот, уже видим, что двух коэффициентов N и Z для сравнения не достаточно. Как минимум еще надо учесть тип поведения ф-ии T (монотонная, возрастающая, убывающая, периодическая и т.д.) и размер входного потока S.
И еще для GZIP надо помнить, что для отображения данных на мнемосхеме мы должны прочитать данные из БД, декодировать их, после чего отобразить. Для SwingingDoor декодирование не требуется.
Итого, при первом приближение имеем уже 4 коэффициента, которые косвенно связаны между собой. Сравнение алгоритмов сведется к анализу ф-ии GZIP(N, Z, T, S) и SwinginDoor(N, Z, T, S), которое за ближайшие несколько дней мы провести не успеем :)
>> SwingingDoor тоже требуется декодировать.
В том то и дело, что декодировать ничего не надо. Мы получаем точку, решаем сохранить ли ее, если да, то укладываем ее в БД.
Далее при просмотре данных на мнемосхеме делаем select из БД.
>>Хотя думаю, все будет зависеть от самих данных: если меняются скачкообразно и часто, то тут преимущества перед gzip большого не будет. Или как на практике?
Сложно сказать, надо проводить опыт над конкретными рядами данных.
Ну если только «just for fun» :)
GZIP — сжимает информацию, при этом сохраняет все данные, а SwingingDoor — выполняет компрессию, при этом часть данных «выкидывается».
Как вариант — сначала отфильтровать данные при помощи SwingingDoor, а затем полученный остаток сжать.
Но даже такой вариант для нас не прокатит, поскольку сохраненные данные мы еще в Инфоконте и на мнемосхемах отображаем. Это тогда перед их показом надо будет на лету «разжимать».
Плюсы этого алгоритма — скорость работы. Для ответа на вопрос «Нужно ли сохранять следующую точку?» не надо помнить о предыдущих 5-6 точек, как, полагаю, потребуется для построения полинома.
Особенно это условие становиться актуальным если учесть, что нашему Инфоконту надо обрабатывать десятки тысяч параметров в секунду.
Да. Так оно и есть, существует несколько запатентованных алгоритмов компрессии.
Когда мы думали над тем каким образом лучше отфильтровать входной поток, то изучили несколько альтернативных алгоритмов компрессии: Boxcar, Backslope, SLIM1, SLIM2, SLIM3.
SwingingDoor оказался более эффективным и быстрым. Коэффициент сжатия на практике получился около 17.
Еще насчет колебаний.
Если под «большими» колебаниями Вы понимаете большую амплитуду, то алгоритм будет прекрасно работать без уточнения погрешности. В ходе работы направление коридора просто будет изменяться, захватывая все новые и новые точки.
Уточнение погрешности потребуется только в том случае, если мы следим за параметром, значение которого имеет малую амплитуду колебаний, например 0,01.
>> А что если необходимо обрабатывать данные которые имеют большие колебания?
Для таких параметров указывается более маленькая погрешность, тогда никакие колебания мимо не пройдут — все экстремумы будут сохранены.
>> А почему бы не сглаживать какими-нибудь рядами Фурье
Если использовать сглаживание, то значения в экстремумах будут отличаться от действительных значений, полученных, например, с приборов. Для нас важно сохранять именно «сырые» данные, поскольку любое их изменение может повлечь ошибку в анализе процесса.
Предположим, что это время за которое алгоритм обрабатывает N параметров и коэффициент сжатия Z — отношение числа параметров на входе к числу параметров на выходе.
Измерив эти данные, мы сможем сказать кто круче по времени, а кто по сжатию. Но эта информация на практике нам будет не интересна, поскольку в Инфоконте с систем контроля мы получаем поток данных, размер которого изначально не определен. За одну итерацию может поступить как 1, так и 10 000 параметров(так работают системы контроля на предприятии, отправляют данные по изменению).
Т.е. на практике мы имеем входные потоки данных различной длинны. Если ставить тесты, то потребуется ряд экспериментов, по результатам которого можно определить среднее время обработки н-ого числа параметров.
Другой параметр — это коэффициент сжатия. Если для gzip'a он будет постоянным, то для swingdoor будет существовать зависимость от длины ряда. Например, возможен ход процесса, когда данные меняются не значительно, тогда большую часть из них можно отсечь. Если такие данные подавать непрерывно, то будут сохранено меньше точек, если бы подавали эти данные маленькими кусками, поскольку первая и последняя точка коридора должна быть сохранена.
Ну вот, уже видим, что двух коэффициентов N и Z для сравнения не достаточно. Как минимум еще надо учесть тип поведения ф-ии T (монотонная, возрастающая, убывающая, периодическая и т.д.) и размер входного потока S.
И еще для GZIP надо помнить, что для отображения данных на мнемосхеме мы должны прочитать данные из БД, декодировать их, после чего отобразить. Для SwingingDoor декодирование не требуется.
Итого, при первом приближение имеем уже 4 коэффициента, которые косвенно связаны между собой. Сравнение алгоритмов сведется к анализу ф-ии GZIP(N, Z, T, S) и SwinginDoor(N, Z, T, S), которое за ближайшие несколько дней мы провести не успеем :)
В том то и дело, что декодировать ничего не надо. Мы получаем точку, решаем сохранить ли ее, если да, то укладываем ее в БД.
Далее при просмотре данных на мнемосхеме делаем select из БД.
>>Хотя думаю, все будет зависеть от самих данных: если меняются скачкообразно и часто, то тут преимущества перед gzip большого не будет. Или как на практике?
Сложно сказать, надо проводить опыт над конкретными рядами данных.
GZIP — сжимает информацию, при этом сохраняет все данные, а SwingingDoor — выполняет компрессию, при этом часть данных «выкидывается».
Как вариант — сначала отфильтровать данные при помощи SwingingDoor, а затем полученный остаток сжать.
Но даже такой вариант для нас не прокатит, поскольку сохраненные данные мы еще в Инфоконте и на мнемосхемах отображаем. Это тогда перед их показом надо будет на лету «разжимать».
Особенно это условие становиться актуальным если учесть, что нашему Инфоконту надо обрабатывать десятки тысяч параметров в секунду.
Когда мы думали над тем каким образом лучше отфильтровать входной поток, то изучили несколько альтернативных алгоритмов компрессии: Boxcar, Backslope, SLIM1, SLIM2, SLIM3.
SwingingDoor оказался более эффективным и быстрым. Коэффициент сжатия на практике получился около 17.
Если под «большими» колебаниями Вы понимаете большую амплитуду, то алгоритм будет прекрасно работать без уточнения погрешности. В ходе работы направление коридора просто будет изменяться, захватывая все новые и новые точки.
Уточнение погрешности потребуется только в том случае, если мы следим за параметром, значение которого имеет малую амплитуду колебаний, например 0,01.
Для таких параметров указывается более маленькая погрешность, тогда никакие колебания мимо не пройдут — все экстремумы будут сохранены.
>> А почему бы не сглаживать какими-нибудь рядами Фурье
Если использовать сглаживание, то значения в экстремумах будут отличаться от действительных значений, полученных, например, с приборов. Для нас важно сохранять именно «сырые» данные, поскольку любое их изменение может повлечь ошибку в анализе процесса.