NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jak efektywnie obliczyć transformację FFT dla 15000 punktów bez całek?
J.F.
Guest
Guest
Sat Nov 25, 2006 7:45 pm
On Sat, 25 Nov 2006 15:53:57 +0100, BartekK wrote:
Quote:
Adam Dybkowski napisał(a):
Możesz przyjąć skończoną dokładność i robić obliczenia na liczbach
stałoprzecinkowych. Np. przeskalować wszystkie dane wejściowe do zakresu
-1,1) i zapisać je jako liczy 16 bitowe (1 bit znaku i 15 bitów części
ułamkowej).
Myslalem o tym, ale dla danych wejsciowych o rozdzielczosci 12bit (a
docelowo raczej 16bit) skalowanie do 16bit nie byloby sensowne chyba
(przeciez i tak juz maja zakres 0-0xffff) wiec mozna po prostu przyjac
ze to co jest zapisane jako 0-65535 to jest -1 do +1. Tylko ze jak
nakarmilem ten algorytm (tak na piechote na pc) dosc losowymi danymi o
rozpietosci 16bitowej to floaty zaczely mi siegac od bardzo malych
(ktore nijak na 16bit -1 do +1 bym nie zapisal na 1bicie) do bardzo
duzych - ktore by mi sie w 32bit nie zmiescily... Sproboje jeszcze
Możesz przyjąć skończoną dokładność i robić obliczenia na liczbach
stałoprzecinkowych. Np. przeskalować wszystkie dane wejściowe do zakresu
-1,1) i zapisać je jako liczy 16 bitowe (1 bit znaku i 15 bitów części
ułamkowej).
Myslalem o tym, ale dla danych wejsciowych o rozdzielczosci 12bit (a
docelowo raczej 16bit) skalowanie do 16bit nie byloby sensowne chyba
(przeciez i tak juz maja zakres 0-0xffff) wiec mozna po prostu przyjac
ze to co jest zapisane jako 0-65535 to jest -1 do +1. Tylko ze jak
nakarmilem ten algorytm (tak na piechote na pc) dosc losowymi danymi o
rozpietosci 16bitowej to floaty zaczely mi siegac od bardzo malych
(ktore nijak na 16bit -1 do +1 bym nie zapisal na 1bicie) do bardzo
duzych - ktore by mi sie w 32bit nie zmiescily... Sproboje jeszcze
I bardzo dobrze do tego podszedles - trzeba sprawdzic, bo na oko
to 16-bitowa dokladnosc moze byc za mala.
Tymi malymi liczbami byc moze nie trzeba sie przejmowac - wpiszesz
zero, a liczba i moze jest pomijalnie mala. Byc moze bedzie
sens te 12-bitowe liczby wstepnie przemnozyc przez 2, 4 czy 8.
Niestety - jest to dosc skomplikowany przypadek do analizy
dokladnosci.
J.
PAndy
Guest
Guest
Sat Nov 25, 2006 10:20 pm
"Piotr Wyderski" <wyderski@mothers.against.spam-ii.uni.wroc.pl> wrote in
message news:ek9dn9$597$1@news.dialog.net.pl...
Quote:
PAndy wrote:
Raczej dla 16384, choc sa i dla niekraglych liczb.
Dostawia sie zera i po klopocie
Po klopocie, ale w sytuacjach wymagajacych zgrubnego
podzialu na podpasma, takich jak filtrowanie itp. Jesli
jednak chce sie policzyc _DFT_, to po dostawieniu zer
wyniki beda opisywaly cos innego, niz dana funkcja.
Raczej dla 16384, choc sa i dla niekraglych liczb.
Dostawia sie zera i po klopocie
Po klopocie, ale w sytuacjach wymagajacych zgrubnego
podzialu na podpasma, takich jak filtrowanie itp. Jesli
jednak chce sie policzyc _DFT_, to po dostawieniu zer
wyniki beda opisywaly cos innego, niz dana funkcja.
Wierze Ci na slowo.
Quote:
A ja ze swej strony polecam sprzetowe FFT
A po co to liczyc sprzetowo, skoro algorytm jest latwy,
dobrze implementowalny i wydajny, zwlaszcza przy wsparciu
sprzetowym do adresowania w odwróconym porzadku bitowym?
A po co to liczyc sprzetowo, skoro algorytm jest latwy,
dobrze implementowalny i wydajny, zwlaszcza przy wsparciu
sprzetowym do adresowania w odwróconym porzadku bitowym?
Do tego by miec reverse adressing to trzeba miec DSP ktore wspiera -
jesli mnie pamiec nie myli maja to dopiero TI z rodziny 50, a sprzetowo
dlatego ze mozna trafic za grosze uklad ktory to zwyczajnie zrobi...
Naprawde nie wyobrazam sobie efektywnej implementacji FFT 16384 punkty
na 8 czy nawet 16 bitowym staloprzecinkowym procesorze o ograniczonych
zasobach i bez wsparcia w hardware... - juz predzej jakis ARM za 40zl
jako koprocesor FFT...
Adam Dybkowski
Guest
Guest
Sun Nov 26, 2006 1:40 am
BartekK napisał(a):
Quote:
Możesz przyjąć skończoną dokładność i robić obliczenia na liczbach
stałoprzecinkowych. Np. przeskalować wszystkie dane wejściowe do
zakresu <-1,1) i zapisać je jako liczy 16 bitowe (1 bit znaku i 15
bitów części ułamkowej).
Myslalem o tym, ale dla danych wejsciowych o rozdzielczosci 12bit (a
docelowo raczej 16bit) skalowanie do 16bit nie byloby sensowne chyba
(przeciez i tak juz maja zakres 0-0xffff) wiec mozna po prostu przyjac
ze to co jest zapisane jako 0-65535 to jest -1 do +1.
stałoprzecinkowych. Np. przeskalować wszystkie dane wejściowe do
zakresu <-1,1) i zapisać je jako liczy 16 bitowe (1 bit znaku i 15
bitów części ułamkowej).
Myslalem o tym, ale dla danych wejsciowych o rozdzielczosci 12bit (a
docelowo raczej 16bit) skalowanie do 16bit nie byloby sensowne chyba
(przeciez i tak juz maja zakres 0-0xffff) wiec mozna po prostu przyjac
ze to co jest zapisane jako 0-65535 to jest -1 do +1.
Pamiętaj jednak o prostych zasadach obliczeń na liczbach
stałoprzecinkowych, gdzie wymagana jest m.in. konwersja przy mnożeniu.
Przykładowo 1/2 * 1/2 = 1/4 ale proste zapisanie tego na liczbach
stałoprzecinkowych z 15 bitami ułamka i wykonanie mnożenia 0x4000 *
0x4000 dałoby zły wynik (0x10000000), trzeba po mnożeniu przesunąć wynik
o 15 bitów w prawo (wyjdzie 0x2000 czyli 1/4). Odwrotna konwersja
potrzebna przy dzieleniu.
--
Adam Dybkowski
http://www.amwaw.edu.pl/~adybkows/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Piotr Wyderski
Guest
Guest
Sun Nov 26, 2006 12:06 pm
PAndy wrote:
Quote:
Wierze Ci na slowo.
Nie ma takiej potrzeby. Wez np. sinus zsamplowany w 5
punktach i wyznacz DFT wektora dlugosci 5. Nastepnie
dopisz do niego 3 zera, zrób FFT wektora dlugosci 8
i porównaj wyniki. :-)
Quote:
Do tego by miec reverse adressing to trzeba miec DSP ktore wspiera - jesli
mnie pamiec nie myli maja to dopiero TI z rodziny 50, a sprzetowo dlatego
ze mozna trafic za grosze uklad ktory to zwyczajnie zrobi...
mnie pamiec nie myli maja to dopiero TI z rodziny 50, a sprzetowo dlatego
ze mozna trafic za grosze uklad ktory to zwyczajnie zrobi...
No tak, ale pytanie o to, po co komu taki uklad. Ja sobie
nie wyobrazam mozliwosci jego zastosowania w warunkach
amatorskich, a FFT uzywam. Pomijam przy tym fakt, ze
uklad zajmuje miejsce na plytce, pobiera energie i slabo
u niego z rekonfigurowalnoscia. Gdybym mial potrzebe
szybkiego policzenia FFT, to po prostu wzialbym mocniejszy
procesor, np.jakies zmiennoprzecinkowe DSP. Owszem,
mozna sobie kupic sprzetowy procesor fourierowski "to
impress chicks", ale ja pytam o rzeczywiste potrzeby... ;-)
Quote:
Naprawde nie wyobrazam sobie efektywnej implementacji FFT 16384 punkty na
8 czy nawet 16 bitowym staloprzecinkowym procesorze o ograniczonych
zasobach i bez wsparcia w hardware...
8 czy nawet 16 bitowym staloprzecinkowym procesorze o ograniczonych
zasobach i bez wsparcia w hardware...
Ale nie wiadomo, co dla kogo znaczy "efektywnie" -- jednemu wystarczy
taka transformata raz na sekunde, inny bedzie chcial co 100 mikrosekund.
Poza tym 16384 punkty to sporawo nawet jak na potrzeby przetwarzania
sygnalów -- zwykle wystarcza 1024 punkty.
Pozdrawiam
Piotr Wyderski
PAndy
Guest
Guest
Sun Nov 26, 2006 4:05 pm
"Piotr Wyderski" <wyderski@mothers.against.spam-ii.uni.wroc.pl> wrote in
message news:ekbser$ki0$1@news.dialog.net.pl...
Quote:
PAndy wrote:
Wierze Ci na slowo.
Nie ma takiej potrzeby. Wez np. sinus zsamplowany w 5
punktach i wyznacz DFT wektora dlugosci 5. Nastepnie
dopisz do niego 3 zera, zrób FFT wektora dlugosci 8
i porównaj wyniki.
Wierze Ci na slowo.
Nie ma takiej potrzeby. Wez np. sinus zsamplowany w 5
punktach i wyznacz DFT wektora dlugosci 5. Nastepnie
dopisz do niego 3 zera, zrób FFT wektora dlugosci 8
i porównaj wyniki.
nie omieszkam w wolnym czasie... ale JF ma priorytet - wisze mu jeden
opis...
Quote:
Do tego by miec reverse adressing to trzeba miec DSP ktore wspiera -
jesli mnie pamiec nie myli maja to dopiero TI z rodziny 50, a
sprzetowo dlatego ze mozna trafic za grosze uklad ktory to zwyczajnie
zrobi...
No tak, ale pytanie o to, po co komu taki uklad. Ja sobie
nie wyobrazam mozliwosci jego zastosowania w warunkach
amatorskich, a FFT uzywam. Pomijam przy tym fakt, ze
uklad zajmuje miejsce na plytce, pobiera energie i slabo
u niego z rekonfigurowalnoscia. Gdybym mial potrzebe
szybkiego policzenia FFT, to po prostu wzialbym mocniejszy
procesor, np.jakies zmiennoprzecinkowe DSP. Owszem,
mozna sobie kupic sprzetowy procesor fourierowski "to
impress chicks", ale ja pytam o rzeczywiste potrzeby...
jesli mnie pamiec nie myli maja to dopiero TI z rodziny 50, a
sprzetowo dlatego ze mozna trafic za grosze uklad ktory to zwyczajnie
zrobi...
No tak, ale pytanie o to, po co komu taki uklad. Ja sobie
nie wyobrazam mozliwosci jego zastosowania w warunkach
amatorskich, a FFT uzywam. Pomijam przy tym fakt, ze
uklad zajmuje miejsce na plytce, pobiera energie i slabo
u niego z rekonfigurowalnoscia. Gdybym mial potrzebe
szybkiego policzenia FFT, to po prostu wzialbym mocniejszy
procesor, np.jakies zmiennoprzecinkowe DSP. Owszem,
mozna sobie kupic sprzetowy procesor fourierowski "to
impress chicks", ale ja pytam o rzeczywiste potrzeby...
Hm... bo jest okazja... gdyby nie bylo okazji to jak najbardziej
proponowany przez Ciebie wariant jest najrozsadniejszy... a poza tym nie
jestem programista... rozwiazania w hardware sa dla mnie najlepsze :D
Quote:
Naprawde nie wyobrazam sobie efektywnej implementacji FFT 16384
punkty na 8 czy nawet 16 bitowym staloprzecinkowym procesorze o
ograniczonych zasobach i bez wsparcia w hardware...
Ale nie wiadomo, co dla kogo znaczy "efektywnie" -- jednemu wystarczy
taka transformata raz na sekunde, inny bedzie chcial co 100
mikrosekund.
Poza tym 16384 punkty to sporawo nawet jak na potrzeby przetwarzania
sygnalów -- zwykle wystarcza 1024 punkty.
punkty na 8 czy nawet 16 bitowym staloprzecinkowym procesorze o
ograniczonych zasobach i bez wsparcia w hardware...
Ale nie wiadomo, co dla kogo znaczy "efektywnie" -- jednemu wystarczy
taka transformata raz na sekunde, inny bedzie chcial co 100
mikrosekund.
Poza tym 16384 punkty to sporawo nawet jak na potrzeby przetwarzania
sygnalów -- zwykle wystarcza 1024 punkty.
Zdaje sobie sprawe - sporadycznie wykorzystuje FFT rzedu 2^16 -
zazwyczaj 2048 - 8192 w zupelnosci wystarcza
Quote:
Pozdrawiam
pozdrawiam i dziekuje
BartekK
Guest
Guest
Mon Nov 27, 2006 2:55 pm
pisz_na.mirek@dionizos.zind.ikem.pwr.wroc.pl napisał(a):
Quote:
BartekK <sibi@drut.org> wrote:
mk napisał(a):
A co się tak uparłeś samodzielnie kodować ten algorytm, kiedy pełno
dostępnych gotowych.
Chociażby pierwszy z brzegu:
http://www.archelon.com/fft.html
A moze masz gdzies pod reka gotowca, ktory by poszedl bez floatow,
najlepiej bez liczenia cosinusow w locie (chocby z tablicy) - zalezy mi
glownie na predkosci, jakby sie udalo to na AVR bym chcial to robic :)
http://www.jjj.de/fft/fftpage.html
Dziekuje! Chyba o cos takiego mi chodzilo, z tego co widze.
mk napisał(a):
A co się tak uparłeś samodzielnie kodować ten algorytm, kiedy pełno
dostępnych gotowych.
Chociażby pierwszy z brzegu:
http://www.archelon.com/fft.html
A moze masz gdzies pod reka gotowca, ktory by poszedl bez floatow,
najlepiej bez liczenia cosinusow w locie (chocby z tablicy) - zalezy mi
glownie na predkosci, jakby sie udalo to na AVR bym chcial to robic :)
http://www.jjj.de/fft/fftpage.html
Dziekuje! Chyba o cos takiego mi chodzilo, z tego co widze.
--
| Bartlomiej Kuzniewski
| sibi@drut.org GG:23319 tel +48 696455098 http://drut.org/
| http://www.allegro.pl/show_user_auctions.php?uid=338173
Maciej
Guest
Guest
Mon Nov 27, 2006 4:03 pm
Uzytkownik "J.F." <jfox_xnospamx@poczta.onet.pl> napisal w wiadomosci
news:6qfdm21v8nt0ak4leobscgsg35u0qt82ha@4ax.com...
Quote:
DCT to nie jest DFT.
J.
J.F.: To juz jest, rzecz jasna, kwestia terminologii. Jezeli sygnal jest
rzeczywisty i symetryczny
(mozemy przeciez symetrycznie rozszerzyc), to DFT i DCT to to samo. Liczymy
tylko na liczbach rzeczywistych, kosztem dluzszego wektora transformaty.
Maciej
J.F.
Guest
Guest
Mon Nov 27, 2006 4:21 pm
On Mon, 27 Nov 2006 16:03:16 +0100, Maciej wrote:
Quote:
Uzytkownik "J.F." <jfox_xnospamx@poczta.onet.pl> napisal w wiadomosci
DCT to nie jest DFT.
J.F.: To juz jest, rzecz jasna, kwestia terminologii. Jezeli sygnal jest
rzeczywisty i symetryczny (mozemy przeciez symetrycznie rozszerzyc)
DCT to nie jest DFT.
J.F.: To juz jest, rzecz jasna, kwestia terminologii. Jezeli sygnal jest
rzeczywisty i symetryczny (mozemy przeciez symetrycznie rozszerzyc)
Jesli rozszerzysz, to jest to juz inna funkcja.
Quote:
, to DFT i DCT to to samo. Liczymy
tylko na liczbach rzeczywistych, kosztem dluzszego wektora transformaty.
tylko na liczbach rzeczywistych, kosztem dluzszego wektora transformaty.
A chociaz liczy sie szybciej ? :-)
J.
Maciej
Guest
Guest
Mon Nov 27, 2006 4:38 pm
Uzytkownik "J.F." <jfox_xnospamx@poczta.onet.pl> napisal w wiadomosci >
Quote:
Jesli rozszerzysz, to jest to juz inna funkcja.
A chociaz liczy sie szybciej ? :-)
J.
A chociaz liczy sie szybciej ? :-)
J.
J.F.: To znowu kwestia terminologii. Funkcja jest ta sama, tylko odtwarza
sie z innych wspolczynnikow, innymi wzorami. Szybkosc tez jest ta sama, bo
to jest ten sam algorytm.
Oczywiscie, w konkretnych przypadkach ktoras z postaci moze sie okazac
lepsza.
Pozdrowienia,
Maciej
J.F.
Guest
Guest
Mon Nov 27, 2006 5:19 pm
On Mon, 27 Nov 2006 16:38:30 +0100, Maciej wrote:
Quote:
Uzytkownik "J.F." <jfox_xnospamx@poczta.onet.pl> napisal w wiadomosci
Jesli rozszerzysz, to jest to juz inna funkcja.
A chociaz liczy sie szybciej ? :-)
J.F.: To znowu kwestia terminologii. Funkcja jest ta sama, tylko odtwarza
sie z innych wspolczynnikow, innymi wzorami.
Jesli rozszerzysz, to jest to juz inna funkcja.
A chociaz liczy sie szybciej ? :-)
J.F.: To znowu kwestia terminologii. Funkcja jest ta sama, tylko odtwarza
sie z innych wspolczynnikow, innymi wzorami.
No wlasnie nie jest. Czesc wspolczynnikow _od biedy_ pasuje.
A reszta nie.
Quote:
Szybkosc tez jest ta sama, bo to jest ten sam algorytm.
Hm, na DCT sie tak dobrze nie znam, ale wydaje mi sie ze algorytmy
wcale nie sa te same.
J.
mk
Guest
Guest
Mon Nov 27, 2006 10:34 pm
Newsuser "Maciej" <m_usun_pal@usun.math.uni.wroc.pl> wrote:
Quote:
DCT to nie jest DFT.
J.
J.F.: To juz jest, rzecz jasna, kwestia terminologii. Jezeli sygnal jest
rzeczywisty i symetryczny
(mozemy przeciez symetrycznie rozszerzyc), to DFT i DCT to to samo.
Liczymy tylko na liczbach rzeczywistych, kosztem dluzszego wektora
transformaty.
J.
J.F.: To juz jest, rzecz jasna, kwestia terminologii. Jezeli sygnal jest
rzeczywisty i symetryczny
(mozemy przeciez symetrycznie rozszerzyc), to DFT i DCT to to samo.
Liczymy tylko na liczbach rzeczywistych, kosztem dluzszego wektora
transformaty.
Okay. Rozszerzamy symetrycznie niesymetryczny sygnał.
Liczymy i... w wyniku obliczeń uzyskujemy zupełnie inne wyniki, niż daje
DFT...
Jak przekształcić teraz te wyniki (?), by uzyskać to, co daje DFT (bo o to
nam chodzi).
pzdr
mk
Maciej
Guest
Guest
Mon Nov 27, 2006 11:27 pm
Użytkownik "mk" <REVERSE_lp.pw@myzskm.REMOVE> napisał w wiadomości
news:ekflih$kch$1@inews.gazeta.pl...
Quote:
Okay. Rozszerzamy symetrycznie niesymetryczny sygnał.
Liczymy i... w wyniku obliczeń uzyskujemy zupełnie inne wyniki, niż daje
DFT...
Jak przekształcić teraz te wyniki (?), by uzyskać to, co daje DFT (bo o to
nam chodzi).
pzdr
mk
Rany, przeciez tojest prosta sprawa. Mamy sygnal f skladajacy sie z N
rzeczywistych wartosci,
f(i), i=0,...,N-1. Zamiast myslec o nim, myslimy o sygnale g skladajacym sie
z 2N wartosci,
symetrycznie rozmieszczonych wokol zera, ktory jest symetryczny wokol zera,
czyli g(-i)=g(i).
To jest prosta sprawa, nic nowego nie wnosi, nic sie nie traci. Nasze
wyjsciowe N probek f pozostaje niezmienione, to jest teraz prawa polowka 2N
probek g.
Obliczamy DTF tego sygnalu g. Bedzie miala dlugosc 2N probek, tak jak i g.
Ale te probki sa liczbami rzeczywistymi, sumowanie czesci urojonych (czyli
sygnalu rzeczywistego pomnozonego przez sinusy), ze wzgledu na parzystosc g
i nieparzystosc sinusa daje zero. A wiec wspolczynniki Fouriera sygnalu g sa
sumami sygnalu pomnozonego przez cosinusy. Dodajac do siebie elementy sumy
na lewo od zera z elementami na prawo (sa rowne, bo i cosinus i g sa
parzyste), dostajemy cos, co nazywa sie dyskretna transformata cosinusowa
wyjsciowego sygnalu f.
Czy ta rzeczywista transformata cosinusowa to jest transformata Fouriera czy
to nie jest juz transformata Fouriera, bo jest inaczej zapisana, to kwestia
terminologii. Przy okazji: to co opisalem to jest jeden z kilku wariantow
transformaty cosinusowej, ktore sa w uzyciu.
Tylko tyle chcialem powiedziec.
Pozdrowienia,
Maciej
mk
Guest
Guest
Tue Nov 28, 2006 12:05 am
Newsuser "Maciej" <m_usun_pal@usun.math.uni.wroc.pl> wrote:
Quote:
Okay. Rozszerzamy symetrycznie niesymetryczny sygnał.
Liczymy i... w wyniku obliczeń uzyskujemy zupełnie inne wyniki, niż daje
DFT...
Jak przekształcić teraz te wyniki (?), by uzyskać to, co daje DFT (bo o
to nam chodzi).
pzdr
mk
Rany, przeciez tojest prosta sprawa. Mamy sygnal f skladajacy sie z N
rzeczywistych wartosci,
f(i), i=0,...,N-1. Zamiast myslec o nim, myslimy o sygnale g skladajacym
sie z 2N wartosci,
symetrycznie rozmieszczonych wokol zera, ktory jest symetryczny wokol
zera, czyli g(-i)=g(i).
To jest prosta sprawa, nic nowego nie wnosi, nic sie nie traci. Nasze
wyjsciowe N probek f pozostaje niezmienione, to jest teraz prawa polowka
2N probek g.
Obliczamy DTF tego sygnalu g. Bedzie miala dlugosc 2N probek, tak jak i
g. Ale te probki sa liczbami rzeczywistymi, sumowanie czesci urojonych
(czyli sygnalu rzeczywistego pomnozonego przez sinusy), ze wzgledu na
parzystosc g i nieparzystosc sinusa daje zero. A wiec wspolczynniki
Fouriera sygnalu g sa sumami sygnalu pomnozonego przez cosinusy. Dodajac
do siebie elementy sumy na lewo od zera z elementami na prawo (sa rowne,
bo i cosinus i g sa parzyste), dostajemy cos, co nazywa sie dyskretna
transformata cosinusowa wyjsciowego sygnalu f.
Liczymy i... w wyniku obliczeń uzyskujemy zupełnie inne wyniki, niż daje
DFT...
Jak przekształcić teraz te wyniki (?), by uzyskać to, co daje DFT (bo o
to nam chodzi).
pzdr
mk
Rany, przeciez tojest prosta sprawa. Mamy sygnal f skladajacy sie z N
rzeczywistych wartosci,
f(i), i=0,...,N-1. Zamiast myslec o nim, myslimy o sygnale g skladajacym
sie z 2N wartosci,
symetrycznie rozmieszczonych wokol zera, ktory jest symetryczny wokol
zera, czyli g(-i)=g(i).
To jest prosta sprawa, nic nowego nie wnosi, nic sie nie traci. Nasze
wyjsciowe N probek f pozostaje niezmienione, to jest teraz prawa polowka
2N probek g.
Obliczamy DTF tego sygnalu g. Bedzie miala dlugosc 2N probek, tak jak i
g. Ale te probki sa liczbami rzeczywistymi, sumowanie czesci urojonych
(czyli sygnalu rzeczywistego pomnozonego przez sinusy), ze wzgledu na
parzystosc g i nieparzystosc sinusa daje zero. A wiec wspolczynniki
Fouriera sygnalu g sa sumami sygnalu pomnozonego przez cosinusy. Dodajac
do siebie elementy sumy na lewo od zera z elementami na prawo (sa rowne,
bo i cosinus i g sa parzyste), dostajemy cos, co nazywa sie dyskretna
transformata cosinusowa wyjsciowego sygnalu f.
No i policzyłeś DCT przy pomocy DFT.
A celem jest obliczyć DFT.
Zasugerowałeś, że do obliczenia DFT można wykorzystać DCT. Nadal nie ma
odpowiedzi jak to zrobić.
Quote:
Czy ta rzeczywista transformata cosinusowa to jest transformata Fouriera
czy to nie jest juz transformata Fouriera, bo jest inaczej zapisana, to
kwestia terminologii.
czy to nie jest juz transformata Fouriera, bo jest inaczej zapisana, to
kwestia terminologii.
Nie. Z tego, że, w szczególnych przypadkach prostokąt jest kwadratem nie
wynika to, że kwadraty są prostokątami.
pzdr
mk
mk
Guest
Guest
Tue Nov 28, 2006 12:48 am
Newsuser "mk" <REVERSE_lp.pw@myzskm.REMOVE> wrote:
Quote:
Nie. Z tego, że, w szczególnych przypadkach prostokąt jest kwadratem nie
wynika to, że kwadraty są prostokątami.
wynika to, że kwadraty są prostokątami.
Coś mi się tu pozajączkowało ;-)
pzdr
mk
elektroda NewsGroups Forum Index - Elektronika Polska - Jak efektywnie obliczyć transformację FFT dla 15000 punktów bez całek?