Linuxを中心とした話題を投稿予定。 使用ディストリビューションであるFedoraが中心になると思われます。http://oedipa.wiki.fc2.com/にてTips Wikiを公開してます。
スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
解決はしたけれど別の問題が・・・
後輩のプログラムのバグは無事修正され、きちんと動作しております。が、私の方がまだまともに動いてくれていないためデバッグすることに。

(個人的には)今回のプログラムは見通しよく作ったつもりなのでフローを追いかけるのは容易だったのですが、何度見返してもおかしげなところがない。後輩のプログラムのフローは私が教えたとおりのフローでしたし、私自身そのフローに沿って組んでいるし。

で、パラメータをいじってみるとちょいと規則性が見えてきたり。本来、いかなる場合においても0~4の範囲で設定できるはずのパラメータが、バッファサイズに反比例して狭まっていることが判明。

なぜそうなるのかは不明ですが規則性が見つかれば解決のとっかかりになる。ってなわけで注意深く追っていくと、どうも発散するのは序盤だけであり、ある程度収束方向に向かっている最中にパラメータを最適値へ変更してやるときちんと収束することが発覚(デバッガってほんと便利)。

つまり根本のアルゴリズムが間違っているわけではないし、FFTする系列の順序が間違っているわけでもないという確証は取れました。となると、後輩のプログラムと私のプログラムで異なっているのはFFTの方式くらい。後輩の(と私の前回の)プログラムで使用しているFFTの方式は非対称な方式で、IFFTの際に1/Nを掛けて大きさを調節するタイプなんですよね。で、今回私が使用していた方式は対称な方式。確か1/sqrt(N)を両変換の際に掛けるんだっけかな。ライブラリだからあんまり中身見てないけれど、確かそうだったはず^^;

ただ、どちらの方式であれ、FFT->IFFTの結果に変化は起こりません。ちゃんと元に戻ります(ごくごく小さな誤差は出ますが)。
とはいえFFTくらいしか差がないためダメ元でFFTの方式を非対称の方式に直してみると、なんと収束!!!

つまりはFFTの方式によってはパラメータが変わる可能性があるということです。これが私のプログラムの組み方が悪くてそうなっているだけなら私の能力不足&勉強不足ってだけなので大した問題にはなりませんが、ほんとに方式によってはパラメータが変化すると言うことであれば大問題です。信号処理の世界で使われている形式は通常非対称だよ、ということであれば実用上さほど問題にはならないでしょうが・・・。

ちょっとこれは気になるので週明けに後輩君に頼んで別のFFTの方式でも試して貰うことにしよう。で、もし私と同じ結果が出たらちょいと問題かも。

あぁまったく、まさかこんなところに落とし穴があるとはな・・・!!!

誰かが覚えていてくれるという事は、きっと幸せな事だ。時々誰かが僕を思い出してくれるという事は、僕が居たということの証明だから


こなたよりかなたまで 遙 彼方

心の中に生き続ける、ということに繋がるのかな。法事なんかで坊さんが「故人を偲んで~」と説法をしてくださいますが、そうして記憶の中にあり続ける限りはその存在は消えずに残り続けるんでしょうね。

思い出はただただ美しく、かな?^^
関連記事
スポンサーサイト
コメント
この記事へのコメント
コメントを投稿
URL:
Comment:
Pass:
秘密: 管理者にだけ表示を許可
 
トラックバック
この記事のトラックバックURL
この記事へのトラックバック
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。