Почему два? Положительных составляющих типа не бывает? ;>


Для младших надо сделать операцию NEG. иначе такое умножение ни к чему хорошему не приведет.


Если преобразовывать сразу при расчете, то это сведется к доп. 3-м тактам в худшем случае (к двум в лучшем) на каждую составлющую:

в среднем +5 тактов к 38-ми

Господа, ну вы что, думаете, что я не знаю, как быстро возвести в квадрат на AVR? Конечно знаю.

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

Еще раз повторюсь: там много накладных расходов. Я буду их уменьшать. Но, видимо, потом, потому как необходимо править последний проход БПХ для перетасовывания данных.

А господину Огурцову я бы порекомендовал сначала думать, потом говорить, и не высасывать из пальца темы для флуда.

PS А почему никто не кричит, что 2000 тактов на 32хточечное БПХ - это много?

Для тех, кому не терпится, выкладываю проект и листинг.

В проекте только DHT и расчет мощностей с нормированием.

Временно выключен inline для того, чтобы проще было читать листинг.

Несмотря на то, что я перетасовал выход DHT для более простой манипуляции с данными в последующем расчете мощностей выигрыша это почти не дало.

Результаты со включенным инлайном:

DHT - 1947
PWRS - 3122

Если есть возражения к коду - велком...

 proj.zip ( 6.25 килобайт ) Кол-во скачиваний: 113
 list.zip ( 6.88 килобайт ) Кол-во скачиваний: 105

Два, потому что есть действительная и мнимая составляющая спектра, каждую надо проверять на знак.

Загрузку считать надо обязательно, поскольку множители не константы. (Подправил цифры, почему-то считал, что movw выполняется за два такта.)

Вот мой вариант перемножения (a1,a0)*(a1,a0)+(b1,b0)*(b1,b0)->(c3,c2,c1,c0), сделанный на базе ваших макросов, просто отказался от регистров промежуточного хранения r7-r4

Код

    ld    a1,y+
    ld    a0,y+
    ld    b1,y+
    ld    b0,y+

    mul    a1,a1
    movw    c2,r0
    mul    a0,a0
    movw    c0,r0
    mul    a1,a0
    add    c1,r0
    adc    c2,r1
    adc    c3,r2
    add    c1,r0
    adc    c2,r1
    adc    c3,r2

    mul    b1,b1
    add    c2,r0
    adc    c3,r1
    mul    b0,b0
    add    c0,r0
    adc    c1,r1
    adc    c2,r2
    adc    c3,r2
    mul    b1,b0
    add    c1,r0
    adc    c2,r1
    adc    c3,r2
    add    c1,r0
    adc    c2,r1
    adc    c3,r2

Итого 32 такта на вычисления, всего, с загрузкой множителей из рамы, получилось 40 тактов. Ещё можно сэкономить регистры b1, b0, если делать загрузку второго множителя в регистры (a1,a0) непосредственно перед вычислением (b1,b0)*(b1,b0). (Третий раз корректирую, спасибо rst7)


Хм, загрузка множителя не даёт флагов, надо делать тестирование, а это доптакты. Вы привели неполный код для конверсии. В среднем у вас будет будет 6 тактов, т.е. для вашего кода в среднем будет 38+6=44 на вычисления плюс 8 на загрузку, всего 52.

И они обе отрицательные всегда?


AVR-студией, код приведен. Загрузка операндов там есть, правда не из RAM а из флеш, но по скорости одинаково.


Нет не будет там 6 тактов в среднем, в среднем будет 5, как я и написал, из расчета что одна из составляющих уже положительная.
Вчитайтесь в то что я написал. Преобразовывать сразу при расчете. - расчитали спектральную составляющую и перед сохранением (пока еще флаги известны) сделали модуль. Вы же предполагаете что модуль будет считаться после загрузки.

i.e.:

1. расчет составляющей
<-- я предлагаю преобразование делать сразу здесь
2. сохранение в массив
3. загрузка из массива
<-- вы предполагаете преобразование делать здесь
4. вычисление мощности

Чтото мне говорит, что такой код работать не будет.

Вот так - будет:


А вообще я по другому делаю, рекомендую глянуть в проект/листинг.

Точно, еще раз убеждаюсь ночная оптимизация - это зло!

Тоже не работает. Два произведения есть, а суммы нету

Господа, хватит. IAR делает вполне приемлемый код

Господа оптимизаторы. Объясните мне, сирому, зачем:

1) считать спектр мощности при этом теряя всю информацию о фазовой составляющей!!!??? Нафиг тогда FFT вообще??? Быстрая корреляция методом сравнения спектров мощности это нечто новое вообще. Советую подавать заявки во все инстанции... статью в "Юный техник" дабы застолбить открытие...

2) Отбрасывать половину спектра... Вернее зачем отбрасывать я понимаю, а вот зачем ее было считать!!!??? . Кстати в FWT это отбрасывание делается лЁгко, и экономит часть расчетов...

Мда уш...

Нам фаза сигнала не нужна. Мы сравниваем спектры мощности. Такой у нас алгоритм.



Тут никто не говорит о вычислении взаимной корреляции.



А кто ее отбрасывает и кто ее считает? 32 результата после Хартли суть 15 пар значений, которые определяют мощность каждой спектральной составляющей и постоянку, которую отбрасываем.



А причем тут вейвлеты?

Отбрасывать надо пол-спектра именно при DFT (Фурье), на входе которого только действительные числа. Тогда спектр зеркально симметричен. Мы же, для оптимизации, пользуем DHT (Хартли), которое именно под это и заточено - под обработку действительных исходных данных.



К Вам это тоже относится

ну так алгоритм принципиально глупый скажу я Вам, он насыщен излишними вычислениями в принципе, а некоторые уже взялись за ассемблер...

Вот это то меня и пугает. Ибо это и есть математическая основа любого распознавания.

Ага. Вот только основная мощность фонемы сосредоточена в частотах от 500 Hz... Мощность,в этом контексте, показывает что "за пределами" сигнала практически нет, а не то, что это кртитерий распознавания...

А при том, что это отображение во многих случаях(вот как сдесь) эффективнее FCT(или FHT). Причем ни для быстрой корреляции ни для, непонятно для чего примененного, спектра мощности оно не потребует туда-сюда переходов к комплексным числам, как и Хартли.

Вы меня совершенно не поняли. Я про отброс частот 0..400Hz которые обрабатываются "напрасно"...

Разумеется. Только не в этом случае.

Да ну? А я, например, считаю, что алгоритм весьма не глуп. Вычисляя спектр мощности мы выбрасываем из сигнала то, что не несет информации (например, фазу сигнала). Затем ищем ближайший из известных спектров.

А вот что Вы предлагаете - мне пока не понять. Вы предлагаете вычислять корреляционную функцию заранее известных сигнало прямо c входными семплами??? И что же Вы получите на выходе? Банально, что делать с фазой сигнала, которая не несет информации, но может сильно меняться?

Вы вероятно упустили что Fd у нас 3.2kHz, а не 8, т.е. мы отбрасываем 0..100Hz, а не 0..400Hz.


Объясните нам темным зачем нужна фазовая составляющая? Если она для каждой выборки (32 точки) будет случайным числом.

Мне вот что подумалось, DRUID3, Вы наверно знаете что-то энтакое...но нам не говорите. Но намекаете постоянно. Чего уж там церемониться, режьте правду-матку, прямо в лоб, а не какими-то намеками, которые мы не все равно ж не сможем понять.

Ну что, сделал я поиск ближайшего спектра, заодно пооптимизировал остальное (в частности, сумму квадратов считаю прямо в финальных бабочках DHT, в результате получение 15ти квадратов мощностей из исходных 32х выборок сигнала занимает 2634 такта, причем заодно я нахожу максимальное значение мощности для последующей нормализации).

Ну а нормализация с извлечением корня и поиск ближайшего из 25ти спектров занимает 6924 6482 такта. Основное время, как понимаете, занимает именно поиск ближайшего. В принципе, есть одна идея насчет оптимизации этого поиска, но это потом, когда получится остальное.

С другой стороны, суммарно имеем менее 10000 тактов, что при тактовой, скажем, 8МГц - чуть больше миллисекунды. А выборка 32х точек - 10мс.

Исходник и листинг в аттаче.
 main.zip ( 10.61 килобайт ) Кол-во скачиваний: 202


PS Ждем спектров
PPS И еще немножко оптимизировал, аттач положил новый.

Сообщение отредактировал Rst7 - Oct 26 2008, 12:55