Anvar (25.06.2024 13:49, просмотров: 35) ответил SciFi на 65535 - это -1. В арифметике со знаком всё работает из коробки. А
если без знака, предлагаю перед сложением перенести всё вверх
(скажем, не на 65536, а на 100000): 99999, 100000, 100001. После
вычисления среднего арифметического перенести обратно вниз на
100000.-
- "Я тебе один умный вещь скажу, ..."(с) Дело в том что АЛУ не знает с какими числами оно выполняет операции. Знаковые, беззнаковые - нет разницы, операции сложения/вычитания, инкремента/декремента выполняются абсолютно одинаково. Разница возникает только потом, когда проверяешь знак или выводишь на печать. ЫЫyкпy(431 знак., 25.06.2024 15:08, картинка)
- Или вот. Принимаем первый отсчёт как ноль сдвинутой шкалы.
Остальные отсчёты относительно него. В вашем случае 0, 1, 2.
Среднее 1. Приводим к исходной шкале - среднее 0. - SciFi(25.06.2024 14:49)
- Лучше за нуль принимать средний отсчет и усреднять дельты
относительно него. Boвa(1 знак., 26.06.2024 13:20 - 13:37, ссылка)
- "Чем лучше? Чем армяне!" © :-))) - SciFi(26.06.2024 13:22)
- Если энкодер крутится с большой скоростью, а промежуточные данные
сохраняются как 16 битные числа, то в вашем варианте меньше
максимальная разность показаний, которую обрабатывает алгоритм
усреднения. Допустим что разность между соседними показаниями равна
D и она примерно постоянна. Тогда чтобы не произошло переполнение в
вашем алгоритме необходимо чтобы |3*D|<32768, откуда
|D|<10922. Если же использовать мой вариант то при постоянной
скорости вращения Boвa(160 знак., 26.06.2024 13:53 - 13:56)
- Выдумать несуществующую проблему и тут же её решить. Типичная
сахара. За это её и любим :-) - SciFi(26.06.2024 13:56)
- Не нравится - не решай. - Boвa(26.06.2024 13:57)
- Выдумать несуществующую проблему и тут же её решить. Типичная
сахара. За это её и любим :-) - SciFi(26.06.2024 13:56)
- Если энкодер крутится с большой скоростью, а промежуточные данные
сохраняются как 16 битные числа, то в вашем варианте меньше
максимальная разность показаний, которую обрабатывает алгоритм
усреднения. Допустим что разность между соседними показаниями равна
D и она примерно постоянна. Тогда чтобы не произошло переполнение в
вашем алгоритме необходимо чтобы |3*D|<32768, откуда
|D|<10922. Если же использовать мой вариант то при постоянной
скорости вращения Boвa(160 знак., 26.06.2024 13:53 - 13:56)
- "Чем лучше? Чем армяне!" © :-))) - SciFi(26.06.2024 13:22)
- Мне кажется это те же balls, только вид сбоку. Т.е. Хсдвига =
65535, формула Х1 = 65535 - Хсвдига, упс тут переворачиваем применяем другую формулу Х2 = 0-Хсдвига+65536, Х3 = 1-Хсдвига+65536. А среднее Хсреднее = (Х1+Х2+Х3)/3 + Хсдвига -
65536. Я правильно понял алгоритм? - Anvar(26.06.2024 11:47)
- чуть выше: SciFi(1 знак., 26.06.2024 11:48, ссылка)
- Лучше за нуль принимать средний отсчет и усреднять дельты
относительно него. Boвa(1 знак., 26.06.2024 13:20 - 13:37, ссылка)
- Я конечно не программист, но согласен со SciFi о том, что нужно
использовать знаковую арифметику. По-моему увеличение беззнакового
числа 32767 на единицу в знаковой арифметике int16_t даст -1, а не
-32768. А чтобы перейти через точку переполнения результата, нужно
исходное число приводить в масштаб точно так же, как мы работаем с
синусом или косинусом - вычитать из числа период до тех пор, пока
оное число не станет меньше периода. P.S. количество вычитаний
можно так же reZident(67 знак., 25.06.2024 14:11)
- Есть ачучение на уровне интуиции, что если число отсчётов - степень
двойки, и деление - это сдвиг, то всё само собой срастётся. - SciFi(25.06.2024 14:17)
- В любом случае период (переполнение, полный оборот) нужно учитывать при расчете. - reZident(25.06.2024 14:28)
- Есть ачучение на уровне интуиции, что если число отсчётов - степень
двойки, и деление - это сдвиг, то всё само собой срастётся. - SciFi(25.06.2024 14:17)
- Получается, моё решение по сути предлагает сместить шкалу, если
есть разрыв. То есть если видим большой скачок между соседними
отсчётами (65535 >> 0), то сдвигаем шкалу. - SciFi(25.06.2024 14:10)
- А-а кажется понял. Фиксировать признак, что в буфере скользящего
среднего есть переход и считать в этом случае по другому. Пока так
и планируется. Но есть ощущение, что делал проще - Anvar(25.06.2024 15:43)
- Чуть выше слегка иначе сформулировал. Предполагается, что энкодер вращается достаточно медленно, и несколько последовательных отсчётов не покрывают половину оборота. Логично взять инкременты по отношению к первому отсчёту, они будут ограничены безопасной величиной. SciFi(1 знак., 25.06.2024 15:45, ссылка)
- А-а кажется понял. Фиксировать признак, что в буфере скользящего
среднего есть переход и считать в этом случае по другому. Пока так
и планируется. Но есть ощущение, что делал проще - Anvar(25.06.2024 15:43)
