Форум РадиоКот

Тоже свой алгоритм нахождения медианы... точнее среднего от медиан массива (отсекается по 0, 1 или несколько крайних значений, а из остального находится среднее арифметическое), сам массив при этом не повреждается. Условие - числа в массиве менее половины емкости типа переменной, т.к. старший бит отдаётся под метку... алгоритм разрабатывался для обработки данных с АЦП - там это условие соблюдается.
Фильтр не портит массив, это позволяет, используя колцевой буфер, использовать результаты работы АЦП повторно (это значит, что результаты фильтрации можно получать с частотой опроса АЦП)
К сожалению исходный алгоритм фильтра остался на жетком диске дома... а это я из готового кода "быстрого АмперВольтВаттОмМетра для ЛБП на меге8" выкусил.

Спойлер

Код написан в кодевижене, прошу понять и простить

Код: Выделить всё

unsigned int filtr (unsigned int inp[], unsigned char Length, unsigned char Median){
//inp[]  массив входных данных
//Length длина массива входных данных
//Median количество отбрасываемых крайних элементов с каждой стороны, т.е. мощность медианного фильтра
unsigned int tmp;
unsigned char i,j,k,u;         //счетчики и ограничители
unsigned long summ = 0;        //аккумулятор для суммирования усредняемых элементов массива
k=Length-Median;               //количество итераций поиска
u=k-Median;                    //определяем, сколько элементов нужно усреднять
while (k) { 
          tmp=~(1<<15);        //0x7FFF - максимально допустимое для алгоритма число
          i=Length;
          while (i>0)          //в цикле перебираем весь массив - ищем минимальный элемент
              {
              i--;
              if (tmp >= inp[i])
                  {
                  j = i;
                  tmp = inp[i];
                  };
              };
          if (k<=u) summ+=tmp; //складываем в аккумулятор если обработать осталось <= требуемое для усреднения количество элементов
          inp[j]|=(1<<15);     //ставим метку на найденном и обработанном элементе, с ней он уже не будет минимальным
          k--;
          };
//--------------------------------------
k=Length;                      //убираем все метки
do {inp[--k]&=~(1<<15);}
while (k>0);
//--------------------------------------
tmp=summ/u;                    //находим среднее арифметическое
return (tmp);                  //и возвращаем его
}

Да, этот код не будет минимальным в вашей гонке, но у него задача и возможности другие - он позволяет быстро обрабатывать и выводить данные с относительно медленного (т.к. там производится серия измерений для уменьшения дискретности и шага отображения) АЦП.
Вроде всё верно выкусил, там просто ещё автокалибровка и автоподстройка 0 и сохранение этих данных в сжатом виде в служебной области массива реализованы... были...

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

ПС не уверен, что я до среднего уровня тут присутствующих дотягиваюсь, т.к. смотрю, все уже на STMах и ESPхах катаются... а я с ними только в среде ардуино дело имел...

[uquote="Adrift",url="/forum/viewtopic.php?p=4644319#p4644319"]вы сами мне только что сказали, что у M33 векторизации нет[/uquote]
Я этого не говорил. Пруф?

[uquote="Adrift",url="/forum/viewtopic.php?p=4644319#p4644319"]Там регистры 32-х битные, у нас в массиве 32-х битные числа, векторизовать можно максимум 16-ти битные[/uquote]
То есть именно по этой причине, Вы мой оригинальный код с u16 перевели на i32? Хорошо, что признались


[uquote="Adrift",url="/forum/viewtopic.php?p=4644319#p4644319"]Одно из немногих исключений, лично я XTensa терпеть не могу )[/uquote]
Ну это уже эмоции пошли. К тому же для RISC-V линейки поддержка SIMD была анонсирована.

[uquote="Adrift",url="/forum/viewtopic.php?p=4644319#p4644319"]пузырьковая сортировка может быть даже быстрее вашего алгоритма, на M33[/uquote]Я так и не понял, что с того, если какой-то код на каком-то легаси производительней, если на более современных CPU он эффективней? Причем по вполне объективным и легко предсказуемым причинам.

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

[uquote="Ivanoff-iv",url="/forum/viewtopic.php?p=4644333#p4644333"]Пузырьковая сортировка (собственно как и любая другая) портит исходный массив - это её минус...
Иногда критичный, иногда нет...[/uquote]
Это если целенаправленно сортировать массив, а я загружаю элементы массива в переменные и своплю уже их ничего не портя, но сам подход как в пузырьковой сортировке.

[uquote="Ivanoff-iv",url="/forum/viewtopic.php?p=4644329#p4644329"]этот код позволяет менять параметры на лету, подбирая фильтрацию под задачу.[/uquote]
Может я отстал от жизни, но для нахождения медианы по окну любого размера еще не так давно по производительности лидировал алгоритм Quick Select https://www.geeksforgeeks.org/quickselect-algorithm/

Там код нахождения одного значения, т.е. для нахождения среднего арифметического мне его придётся запускать 10 раз...
ну и рекурсия... да, для написания проще, но для мелкого МК не проще - как бы стек не надорвать...

[uquote="Ivanoff-iv",url="/forum/viewtopic.php?p=4644351#p4644351"]для нахождения среднего арифметического[/uquote]
Так мы о медиане говорит или о скользящем среднем?

У меня фильтр фильтр - скользящее среднее с исключением выбросов вверх и вниз, т.е. с нахождением медиан

Добавлено after 57 seconds:
Наверно зря я к прошлой теме прицепился - только в заблуждение ввел...

в предложенных Вами ПростоНуб, задачах мой алгоритм значительно проиграет, по объёму и времени при том что ваш алгоритм тоже не повредит исходный массив.

[uquote="ПростоНуб",url="/forum/viewtopic.php?p=4644331#p4644331"]Я этого не говорил. Пруф?[/uquote]
Предвидя возражения, что используете легаси архитектуру без поддержки векторизации, предложу подумать, а что будет, когда потребуется сменить МК на более современный.

Вы же когда это писали помнили, что использую я M33? Мне без разницы, если M33 уже устарел и имеющиеся у него простенькая векторизация не имеет права таковой называться, то не буду спорить, пусть будет по-вашему )

ПростоНуб писал(а):То есть именно по этой причине, Вы мой оригинальный код с u16 перевели на i32?

Вовсе нет, я воспользовался вашим сишным вариантом где указан тип int, думаю ничего страшного, раз вы его сами для сравнительных тестов использовали.

ПростоНуб писал(а):К тому же для RISC-V линейки поддержка SIMD была анонсирована.

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

ПростоНуб писал(а):Я так и не понял, что с того, если какой-то код на каком-то легаси производительней, если на более современных CPU он эффективней? Причем по вполне объективным и легко предсказуемым причинам.

M33 для STM32 сейчас самое новое ядро, мало у кого из юзающих STM32 оно уже есть в наличии, то есть я, можно сказать, впереди планеты всей, какое же это легаси? Нельзя мк в устаревшие записывать только потому, что там SSE 4 нет )

[uquote="Adrift",url="/forum/viewtopic.php?p=4644358#p4644358"][uquote="ПростоНуб",url="/forum/viewtopic.php?p=4644331#p4644331"]Я этого не говорил. Пруф?[/uquote]
Предвидя возражения, что используете легаси архитектуру без поддержки векторизации, предложу подумать, а что будет, когда потребуется сменить МК на более современный.

Вы же когда это писали помнили, что использую я M33?[/uquote]
Я вообще с M33 не работал. Я лишь предположил (предвидеть - это же предполагать будущее?), что такое возражение может поступить. На утверждение ну никак не тянет

[uquote="Adrift",url="/forum/viewtopic.php?p=4644358#p4644358"]

ПростоНуб писал(а):То есть именно по этой причине, Вы мой оригинальный код с u16 перевели на i32?

Вовсе нет, я воспользовался вашим сишным вариантом где указан тип int, думаю ничего страшного, раз вы его сами для сравнительных тестов использовали.[/uquote]
Сишный вариант появился существенно позже оригинального, когда стали настаивать именно на C, а не на Rust.


[uquote="Adrift",url="/forum/viewtopic.php?p=4644358#p4644358"]вы мне сейчас предлагает[/uquote]

Стоп! Вам я ничего не предлагаю. И непонятно зачем бы мне это даже понадобилось. Я объясняю свою позицию. IMHO, лучше писать код, который будет эффективней на современных CPU, а не устаревших. И который вполне можно использовать и на MK, и на одноплатниках с вполне себе взрослыми ARM, и даже на AMD EPIC или Intel Xeon.

[uquote="Adrift",url="/forum/viewtopic.php?p=4644358#p4644358"]может быть когда-нибудь она будет использоваться на мк у которого будет нормальная векторизация и компилятор сможет ее задействовать[/uquote]
Она уже есть на ряде МК. К тому же код, который я привел, ну никак МК не ограничен.

[uquote="Adrift",url="/forum/viewtopic.php?p=4644358#p4644358"]M33 для STM32[/uquote]
То есть для Вас все же на STM32 свет клином сошелся?

[uquote="Adrift",url="/forum/viewtopic.php?p=4644358#p4644358"]Нельзя мк в устаревшие записывать только потому, что там SSE 4 нет )[/uquote]
Мне можно. Так как я работаю с CPU у которых уже есть SIMD. А уж называются они SSE, NEON или еще как - дело десятое.

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

И на счет ворот, открываемых по лицу: ржунимагу! Думаю, если у авс есть веселые друзья, то ваши ворота будут всегда открыты, ведь напечатать вашу фотку не так уж и сложно...

Есть ведь решения, существующие лет 50... Но нет...

[uquote="ARV",url="/forum/viewtopic.php?p=4644391#p4644391"]Где я вижу описанный мной подход? Да везде, где программы пишут не командами в 100500 человек, где убыточного программиста год не могут содержать. Думаете, таких мест мало?
Скорее мало описанных вами мест...[/uquote]
Так всё же, где именно Вы видите? Конкретно. Вот я вижу совсем другой подход. Если отсечь действительно крупные команды, то за последние лет 10 это GMCS, Bunge, СУЭК, ЕвроХим, НТК, СГК. Да даже в ВГТРК с их бардаком до такого не доходят.

[uquote="ARV",url="/forum/viewtopic.php?p=4644391#p4644391"]Думаю, если у авс есть веселые друзья, то ваши ворота будут всегда открыты, ведь напечатать вашу фотку не так уж и сложно...[/uquote]
Лично мне это безразлично. Когда я дома, калитка и так всегда открыта, так как чужие не войдут из-за пса. Когда уезжаю не сложно эту систему блокировать. Например, при закрытии ключом замка на калитке.

[uquote="ARV",url="/forum/viewtopic.php?p=4644391#p4644391"]Есть ведь решения, существующие лет 50... Но нет...[/uquote]
Расскажите. Мне, если честно, эта проблема уже начала доставать и я уже думал, как её решать. На данном этапе AI выглядит, как из пушки по воробьям, но и других реальных альтернатив пока не вижу.

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

На счет того, где я вижу "такое", повторю еще раз: везде, где программистов не 80% от численности компании, а, например, 10%. Ну и сами компании не из тысяч работников, а так, от 10 до 100.

[uquote="ARV",url="/forum/viewtopic.php?p=4644418#p4644418"]Я думаю, мои идеи по определению вам не подойдут, они ведь несовременные. Поинтересуйтесь у гигачата, наверняка предложит лучше.[/uquote]
Зачем хамите?
[uquote="ARV",url="/forum/viewtopic.php?p=4644418#p4644418"]На счет того, где я вижу "такое", повторю еще раз: везде[/uquote]
Вот и перечислите конкретно несколько, как сделал я. Вы хотя бы понимаете, что многократное употребление слова "везде", выглядит, как откровенная демагогия?

ПростоНуб, воротами голосом управляйте. Или свистом. Или их комбинацией.

[uquote="smacorp",url="/forum/viewtopic.php?p=4644450#p4644450"]ПростоНуб, воротами голосом управляйте. Или свистом. Или их комбинацией.[/uquote]
Этот вариант уже рассматривал. Проблема в том, что как раз по выходным, когда нужно это автоматическое открытие, с большой вероятностью рядом будет реветь инструмент. или садовая техника, или просто выставленные на улицу колонки. Или даже жена, которую порой так несет, что перекричать невозможно
Мне легче пса научить, чтобы он какой то рычаг нажимал в нужный момент, чем добиться стабильного голосового управления

Если честно, то мне похер, даже если вы меня не в демагогии обвините, а в чем похуже. Не люблю кичливых снобов, и не дискутирую сними, только хамлю.

ПростоНуб писал(а):IMHO, лучше писать код, который будет эффективней на современных CPU, а не устаревших.

А ещё лучше писать код, который будет эффективен на железе, которое появится только завтра. Сложновата задачка, но вы справитесь, наверняка справитесь.

Добавлено after 4 minutes 6 seconds:

ПростоНуб писал(а):Мне легче пса научить, чтобы он какой то рычаг нажимал в нужный момент,

Странно от вас это слышать. Пёс - это устаревшая технология, уж сколько тысяч лет в работе на человека.

ПростоНуб, я тут решил более детально разобраться что там за SIMD в кортексах M33/M7/M4 и по сути это только инструкции сложения и вычитания, они так в документации и называются: Parallel addition and subtraction instructions. А ваши инструкции из SSE сравнивают и сохраняют, например, наименьшее. Такое уже умеет Helium, однако на всех производителей мк на M85/M55/M52 удручающе мало. Все остальные Cortex-M устарели, что не удивительно, если даже RISC-V, где SIMD неизвестно когда появится, устарел уже в момент своего появления ) Непонятно только зачем вы перечисляли все шесть ESP32 на RISC-V, на которые так трудно будет переносить программы на ассме с предыдущих архитектур, ведь никому и в голову не придет заниматься такой бессмысленной работой, переносить код нужно на современные мк, а не легаси )

[uquote="Adrift",url="/forum/viewtopic.php?p=4644575#p4644575"]Такое уже умеет Helium[/uquote]
Я уже несколько раз указывал, что операции сравнения векторизуются. Именно опираясь на уже существующие SIMD расширения.

[uquote="Adrift",url="/forum/viewtopic.php?p=4644575#p4644575"]удручающе мало[/uquote]
Будет много. Это лишь вопрос времени. Главное, что эти расширения документированы и для них есть кодогенерация.

[uquote="Adrift",url="/forum/viewtopic.php?p=4644575#p4644575"]если даже RISC-V, где SIMD неизвестно когда появится[/uquote]
LLVM уже года четыре, как поддерживает RVV.

Но всё же, где в моем коде нахождения медианы Вы обнаружили хоть какую-то зависимость от Cortex-M или RISC-V?
Почему Вы упорно отказываетесь считать этот код универсальным для любого микропроцессора, от i4004 до AMD EPYC 9965?