Anvar (25.06.2024 12:44, просмотров: 2904)-
- Вот вы все уперлись в среднее арифметическое! Сигнал
широкополосный, скорость сигнала больше скорости помех. ФНЧ не
работает! - IBAH(26.06.2024 15:46)
- Никто никуда не уперся, автор хотел скользящее среднее. Он получил. - Boвa(26.06.2024 17:06)
- 65532, 65533, 65534 -> 65533 AБBГД(406 знак., 26.06.2024 11:30,
)
- Вообще интересно , Но для формулы Rez = ((A1 + A2 + A3) & 0xFFFF) /
3 в комбинации 65534, 65535, 0 -> 65535 ошибка? - Anvar(26.06.2024 12:02)
- Да, прошу прощения, приблизительно понимал, в каком направлении
копать, но выкопал немного не то. Вот так работает, проверил AБBГД(234 знак., 26.06.2024 12:33, )
- По моему это алгоритм Скифи со сдвигом по первой точке. - Anvar(26.06.2024 12:59)
- По-моему, вы общаетесь с нейросетью - Ralex(26.06.2024 14:16)
- Главное результат! - Anvar(26.06.2024 15:34)
- По-моему, вы общаетесь с нейросетью - Ralex(26.06.2024 14:16)
- По моему это алгоритм Скифи со сдвигом по первой точке. - Anvar(26.06.2024 12:59)
- Да, прошу прощения, приблизительно понимал, в каком направлении
копать, но выкопал немного не то. Вот так работает, проверил AБBГД(234 знак., 26.06.2024 12:33,
- Вообще интересно , Но для формулы Rez = ((A1 + A2 + A3) & 0xFFFF) /
3 в комбинации 65534, 65535, 0 -> 65535 ошибка? - Anvar(26.06.2024 12:02)
- Энкодер, как я понимаю, выдает 16-разрядные числа и на один оборот
приходится 64К дискретов. В таком случае 16-разрядный процессор -
то что надо. Фокус в том, что представление целых чисел только
пытается имитировать математические целые, но из-за ограниченной
разрядности множество целых от +бесконечности до -бесконечности
оказывается обрезанным до [0, 2N-1], да ещё и закольцованным потому что следом за 2N-1 (0xffff) следует 0. Это как раз то что ЫЫyкпy(366 знак., 26.06.2024 05:37)
- Вы уже три поста написали , что все просто. Напишите пример
алгоритма как вычислять среднее трех чисел. Для безнаковых
65535,0,1 или если вы хотите знаковые то 32766,32767, -32768. - Anvar(26.06.2024 06:24)
- Так Вам мало одного поста. Я же рекомендовал уже: введите вторую переменную, смешенную на четверть оборота от основной. И обрабатывать ее параллельно. В тот момент, когда основная переходит через ноль, вспомогательная будет вполне гладкой. И да. При самой идеальной механике показания все равно будут скакать. - Kpoк(26.06.2024 11:10)
- Я вам ниже уже пояснял, что нужно учитывать период. Для беззнаковых чисел 65535, 0, 1 арифметика (с учетом выхода за границы
периода) получается такая:
[65535+(0+65536)+(1+65536)]/3=196608/3=65536. Результат усреднения
вновь приводим к периоду, вычитая его (периода) значение (65536) до
тех пор, пока результат не станет меньше периода =>
65536-65536=0. Итоговый результат усреднения = 0. Плюсом идет информация об
одном полном обороте reZident(35 знак., 26.06.2024 11:08)
- Нет, не получается такой арифметики. 0/3=0, а (0+65536)/3=21845.
Переполнение можно не учитывать только если нет операций деления, с
делением все становится сложнее. AlexBi(147 знак., 26.06.2024 11:18, ссылка)
- Если я правильно понял резидента, оно работает - вы фиксируете
переход и в зависимости от этого прибавляете или не прибавляете
65536. Так и делается, просто не нравится. Кстати в моем случае
энкодер 18 разрядный - шкала 262144, но это сути не меняет - Anvar(26.06.2024 11:35)
- Как-то так? SciFi(325 знак., 26.06.2024 11:49)
- Возможно, если по времени уложится, не люблю я в прерывания, циклы
вставлять - Anvar(26.06.2024 12:19)
- Теологический вопрос, а если компилер развернет цикл, остается ли
он циклом? - Andreas(26.06.2024 13:25)
- С циклами проблема не в этом. Вы его делаете, скажем 10, проходит 5
лет, вы лезете в код и думаете, а почему бы не сделать 1000? Будет
же только лучше! - Anvar(26.06.2024 13:35)
- Просто надо рядом написать комментарий с гневным предостережением. - SciFi(26.06.2024 13:37)
- А еще добавить ASSERT , что бы оно не компилировалось, если гневное предостережение не будет учтено. - AlexBi(26.06.2024 17:13)
- Только вчера залез в чужой код и в комменте к константе А гневное
предостережение, что ее менять надо обязательно вместе с константой
В, причем полстроки восклицательных знаков. Но константы В в коде
нет вообще и похожего по написанию нет, много думал. ) - Andreas(26.06.2024 13:41)
- Есть такая тема ,по прошествии 20 лет, иногда проще новый код написать - Anvar(26.06.2024 13:44)
- Просто надо рядом написать комментарий с гневным предостережением. - SciFi(26.06.2024 13:37)
- С циклами проблема не в этом. Вы его делаете, скажем 10, проходит 5
лет, вы лезете в код и думаете, а почему бы не сделать 1000? Будет
же только лучше! - Anvar(26.06.2024 13:35)
- А как же среднее арифметическое без цикла? Хочу всё знать. - SciFi(26.06.2024 12:23)
- Без коррекции перехода пока так. Ессно дает ошибку при переходе Anvar(1663 знак., 26.06.2024 12:51)
- Запросто, кольцевой буфер с указателями - новый добавил, совсем
старый вычел. - Andreas(26.06.2024 12:25)
- Сумма по скользящему окну? Мы тут с переходом через ноль никак не
разберёмся, а эта штука вообще добьёт :-) - SciFi(26.06.2024 12:26)
- Возможно, таких умных слов не знал. Это очередь, при поступлении
элемента он прибавляется к сумме, выходящий с другого конца очереди
элемент вычитается из суммы. Если очередь инициализировать нулями,
то в сумме всегда будет сумма элементов очереди. - Andreas(26.06.2024 13:23)
- Применимо только для целых чисел. При использовании плавучки очень
быстро ошибка округления суммы накапливается. Поэтому если буфер
небольшой, то надежнее каждый раз сумму считать. - reZident(26.06.2024 15:28)
- Как-то незаметно в какой-то момент энкодер начал выдавать коды в плавучке. Обожаю сахару :-) - SciFi(26.06.2024 15:32)
- Причём "прибавляется и вычитается" можно заменить на "добавляется
разность элементов", а разность вычислять правильным образом со
знаком. Тогда скользящая сумма не подвержена ошибке перехода через
ноль. - SciFi(26.06.2024 13:32)
- Да, можно перейти к виртуальному инкрементальному энкодеру, тоже вариант - Anvar(26.06.2024 13:37)
- Применимо только для целых чисел. При использовании плавучки очень
быстро ошибка округления суммы накапливается. Поэтому если буфер
небольшой, то надежнее каждый раз сумму считать. - reZident(26.06.2024 15:28)
- Возможно, таких умных слов не знал. Это очередь, при поступлении
элемента он прибавляется к сумме, выходящий с другого конца очереди
элемент вычитается из суммы. Если очередь инициализировать нулями,
то в сумме всегда будет сумма элементов очереди. - Andreas(26.06.2024 13:23)
- Сумма по скользящему окну? Мы тут с переходом через ноль никак не
разберёмся, а эта штука вообще добьёт :-) - SciFi(26.06.2024 12:26)
- Теологический вопрос, а если компилер развернет цикл, остается ли
он циклом? - Andreas(26.06.2024 13:25)
- Возможно, если по времени уложится, не люблю я в прерывания, циклы
вставлять - Anvar(26.06.2024 12:19)
- Что бы "зафиксировать переход" придется реализовать некий алгоритм обнаружения перехода, написать лишний код, хотя можно обойтись без этого. - AlexBi(26.06.2024 11:47)
- Усреднять только знаковые приращения, в которых нет переполнения и
раз в N отсчетов среднее приращение перекидывать в смещение и
среднее приращение обнулять. Я так понял и в этом может и есть
смысл, если период опроса намного меньше частоты вращения энкодера. - Andreas(26.06.2024 11:44)
- Это кстати идея. Я вспомнил, я с инкрементными энкодерами это делал. А тут проблема видимо в том, что аппаратный, но без счетчика оборотов. Кстати есть аппаратные со счетчиками оборотов, видимо для этих целей тоже - Anvar(26.06.2024 12:04)
- +1. Похожая история с отслеживанием времени. В пределах периода аппаратного таймера можно спокойно отсчитывать задержки. Для более длительных промежутков нужно время от времени (но снова в пределах периода) давать приращение счётчику с бОльшим числом разрядов. - SciFi(26.06.2024 11:47)
- Не-не, прибавлять и вычитать нужно период! Ну как у синуса или косинуса период 2π. - reZident(26.06.2024 11:40)
- Но у вас же неуниверсальная формула? [65535(тут не прибавляем 65536, а дальше почему-то
прибавляем) +(0+65536)+(1+65536)]/3=196608/3=65536. И это почему-то - переход через "0" т.е. его
нужно анализировать и применять разные формулы. У меня буфер, если
что, на 10 значений - Anvar(26.06.2024 12:12)
- Дык 65535 меньше же периода. Вообще идея в том, чтобы от функции, определенной на отдельном отрезке (периоде), перейти к непрерывной периодической функции. По типу синуса. Но поскольку вам как результат нужно именно значение на заданном отрезке, то период из результата нужно убирать (вычитать). - reZident(26.06.2024 12:47)
- После деления в результат будет добавлено не целое число периодов - AlexBi(26.06.2024 11:49)
- Но у вас же неуниверсальная формула? [65535(тут не прибавляем 65536, а дальше почему-то
прибавляем) +(0+65536)+(1+65536)]/3=196608/3=65536. И это почему-то - переход через "0" т.е. его
нужно анализировать и применять разные формулы. У меня буфер, если
что, на 10 значений - Anvar(26.06.2024 12:12)
- Как-то так? SciFi(325 знак., 26.06.2024 11:49)
- Я вам больше скажу, 0 можно делить на любое число, все равно 0
получится :-))) В вашем сообщении нет логики. Зачем делить сумму из
одного значения на 3? Среднее арифметическое считается как Xср =Ʃ(Xi)/N, где i=1...N. Для N=1 делитель 1, а не 3! :-P - reZident(26.06.2024 11:30)
- Вы предлагаете ко всем добавить период (65536)? Если да, то почему
к 65535 не добавили? - AlexBi(26.06.2024 11:50)
- Период добавляется (или вычитается) при переходе через границу периода. - reZident(26.06.2024 12:02)
- Вы предлагаете ко всем добавить период (65536)? Если да, то почему
к 65535 не добавили? - AlexBi(26.06.2024 11:50)
- Если я правильно понял резидента, оно работает - вы фиксируете
переход и в зависимости от этого прибавляете или не прибавляете
65536. Так и делается, просто не нравится. Кстати в моем случае
энкодер 18 разрядный - шкала 262144, но это сути не меняет - Anvar(26.06.2024 11:35)
- Нет, не получается такой арифметики. 0/3=0, а (0+65536)/3=21845.
Переполнение можно не учитывать только если нет операций деления, с
делением все становится сложнее. AlexBi(147 знак., 26.06.2024 11:18, ссылка)
- Простые вещи самые сложные для объяснения :(( Я пытаюсь донести то факт, что вычисления с целыми числами на современных процессорах это арифметика по модулю 2N. Результаты арифметических операций это остаток от деления "настоящих" математических целых чисел на 2N. И что в данном случае это не столько мешает, сколько помогает. - ЫЫyкпy(26.06.2024 07:29)
- В двоичном виде 65535 выглядит так же как и -1. Неудивительно что результат будет =0. ЫЫyкпy(123 знак., 26.06.2024 07:11)
- Вы уже три поста написали , что все просто. Напишите пример
алгоритма как вычислять среднее трех чисел. Для безнаковых
65535,0,1 или если вы хотите знаковые то 32766,32767, -32768. - Anvar(26.06.2024 06:24)
- Кстати, аналогичная задача в буржуинском электрическом интернете
гуглится по словам "average of angles" >>> SciFi(1 знак., 25.06.2024 22:18, ссылка)
- Здорово, только мне это надо сделать за 100мкс))) Прикольно, обсуждение у них похоже как у нас - Anvar(26.06.2024 06:34)
- Они там все поголовно развращены наличием плавающей арифметики, вот и творят всякие непотребства. ЫЫyкпy(57 знак., 26.06.2024 06:12)
- Точно. Так тоже делал. - RxTx(25.06.2024 22:30)
- Потеря непрерывности aka заворот угла убирается знаковым представлением. 65535 это -1. Тогда (-1 + 0 + 1) / 3 = 0. - RxTx(25.06.2024 22:12)
- Не нужны показания угла. Нужно обрабатывать синус и косинус от него . У них скачков не бывает - Kpoк(25.06.2024 21:50)
- У меня веселее было, 14 бит усреднять. А таких данных в АЛУ нет :) Только момент: здесь НЕ скользящее среднее, а усреднение нескольких чтений подряд. Так нужно было. 2dimka(3776 знак., 25.06.2024 20:39)
- Нет никакого перехода, потому ничего обрабатывать не нужно. - ЫЫyкпy(25.06.2024 17:42)
- еще вариант, находить не среднее арифметическое, а наиболее вероятное. Т.е накопили выборку отсортировали, взяли N/2 элемент. - IBAH(25.06.2024 17:35)
- Надо сделать функцию гладкой. Например ограничить, или во второй половине изменить знак - IBAH(25.06.2024 17:29)
- в определенном случае было удобнее ввести минимальное отклонение, соответствующее минимальному регистрируемому изменению. а-ля электронный храповик. - Vit(25.06.2024 15:27)
- Для чего оно вам нужно? VVB(608 знак., 25.06.2024 13:54, ссылка, ссылка)
- 65535 - это -1. В арифметике со знаком всё работает из коробки. А
если без знака, предлагаю перед сложением перенести всё вверх
(скажем, не на 65536, а на 100000): 99999, 100000, 100001. После
вычисления среднего арифметического перенести обратно вниз на
100000. - SciFi(25.06.2024 12:53)
- Мне кажется вы не совсем поняли задачу, это не про числа, это про
угловой энкодер. 1. Тогда как вычислять при переходе от 32767 к
-32768? 2. Не понял. Все равно там будет "стык" соседних угловых
положений отличающихся на один бит, а среднее будет в полшкалы
энкодера. И да, некрасивое решение у меня есть. - Anvar(25.06.2024 13:49)
- "Я тебе один умный вещь скажу, ..."(с) Дело в том что АЛУ не знает с какими числами оно выполняет операции. Знаковые, беззнаковые - нет разницы, операции сложения/вычитания, инкремента/декремента выполняются абсолютно одинаково. Разница возникает только потом, когда проверяешь знак или выводишь на печать. ЫЫ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)
- Мне кажется вы не совсем поняли задачу, это не про числа, это про
угловой энкодер. 1. Тогда как вычислять при переходе от 32767 к
-32768? 2. Не понял. Все равно там будет "стык" соседних угловых
положений отличающихся на один бит, а среднее будет в полшкалы
энкодера. И да, некрасивое решение у меня есть. - Anvar(25.06.2024 13:49)
- Вот вы все уперлись в среднее арифметическое! Сигнал
широкополосный, скорость сигнала больше скорости помех. ФНЧ не
работает! - IBAH(26.06.2024 15:46)
