Tipovi podataka
Grujo, ovo je prevashodno tebi namenjeno.
Zakljucio sam da ne mozemo da koristimo 16-bitni floating point zapis podataka, jer je previse mali raspon brojeva i previse mala preciznost za algoritam LU dekompozicije. Raspon apsolutne vrednosti mantise bi bio od 2^(-8) do 1-2^(-12), a eksponenta od 2^(-7) do 2^7. Ovo otprilike znaci da bi apsolutna vrednost broja mogla da se krece od oko 0.04 do oko 127.97, uz mogucu gresku vec na drugoj decimali od oko 0.04. Ovo smatram poprilicno neprihvatljivim za potrebe nase aplikacije. Nista bolji rezultat ne bismo dobili ni kada bismo koristili fixed piont zapis, samo bi se teze vrsilo mnozenje i deljenje. Rad sa integerima, tesko da moze da dodje u obzir, jer algoritam LU dekompozicije zahteva deljenje realnih brojeva, i makar ja nisam uspeo da smislim ni jedan nacin .
Takodje, za rad sa float brojevima je za svaku aritmeticku operaciju potrebno izvrsiti malo vise aritmetickih operacija nego za integer (cak je i samo sabiranje i oduzimanje komplikovanije). To znaci da ce nam svaka aritmeticka operacija oduzimati malo vise procesorskog vremena nego sto smo planirali. A tek kad uracunamo da cemo morati da radimo sa kompleksnim brojevima, glava me zaboli.
Kompromis do koga sam dosao jeste da se radi sa 32-bitnim float brojevima, ali takvim da mantisa bude 16 bita, i eksponent 16 bita. Ovo bi dalo dovoljnu preciznost, a bilo bi znatno brze za racunanje aritmetickih operacija nego klasican floating point sa 24 bita mantise i 8 bita eksponenta. Naravno, i ovde bi sve aritmeticke operacije trajale duze nego za integere. Sabiranje i oduzimanje bi bilo u oko 10 ciklusa (mozda i koji vise, a mozda i koji manje), a deljenje i mnozenje u oko 30-ak ciklusa (mozda i koji manje). Takodje bi bilo gadno to sto ne bismo mogli tek tako da koristimo MAC instrukcije, ali sad sta je tu je. Ovo se odnosi makar na deo koji se tice LU dekompozicije. Mozda bi posle LU dekompozicije moglo da se izvrsi neko sredjivanje rezultata tako da se na kraju svi rezultati zapisu u nekoj vrsti integer forme, pa da mogu dalje da se brzo obradjuju, ali ovu ideju treba malo bolje razmotriti. Takodje jedna od mana svega ovoga je sto ce podaci zauzimati vise memorije, ali mislim da memorija nece biti kriticna ako budemo uspeli ceo algoritam obrade da izvrsavamo u 12000 ciklusa ("u letu" izmedju snimanja odabiraka sa mikrofona). Sve jedno, mislim da cemo ipak morati sve da uradimo na ovaj nacin.
Pedja
P.S.
Svaka bolja ideja od ove (a ujedno i razumna) ce biti razmotrena, ali cu ja za sada algoritam bazirati na ovoj ideji.
Zakljucio sam da ne mozemo da koristimo 16-bitni floating point zapis podataka, jer je previse mali raspon brojeva i previse mala preciznost za algoritam LU dekompozicije. Raspon apsolutne vrednosti mantise bi bio od 2^(-8) do 1-2^(-12), a eksponenta od 2^(-7) do 2^7. Ovo otprilike znaci da bi apsolutna vrednost broja mogla da se krece od oko 0.04 do oko 127.97, uz mogucu gresku vec na drugoj decimali od oko 0.04. Ovo smatram poprilicno neprihvatljivim za potrebe nase aplikacije. Nista bolji rezultat ne bismo dobili ni kada bismo koristili fixed piont zapis, samo bi se teze vrsilo mnozenje i deljenje. Rad sa integerima, tesko da moze da dodje u obzir, jer algoritam LU dekompozicije zahteva deljenje realnih brojeva, i makar ja nisam uspeo da smislim ni jedan nacin .
Takodje, za rad sa float brojevima je za svaku aritmeticku operaciju potrebno izvrsiti malo vise aritmetickih operacija nego za integer (cak je i samo sabiranje i oduzimanje komplikovanije). To znaci da ce nam svaka aritmeticka operacija oduzimati malo vise procesorskog vremena nego sto smo planirali. A tek kad uracunamo da cemo morati da radimo sa kompleksnim brojevima, glava me zaboli.
Kompromis do koga sam dosao jeste da se radi sa 32-bitnim float brojevima, ali takvim da mantisa bude 16 bita, i eksponent 16 bita. Ovo bi dalo dovoljnu preciznost, a bilo bi znatno brze za racunanje aritmetickih operacija nego klasican floating point sa 24 bita mantise i 8 bita eksponenta. Naravno, i ovde bi sve aritmeticke operacije trajale duze nego za integere. Sabiranje i oduzimanje bi bilo u oko 10 ciklusa (mozda i koji vise, a mozda i koji manje), a deljenje i mnozenje u oko 30-ak ciklusa (mozda i koji manje). Takodje bi bilo gadno to sto ne bismo mogli tek tako da koristimo MAC instrukcije, ali sad sta je tu je. Ovo se odnosi makar na deo koji se tice LU dekompozicije. Mozda bi posle LU dekompozicije moglo da se izvrsi neko sredjivanje rezultata tako da se na kraju svi rezultati zapisu u nekoj vrsti integer forme, pa da mogu dalje da se brzo obradjuju, ali ovu ideju treba malo bolje razmotriti. Takodje jedna od mana svega ovoga je sto ce podaci zauzimati vise memorije, ali mislim da memorija nece biti kriticna ako budemo uspeli ceo algoritam obrade da izvrsavamo u 12000 ciklusa ("u letu" izmedju snimanja odabiraka sa mikrofona). Sve jedno, mislim da cemo ipak morati sve da uradimo na ovaj nacin.
Pedja
P.S.
Svaka bolja ideja od ove (a ujedno i razumna) ce biti razmotrena, ali cu ja za sada algoritam bazirati na ovoj ideji.