caxapa.ru :: Это не ошибка. Это порог. Причем он при определенной ситуации может стать ловушкой, когда слишком малое входное значение не сможет уменьшить текущее значение фильтра. Решается фикспойнтом для значения фильтра. То есть нужно добавить справа к значению фильтра нужное число дробных разрядов и каждое новое входное значение левым сдвигом делать фикспойнтом. При выводе значения фильтра наружу восстанавливать целочисленную разрядность правым сдвигом.

my504 (27.08.2020 23:12, просмотров: 586) ответил Dingo на Чего-то не соображаю сегодня. Хочу к целочисленным данным применить экспоненциальный фильтр вида Y_n=a*X+(1-a)*Y_n-1 Естественно, при умножении будет неточное значение. Как посчитать ошибку к накоплению?

Это не ошибка. Это порог. Причем он при определенной ситуации может стать ловушкой, когда слишком малое входное значение не сможет уменьшить текущее значение фильтра. Решается фикспойнтом для значения фильтра. То есть нужно добавить справа к значению фильтра нужное число дробных разрядов и каждое новое входное значение левым сдвигом делать фикспойнтом. При выводе значения фильтра наружу восстанавливать целочисленную разрядность правым сдвигом.

Ответить

- Если добавить 8 "лишних" бит справа сдвиги будут не нужны. :-)) - Boвa(28.08.2020 09:53)
  - Сдвиги нужны хотя бы потому, что ВЫХОД фильтра (как и вход) - целое, а сам фильтр - фикспойнт (те самые "лишние"). - my504(28.08.2020 10:44)
- Спасибо! Дельный совет. Тем более при умножении всё равно запас по разрядам должен быть. Dingo(379 знак., 28.08.2020 05:52)
  - Смоделировал в эксельке свой способ. Дополнительная ось для выходов, чтобы видно лучше было. α = 3/256; Dingo(245 знак., 28.08.2020 07:10, картинка)
    - Про плавучку принято жаловаться, что медленно. Приятно встретить человека, который не торопится без надобности. Рукопожимаю, коллега. - SciFi(28.08.2020 08:04)
      - Я один и тот же код для PIC переписывал с long'ов на плавучку. И стало быстрей. Потому, что long'и 32-битные (а в 16 бит не лезет), а плавучка в не-PRO Hitech-C версии хорошо оптимизирована на ассемблере руками и 24-битная. Причём там мантисса-то 16-битная вовсе (которую нужно долго перемножать). Просто меньше операций, не говоря уж, что прорамма сильно проще и короче. Проблема целочисленных вычислений, что нужна немеряная разрядность (особенно если у тебя в выражении fk0(164 знак., 28.08.2020 11:33)
        
        1) Зачем нужна немеряная разрядность, если АЦП 16- разрядный? 2) Что за фантазия считать в 16 разрядах, если все 16-разрядные машины имеют умножитель, дающий 32-разрядный результат? - Kpoк(28.08.2020 15:49)
        
        Затем, что x² например. Или результат умножения в том же фильтре. И не лезет либо снизу, либо сверху. Т.е. вообще осмысленный результат влезает, но с другим множителем. А поскольку аргументы той же суммы отнормированы по одной единице, то кто-то уже не умещается. Фантазия возникает на PIC18 или x51, у которых каждый байтик нужно протаскивать через игольное ушко регистрое DPTR или WREG, что в общем-то не быстро (и ещё переноса где-то нет). На MSP430, PIC24 или fk0(39 знак., 28.08.2020 16:55)
        
        Единица в квадрате - все равно единица. И корень из нее тоже. Главное - на берегу ещё выбрать правильные размерности. А так , да, случалось, что и дабла хватало в обрез по точности. - Kpoк(30.08.2020 19:44)
        
        Почему генератор? Полосовик на 16q16 получается устойчивым. Другое дело, что на ПИК такое умножать вспотеешь. Или речь про 16р на всё? А с плывучкой тоже проблема, если нет бочечного шыфтера. Нормализаццыя-денормализаццыя легко может затрахать. - mse homjak(28.08.2020 12:02)
        
        16q16 -- это таки 32-бита. Шифтер же сейчас есть даже у пиков, более того у, даже трёхцилиндровых (pic24/dspic), есть относительно быстрый делитель. А как у любительких армов? У некоторых нет вот. - fk0(28.08.2020 12:31)
        
        Дык, про 24/30/33 и речи быть не должно. Даже для 32 бит. Сратый АВР должен такое легко пережёвывать. С млачшими ПИКами, да, могут быть проблемы. - mse homjak(28.08.2020 12:46)
        
        Младшие пики - это у которых нет аппаратного умножителя. А, скажем, ДСПИК при 32 разрядах делает один шаг фильтра за 6 шагов. - Kpoк(28.08.2020 13:44)
        
        Я-жы пишу, что с 24/30/33 проблем нет вообще. А с млачшими, даже с умножителями, должны быть. А с совсем млачшими(у которых переноса нет) так ваще *опа. - mse homjak(28.08.2020 15:34)
        
        ..ля. Я принял эти цифры за количество разрядов в результате :-) Надо сказать, что 18-пики тоже довольно быстро множат 16-разрядные числа. - Kpoк(28.08.2020 15:42)
      - На плавучку принято жаловаться, что она неточно. Любой умножитель в 16-разрядных машинах даёт 32-разпядный результат. Плавучка хранит только 24 из них. - Kpoк(28.08.2020 09:26)
        
        если исходные данные имеют три значащих разряда, а остальное шумы - то и 24-х разрядная плавучка будет иметь 3 значащих разряда, а не 24. - Mahagam(28.08.2020 10:37)
        
        Проблема только в том, что это три МЛАДШИХ разряда. И они могут оказаться НИЖЕ 24 разрядов. И в этом все дело, а не в разрядности как таковой. У 24 разрядов минимальным значащим будут условно 200 нВ, а у 32-х уже 256 раз меньше... - my504(28.08.2020 14:25)
        
        и то и другое может не иметь никакого физического смысла. нановольты, фемтовольты... меряем же с погрешностью на порядки большей - Mahagam(28.08.2020 15:07)

Микроконтроллеры