まさか対応予定があるとは考えてすらいなかったよ

MS、Flash対抗「Silverlight」を正式リリース
MicrosoftのAdobe Flash対抗技術、Silverlightが正式リリース。Flashはほんと幅広く浸透しましたからねぇ。それに対してどこまで肉薄できるか、見ものではあります。
ただ、正直あんまり気にもしてなかったんですよね、Silverlightは。だって、Microsoftでしょう？ しかもWindowsMediaを利用すると聞いちゃぁ、
「あぁ、Linuxは関係ないさな」
と思うのも無理は無いと思うんですよ、えぇ。オフライン、あるいはオンラインでもただ埋め込んである程度ならMplayerなどで視聴可能ですが、これがブラウザのプラグインとなり、WindowsMediaはコンポーネントの1つとなってしまうと話は別です。Linux用のプラグインなんて提供される訳はないよな、そう思ってました。
その点FlashはLinux用のプラグインも提供してくれているし、まぁSilverlightはどうでもいいか、せっかくの.NETなのになぁとあまり情報も集めないでいたんですよ。そしたらなんと、「Moonlight」プロジェクトとしてMonoと協力してLinux版も開発中だとか！
SUSEがMicrosoftに擦り寄ってどっかんどっかん叩かれたけど、意外なお土産を落としてくれたもんだ、うん。
けど、WindowsMediaコンテンツについてはどうするんだろう？ Mplayerは別プロジェクトだし、そもそもオープンソースだから組み込む訳には行かないだろうし・・・？ 動画再生も可能にしたら、どうせならWMPのLinux版みたいなのも作ってほしいもんなんだけど（ぉ C#でそこまで組めるのかは分かりませんが＾＾；
既にMac版はリリースされているということで、クロスプラットフォーム展開は考えているようです。.NETはMicrosoftが推し進めてますしね。PDF対抗技術と違ってそうそう簡単には潰えない・・・と信じたい(苦笑)
ブラウザ用のプラグインもそうだけど、.NET FrameworkにJavaでいうSwingみたいなのをつけてほしいなぁ。そしたらLinuxでのプロジェクトも増えそうなものなのに。GTKはちょっち微妙っすよ＾＾；

なんか色々と行き詰まった

自分の論文は一応書き上がりました。これで一安心、かな？
中間発表までにスライドを仕上げなくてはいけませんが、まぁなんとかなるでしょう。つかしなきゃな。
で、SuperKarambaの日本語パス問題をどうにかしようと奮闘中ですが、ちょっと諦めモード。Python自体は日本語パスだろうと問題なく処理します。PythonからUNIXのプロセスを直接呼び出せるんですが、それは日本語を含むパスだろうと何も問題にならないんですね。ですが、SuperKarambaのPythonモジュールであるAPIに日本語のパスを渡すとダメみたい。謎だ・・・。
一応KDEのツールキットであるQtは文字列をunicodeで扱うことが出来るため、おそらくはSuperKarambaも文字列はunicodeで扱っていると思うのですが・・・、なんでだろ。
SuperKarambaのウィジェットにはamaroKの再生中のアルバムジャケットを表示するものがあり、そいつは日本語のパスにおかれたジャケット画像であろうと問題なく表示していたので、これを参考にしたらいいんじゃね？と思ってスクリプトを見てみたんです。
するとびっくり。amaroKは登録したアルバムジャケットの画像を自動でサムネイル化し、ランダム名にてキャッシュしてたんですね。そのキャッシュ画像の保存場所は各ユーザのKDEアプリ設定等が保存される場所で、日本語のパスが含まれていないため何の問題もなく表示されていたのでした。一度アルバムジャケットとして登録したらその画像がどっか行っても問題なかったという訳ですね。知らなかった・・・。
ということで、SuperKarambaで日本語を含むパスにアクセスする方法についてはひとまず断念。アスペクト比を固定して一定のサイズ以下に縮小して表示することまでは出来たのでひとまずはこれでよいかなと。スライドショーで表示してみて思ったけど、枠なしってのは思いの外味気ないなぁ。ちゃんと枠でもつけようかしら。
話は打って変わって、家のXの設定について。大学のPCではBerylが不安定とか言うこともないので、大学のLinuxマシンのxorg.confを持って帰ってきて比較してみたんですよ。
そしたら違いなんてろくすっぽないんですね。ドライバを再インストールとかもしてみましたが、再起動して数分でXが強制再起動喰らいましたOrz /var/log/Xorg.0.logファイルにも何もエラーが書き込まれてないんですよねぇ。おかげで原因不明。手の施しようがないのが辛いところ。
大学のマシンがX再起動とか喰らわないあたり、やっぱり私の環境がまずいのだろうと。もう今更どの設定ファイルがおかしいのかとか考えたところで埒があかないでしょうから、OS入れ直した方が早いんでしょうけれどね・・・。Fedora8が出たときに本格的に考えましょう。
さて、ここ数日SuperKarambaに掛かりきりで寝不足。明日も頑張らなきゃ行けないし、さっさと寝るかぁ・・・。

ていうかありえな〜い

あんまり気付いてなかったけど、今月どうも忙しいらしい（ぇ
今月末に中間発表があるのですが、B4の進捗具合がそれなりにヤヴァイ。
中間発表までに、こんくらいは片付けておきましょう
そう考えていたところまでに遥か及ばない。そんなにのんびりしていたつもりはなかったんだけどなぁ。自分はともかく、ちょいと後輩の方は前倒しで進めていかないと大変そうだ。
ということで、私の研究を引き継ぐ後輩の面倒を見ることに。サボっている訳ではないけれどなかなか結果を出せない後輩のプログラムの間違い探し。他人のプログラムって見るのしんどいんだよなぁ・・・。まぁプログラムは受け取ったし、明日くらいに眺めてみよう、うん。
そんな自分も今週中に論文をほぼ完成させる必要アリ。今日はシミュレーション結果をゴリゴリ集めてましたよ、えぇ。全部集めてしまう気でいましたがちょいとミスで集めきれず。無念。
普段私はあまりファイルからの入出力を実装しないんですね。扱うのは音声信号だし、それって結局ただの数値データなので、入出力はリダイレクトで片付けることが多かったんですよ。
それが今はWindowsでの開発なので出力はともかく入力がやりにくい。しゃーないので今回は実装してるんですが、慣れていないもので見事ミスしてましたOrz
1行読み込んでいるつもりできちんと読めてませんでした。おかげでそれ以降の入力が全部ずれ込んで、1時間ちょっとぶん回したプログラムの結果が水泡と帰しました；；
その部分の修正だけは施したので明日また1時間ぶん回そう。
やっぱC++は実行速度速いですね。まぁC#のメリットはもっと違うところにある訳で、それを比較するのは間違いでしょうけれど。けどメモリ管理はもっと自分で管理用のクラスなりライブラリを作っておく方が良さげやな。ケアレスミスが多すぎて怖いや。
さて、研究は研究、趣味は趣味。さてさて今からまたSuperKarambaスクリプトと戯れましょうかね＾＾

何故？ 何故なの？ 何故なのよ・・・・・！！！

おっと気付けばこんな時間。早く眠りたいと思いつつ備忘録的なBlogポスト。
今日はSuperKaramba&Pythonと格闘しておりました。Pythonは今回初めて触るので結構戸惑いましたねぇ。内部での処理についてはどうということはないのですが、日本語の文字列に関する扱いにしばらく頭を悩ませました。
というのも、Pythonは内部での文字列処理を基本unicodeで処理するのですが、外部(コンソールなど)に出力しようとすると、きちんとエンコードを指定してやらないとunicodeのまま出力するため16進数をそのまま出力したりasciiをそのまま出力したりしちゃうんですよねぇ。それは困るぞ、と。
でまぁそれはencode()メソッドを呼び出し、引数にシステムの文字コードを与えてやることで解決できることが分かりました。
それで万事解決、と行けば良かったのですが、そうは問屋が卸さない。文字列処理としてはそれでよいらしいのですが、なぜかパスとしてそれを与えてもきちんと認識してくれない模様。これがSuperKarambaの仕様なのかどうなのか、そこが分からないんですよねぇ・・・。
エンコードしないまま文字列を引き渡すと処理できないと文句垂れられるし、エンコードして引き渡すと"そんなパスねぇよ！"とでも言わんばかりのnull pointer。ちょいと今の段階ではお手上げに近いなぁ。
パスに日本語が使われていると正しく処理できないというのはどうしても腑に落ちないんだよなぁ。Python自体はunicodeで処理するからパスは正しく扱えるはず。ってことはSuperKarambaがunicodeのパスを受け取ってそれをどう処理しているかだけど・・・、それは正直分からないんだよなぁ。ソースコードを追いかけるしかないのか・・・？ SuperKarambaに燗する日本語の情報が少ないからなぁ。未だに"SuperKaramba"でぐぐると私のBlog記事が上位に表示されるってそれどーよ？(ただし、iGoogleだから補正は掛かってると思う)
う〜ん、これが解決できないと悔しいなぁ。画像スライドショーウィジェット作ったけど、日本語を含んだパスは使えません、では利便性悪すぎ。どうにかこうにか解決しないと。
PythonでKarambaスクリプトを無理に作らなくても表示自体は可能だけど、画像の拡縮とかそのあたりの制御はKarambaモジュールが最初から用意してくれてるからそれを利用するのがスマートだと思うんよなぁ。
KarambaでのPythonスクリプトの扱い方は大体分かって来たから、後は日本語を含んだパスの問題だけだ。これはPythonよりもKaramba側に要因がありそうだから、今はそれはほっといて細かい部分を詰めて行ってみよう。きっと解決策はあるでしょ。Karambaもファイルシステム自体はQtのライブラリ呼んでるだけだし、そのライブラリはもちろん日本語パスを扱えるのだし。
さて、今日はもう寝て、明日また頑張ろう。
私のLinux環境は不安定やからなぁ・・・。安定させるには再インストールが一番手っ取り早いが・・・、どうせならFedora8まで頑張ってみたいところ。Fedora8までいくと、なんとRH8からカウントしてOSアップグレード10代目。節目までは突っ走ってみたいわ(笑)
そこまで行ったら64bitに入れ替えたいわね。けどものぐさな私のことだから、どうせならFedora10まで行こうかとか考えちゃうのかしら？w

んなわけねーじゃないですか

え〜、昨日、収束はしたけれど微妙に納得のいっていなかったプログラムですが、行列の演算を間違っておりましたOrz
自分で表記した行列の要素の詰め方が間違っており、なおかつ行列の積の順序を間違えているという体たらく。行列の積としてではなく、各要素毎の演算として表記したら間違いは起きなかったのですが、それだと表記がくちゃくちゃになるため、行列で表記した方がスッキリするんですね。
で、それならいっそのことついでに実装も行列演算を実装しようってことで実装したのが運の尽き。実装方法は行列演算に忠実だったのですが、その要素の詰め方を間違っており、しかもその詰め方だと行列を掛ける順序が逆だったという罠。
まぁ原因も分かってスッキリしたのでいいです。論文は至急書き直す必要がありますが、まぁ提出期限は今月21日なのでどうとでもなるでしょう。幸い図の修正は必要ありませんし。テキスト部分のみの修正なら気をつけさえすれば知れた作業量ですね。
ところで今日は飲み会でした。私達修士2年生が全員就職先が決定したと言うことで、そのお疲れ会です。駅前の居酒屋でぱ〜っと宴会。
今日は私にしてはハイペースに呑んだのでがっつり酔っぱらって帰ってきました＾＾；　きっと帰りの電車でのテンションはおかしいものだったに違いない・・・ｗ
帰ってきてからもすっごく眠かったからなぁ。まぁお風呂入ってむしろ眠気は覚めたんだが（ぉ　おかげでBlogを掛けるほどに意識は回復。楽しい飲み会ではありましたね。
ただ、講座だけでなく同期の間でも私の立ち位置はヲ○クというか虐げられているような感じになってきてしまった気がする＞＜
悲しいかなでも私ドMらしいんだよな〜。いくつかの簡易判定法を試してみた（試されたこともあったな）けれど、いずれもM判定。というかドM判定Orz　まぁ、薄々は感じていたけどね・・・。
ま、楽しけりゃいいか！（ぉ
さて、今週のノルマは論文の修正とプログラムの整理・必要なデータ採集かな。なんか家のPCより大学のPCの方が実行速度が遅く感じたのは何故だろう・・・？　クロック的には大学のPCの方がHTを考慮しても早いのに。やっぱ実クロックが同程度ならデュアルコアの方が強いのかしら？　特にマルチスレッドに対応したプログラムにしたわけではないんだけどな。FFTをマルチスレッドにも出来たけど、あえてするほどでもないと思ったし。というか、FFTの時間を短縮できたとしても、処理全体の1%にも満たない気がするし。アルゴリズムの根本的な改良が必要だからなぁ。それも今週のうちに草案を練っておくか。
さて、今週もビリっと頑張るぞ〜！

ぐさー、だくだくだくだく

ここ数日悩み続けたプログラム収束しない謎ですが、ようやく解決。無事収束するようになりました。
が、正直言って納得できていなかったり。ちょいと理論にも関わってしまうのでもう少し細かい部分を詰めてチェックはしなきゃですね。
ただ、動作するようにはなったのでひとまずは安心。C#に比べるとやはり実行速度が上がってますね。比べるのはいかんことではありますが。また、FFTのライブラリがありがたいことにメモリ節約に貢献してくれましたし。
ただ、メモリ管理はやはり面倒だし、バッファオーバーフローなどのケアレスミスも相変わらず多いので、あまり組みたくないのが本音＾＾；
動作確認用のプロトタイプはC#で、がっつり条件を変えてベンチ的なシミュレーションを行いたいときはC++で実装、ってのが私に合っている気がします。最近ではMATLABも多少覚えてきたのでそちらもプロトタイプ作成に使えそうですね。
今回組んでいて思ったのは、配列渡したらグラフ描画してくれるライブラリが欲しいなってことです。C#にはあったんで持ってるんですが、C++用で扱いやすそうなのが見当たらないんですよねぇ。あるとは思うんですが。やっぱり結果をぱぱっと確認するにはグラフ描画ってのが便利ですからねぇ。Linuxならgnuplotにアタッチしたらいいんですけど、Winだとどうなんだろ？　なんか便利なライブラリないかしら。そう考えるとやっぱりMATLABは便利よねほんと。
とりあえず今までの研究で取り組んできたアルゴリズムはC#に集結させているので、それをC++にも移植して後輩に残しておきたいところ。C#は後輩たちには不評だからなぁ。便利なんだぜ？（苦笑
さて、懸念していたプログラムができあがったので、ここからは趣味の時間だ！　さぁて、カレンダーウィジェットでも作りますかねぇ＾＾

なんですか、もう

C#で組んだシミュレーションプログラムをC++に移植し始めて約1週間。ようやく終わりが見えてきました。
というか、デバッグデバッグで、ようやく結果らしい結果が出たってとこですね。それでもまだ正しい結果を吐いてくれないので地道にチェックして行かなくてはいけませんがOrz
単純にアルゴリズムを移植しているだけの部分が半分、根本的に書き換えたところが半分ってところなので、割とコーディングはスッキリしたけれどまだ把握できていない部分もあったりします。とりあえず、FFTWは非常に優秀ですね。
にしても、久々にC++で組むとほんとケアレスミス連発しちゃいますね・・・。今回やっちまったミスのうち9割がバッファオーバーフローなどのメモリの扱い。C#と違って配列のインデックスをオーバーしてもC++はなんも言いませんからねぇ・・・。おかげで踏み越えるわ踏み越えるわで大変でした。書き換えなんて起こらないはずの関数を抜けたら変数のアドレスが訳分からん数字に書き換えられてるとかほんと悪夢だった。まぁ、アドレスが書き換わっていたために100%バッファオーバーフローの類だろうなと気付けただけマシなバグですが。今もまだプログラムが完全には動いていないので、どっかにメモリ周りのバグが潜んでいそうで怖い。しっかと潰して行かなくては。
今回一番やらかしたのはmemset関数とmemcpy関数の扱い。両方とも引数にバッファサイズを要求してくるのですが、処理したいバッファのバイト数を与えなくてはいけないので、配列長*単位サイズを計算しないと行けないんですね。が、ついつい配列長だけを渡してしまってコピーや値の設定が正しく行われず、結果が狂うと言うことが多々ありました。sizeof関数とかC#ではほとんど使わないからなぁ・・・。まぁそもそもmemsetとmemcpyに該当するモノが無かった気がするけど＾＾；
ここまでミスするんならいっそのことmemcpyとmemsetはラッパークラス作った方がいいんじゃないかという気がしてきた。C++って変数の型情報取得とかできたっけなぁ・・・？できたとして、それをsizeofの引数に渡せるのかしら？
まーそれよかsizeofの癖を付けた方がマシか＾＾；
さらに、FFTWの扱いも失敗してた。
forwardFFT = fftw_plan_dft_r2c_1d(length, doubleArray, complexArray, flags);
backwardFFT = fftw_plan_dft_c2r_1d(length, complexArray, doubleArray, flags);
といった形で1次元DFTと1次元IDFTのプランを生成し、それぞれのメソッドを持たせたFFTクラスを作った訳なんですが（超単純なラッパークラス）、このときマニュアルをちゃんと読んでなくてですね、実数配列のサイズと複素数配列のサイズの扱いの違いを理解していなかったんです＾＾；
実数配列をDFTすれば、その結果は複素数となります。が、その複素数の配列は実際にはちょうど真ん中から折り返すような値の配置になります。つまるところ、実数配列のサイズがNのDFTを行うと、本来ならNサイズの複素配列を必要とするところをN/2+1で表現可能というわけです（Nは整数であり、割り算は切り捨てです）。
また、逆にそういった真ん中から折り返したような複素配列をIDFTすると実数だけの結果が得られます。
FFTWのサンプルの多くは通常のDFT/IDFTを紹介しており、入出力のバッファには複素配列を与えています。が、私は今回、DFTは実数を入力とし、IDFTはエルミートな複素配列を入力とすることを前提としていたので先のプランを用意したわけです。
でそこまではよかったのですが、うっかり複素配列もサイズNで確保しちゃってたんですよね。別にバグは起きませんし、用意されていたとしても使われないのですが、せっかくメモリを節約できるのに勿体ないですよね。マニュアルを読み直して良かったよほんと。
ただ、そこで複素配列のサイズをN/2+1に変更したため、DFT後に一時バッファから出力バッファへコピーしたり、あるいはIDFTの前に入力バッファを一時バッファにコピーしたりという作業でコピーする領域のサイズをNのままにしており、ここでも見事メモリ領域を破壊してました；；
まったく、焦ってコトはやるもんじゃないですね・・・。
とまぁそんなこんなでツマラナイミスに苛まれつつ、なんとか動きかけのところまで持ってきました。残すところもうあとわずか。ほんとだと8月中に片付けたかったんですが、間に合わず。デッドラインは9月末ですが、できるだけ早く片付けたいところ。この土日で片付けたいな。
ところでVC++のデバッガの使い方ってどうやったら勉強できるんかなぁ？　もっと使いこなせたらきっと便利やと思うんやけど・・・。表面的な機能しか使えてないし、もうちょっとどうにかしたいところ。
特にnewで確保した配列をウォッチリストで手軽に監視する方法ないだろうか・・・？　確かにC/C++の仕様から言って配列とポインタにほぼ差がないから表示しにくいってのは分かるけど、何か方法ないもんかなぁ？
デバッガとにらめっこしてた、そんな今日1日でした（苦笑