• 管理者用

  • Twitter

    • @_ks マイクオンの方たちはむしろ、「うるせーこら切れよ!」っていわれたらええねん(過激派 やっぱり資料投影しますよねぇ? アイスブレイクのためとかかなー。 マイクオンもそうですが、たしかに相手のリアクションがわからなくて不安になる、ってことはありますね 1 hour ago
    • @2_5_dimension @_ks Teamsにはあったような… オンライン講義とかを想定した機能だったかなと 1 hour ago
    • @2_5_dimension @_ks そうそう、相手をミュートね(開催者権限 12 hours ago
    • @_ks 話してないときには環境ノイズ入れたくないから切りますねぇ テレワークだと窓開けてるんで、車とか飛行機の音が入っちゃうんですよねぇ。 カメラオン派が多いんですか!そうなんやなぁ…。 自分の周りではほぼないっすね! 12 hours ago
    • @_ks マイクのオンオフですか? どんなルールでしょう…? うちは帯域つらいからカメラは原則Off、くらいかなー マイクの方は話すとき以外オフが暗黙のルールですね 12 hours ago

Googleほんっとすげぇな・・・

Google Notebook日本語版公開、Webサイトをブラウザ上で瞬速コピペ

いやほんと、ブラウザの持つ機能がどんどん広がっちゃいますねぇ・・・。リンク、画像も含めてさくっとコピペだなんて・・・。ワードパッドで試してみましたが出来ませんでしたw Wordならできるのかな? けど、仮に出来たとしても、Wordをそのためだけに立ち上げるのも重たいわけで・・・。ブラウザの拡張として利用できるのはすごいなぁともう感嘆の念しか出てきません。
Firefoxの拡張やIEの拡張にもウェブページをクリップするものがありますが、それをネットワーク上で共有までは出来ませんからねぇ・・・。いやまぁローカルに保存したければそちらを使うという感じで使い分ければいい話ですが。
また嬉しいことに、Googleがこうやってツールを提供してくれる場合、基本的にIEとFirefoxに対応してくれるんですよねー。Firefox派の私にとっては嬉しい限り。
ローカルで実行するアプリケーションについても、大概Linux用も用意してくれますし。ないものといえばGoogleパックだっけ、あの無料ソフトをパックにしたツールくらいですね。まぁLinuxの場合、多くのディストリビューションがアプリケーション管理ツールを用意していますから、あまりそういったツールが必要になることもない、ということなのかも知れません(笑)
いやー、Ajaxは繋ぎの技術で、それほど広がりはしないだろうな〜と思っていたんですが、Googleさんはアッと驚くツールを提供してくれますねぇ。JavaScriptがここに来て凄く興味のある言語になってきましたよ?w まぁそれよりもXMLの扱いに慣れないとなぁ・・・。Ajax以外にも色々なところで使われ始めたし、.NET3.0ではWPFがXMLをベースとした言語でUIを表現するし。
まぁタグはTeXで慣れてるし、なんとかなるかしら。特にプログラムの方だとあまりDTD宣言について気にしなくていいしw とりあえず、今作ってるツールの設定ファイルをXMLで管理してみましょうかねぇ?

Office2007インストール成功

以前の記事で、Office2007のインストール途中にフリーズ、そしてインストール不能状態に陥ったと書きましたが、なんとか今日インストールに成功しました!
インストールに失敗したものの、ちょっと悔しかったので頑張ってみたんですね。ログファイルをあさり、その情報を基にぐぐるぐぐる。
で、レジストリキーを削除したりインストーラが参照する設定ファイルを書き換えてみたりいろいろとやってみた結果、どうも
c:\Document and Settings\All Users\Application Data\Microsoft Help
だったかな?ここにあるファイルが邪魔をしているからそれを削除してインストール作業をやり直せば大丈夫だという記事を見つけたんですね。まぁそれはVisual Studio2005か何かのインストール失敗の際の対策だったようですが(英語だったので必要な部分しか読んでません^^;)。
で、残念ながら該当するファイルはなかったのですが、どうせならやってみろということでMicrosoft Helpってディレクトリをリネームしてインストールを実行してみたんですね。
そしたらなんと! うまくいっちゃいました^^
今回は万が一のことも考え、MS IME2007はインストールしないようにしておきました。おかげで(?)無事インストール完了! Office2003と共存しちゃってますがまぁいいでしょう。
ただ、相変わらずWindows Updateは手動でやろうとすると失敗します。定期アップデートで自動実行される更新に関しては問題なく実行されるようなので、まぁ気にしないこととします(ぁ 手動でやることはほぼないでしょうし。
と、いうことで今日はこの解決に随分と時間を喰っちゃいました。
明日はプログラムの方をもっと進めよう・・・^^;

例外処理が甘いけど、一応解決

昨日の記事にて、メニュー項目とインスタンスをどうやって結びつけようかと思案していたのですが、1つの解決策を得ました。
どうもFormクラスをはじめとしたControl全般は、Tagというプロパティを持っており、そこにそのコントロールと関連性の高いオブジェクトを放り込むようです。Tagはobjectクラスとなっているため、なんでも保持できます。一般的には文字列を入れておき、イベント先でswitchなどを駆使して処理を行うらしいです(この考え方で合ってるのかな?)。
で、私はメニューリストのTagプロパティに、インスタンスの参照をそのまま放り込んでみました。イベントハンドラに登録されているメソッドでは、senderとなるオブジェクトを決め打ちとし、Form型にキャストして処理しています。本来、インスタンスの参照をあまり複数で管理すべきではないということは承知しているのですが・・・、こうしておくと初期化処理の部分でTagプロパティに参照を渡すだけでよく、楽なんですよねぇ・・・。
まぁ処理の都合上子フォームのTagプロパティには親フォームのメニューリストの参照を渡していたり。そうしないとメニューリストに項目を追加するたび、子フォームごとにイベント処理を書かなくてはいけないので邪魔くさいんですよね・・・。
まぁTagはおいといて、受け取ったイベントメソッド側でobjectクラスからFormクラスへキャストしているので、万が一イベントを送ってきたインスタンスがこちらの装丁しているクラスでなかったとしたらあっけなく例外を吐きます^^; まぁ自分で管理している以上そんな処理は有り得ないのですが・・・、お行儀がいいとはとても言えませんね(苦笑)
これに関しては、VC#のコードデザイナのイベントメソッド自動生成に任せているからobject型になっているのであって、これを自分でメソッド書いてイベントハンドラに追加してやれば好きに出来るはず・・・と思っていたり。ちょっとまだイベントハンドラについては理解し切れていない部分があるので間違ってるかも知れないけど、おそらくそれで解決できるはず。
Formクラス以外はそのイベントメソッドを利用することを想定してないから、メソッドの引数自体をそうしてしまえばコンパイルの時点で明らかにおかしいものは弾けるしね。
ということでお行儀のいいソースにするためにそこは修正予定。ただ、自動生成しちゃったイベント登録部分ってのはpartialで隠されてる部分だからあんまり手動で消したくないのよねぇ・・・。リファクタで消えたっけ・・・? それがネックだなぁ。
まぁ最悪手動で消すとして、これである程度保守性も確保できたかな。
こっから先はいよいよ実行処理のアルゴリズム実装かな。Timerによるサンプリングレート管理とデータのバインディング処理がネックになるかな・・・。とりあえずは実装モデルを考えないと!

どうするのがスマートなのかなぁ・・・

とりあえずグラフを描画するWindows Formのサブクラスが完成。コンストラクタにしかタイトルや軸のラベル名を変更させる手段を持たせなかったけど、途中で変更することはまず内だろうしそれは別に問題ないかな。汎用性を持たせるならプロパティでも設定すべきなんだろうけど・・・、まぁいいかな。グラフを描画させたいデータソースによってタイトルと軸のラベルなんて決まるもんだし。それはインスタンスを生成する時点で決まってるでしょう、きっと。
とりあえずある程度の汎用性を持たせたグラフ描画フォームは完成と言っていいかな。データソースにはdouble型の配列を引数として受け取るようにはしましたが・・・、あれはどうにか抽象化できんかなぁ。ジェネリクスメソッドにしてもいいんだけれど、確実に型制限をつける必要が出てくるし。値型だけを引数としたいところだけれど、それってできたっけなぁ・・・? まぁよしんばそれができたとして、ArrayListクラスとかは受け取れないけどそれはどーすんだとか諸々の問題はありますが^^;
まぁそれはそこまで大きな問題ではないのですが、今気になっているのはMDIの扱い。描画フォームができたので、それをMDIの子フォームとして呼び出すランチャーを作っているのですが、これをもう少しスマートに書きたいんですよね。
とりあえず、メニューの”Results”をクリックすると、プルダウンメニューが現れ、MDIの子フォームであるいくつかのグラフ描画フォームを選ぶことでMDI領域にフォームが現れるという仕様にしています。この部分は問題なく実装できているのですが、実に泥臭い方法で実現してるんですよね・・・。
それぞれのメニューの項目のクリックイベントのハンドラとしてそれぞれのウィンドウの表示メソッドを書いて居るんです。
が、基本的にやることはみんな同じ。対象となるフォームインスタンスが違うだけ。なので、メニュー内容とそのウィンドウをなんとかリンクさせることが出来れば、同じイベントハンドラで実現できるはず、と思ってはいるのですが・・・、その方法が思い付かないんですよねぇ。
親フォームがロードされた時点で全子フォームのインスタンスは生成されているので、メニューのクラスに関連づけさせるようなプロパティでもあればいいんですが・・・、ない気がしますしねぇ^^;
ってなると自分で実装・・・はしんどいよなぁ^^; けど毎回毎回子フォームを追加してメニューに追加したときに同じようなコードを書かなくちゃ行けないのは明らかに保守性が悪いし・・・。
どうにかしたらできるはず。ってなわけで当面はここをどうにかする方法を考えつつ、プログラムの実行部分を作っていきましょうかね。別スレッドで回すのはいいんだけれど、内部で使われている値を読み出すときはどうやって読み出そうかなぁ・・・。原則、リードオンリーだからロックを掛ける必要はないと思ってはいるのだけれど・・・、WAVファイルからサンプリングレートを取得してそのレートで実行するようなプログラムを書きたいな。そうすれば実際に処理にどれだけ時間が掛かったかが把握できるし。
できたら処理実行クラスはGUIとは完全に切り離して、単体でも動作するような形にしたいからなぁ。あくまでGUI部分はただのランチャってのが理想。アルゴリズムの実装はさして難しくはないけれど、GUIとの連携部分をどうするか、やなぁ・・・。
このあたり、今までまともに組んだことがないからちょいときついなぁ。さて、またネットとかで情報集めて頑張りますかねぇ^^

同期の飲み会

昨日はイベント目白押しの日だったんですなぁ。夕方からは飲み会でした。
謝恩会は15時くらいには終わってしまったので、それから飲み会まで結構時間あったんですね。とはいっても大学に戻ったら逆にすぐ駅前にとんぼ返り。割と中途半端な時間残っちゃったんですよねぇ^^;
とりあえず、一緒に謝恩会に顔を出していたwillたんと駅前を適当に散策することに。ほんとうにあてもなくいろんなお店を冷やかしてました(笑) おかげで結構歩き回ったので、いい運動にはなったかも知れない。
で、適当な時間になったのでお店に行きまして、みんな集まってから(幹事のはずのかちゃーんは電車の遅れのせいで遅刻)飲み会スタート! なんか私は裏幹事みたいになってしまってました(苦笑) まぁ始まっちゃえばどうでもいいことなんですがw
まー、こうして同期で集まって呑むのは2回目。なかなかよいものですね。nikuがインフルエンザのため出席できなかったのが悔やまれますが、電話で参戦。次こそは全員揃うといいな。
飲み会の内容はまぁ語るほどの内容ではないので端折っちゃいますが、とりあえず楽しかったです^^ 一部楽しみきれなかった人も居たようですが(ぁ
あ〜、またこういう飲み会が出来たらいいなぁ^^

ご卒業おめでとうございます

と、いうことで、昨日はうちの大学の謝恩会でした。
私は卒業するわけではないので本来関係ないのですが、卒業してしまう面々と会えるのもそうそうないだろうからということでひょっこり顔を出してきました^^
まぁ最初から行くつもりならスーツで行ってたのですが、午前中は学校におり、willたんに誘われて行く気になったのでもろ私服だったんですね^^; 完全に浮いちゃってました(苦笑
入っちゃまずそうな雰囲気ならやめとこうと思ったのですが、まぁ特に問題にはならなそうだったので助かりましたね。最初の一歩を踏み出す勇気は推して知るべしw
まずは見知った先輩に「おめでとうございます」と挨拶。皆さん快く迎えてくださいました^^ で、お酒も勧めてくださいましたw 私は会費を払っていないので全力でお断りしましたが^^; できたら呑みたかったんですがねぇ、そういうわけにもいかなくて残念です;;
で、続いてうちの講座のB4に挨拶。こちらも快く迎えてくれました。感謝感謝^^
で、あとはふらふら、ふらふらとあたりをうろついてました。どうしても若干浮くのは仕方ないよね^^;
で、最後は花束贈呈。はましんさんからカメラを託されまして、写真を撮ってたのですが、あまりいい絵は取れませんでしたねぇ^^; というかずいぶんと段取りがgdgdだった・・・。もちっと段取りは決めておいた方がいいと思うんだ、うん。
で、その後はうちの講座の集合写真。ここぞとばかりにカメラを受け取って写真撮ってました。ちょっとはお役に立てたかな?
M2の方々、ほんとうにお世話になりました。修士に上がってくるB4、来年度もよろしく。卒業するB4、ご苦労様でした。
うん、やっぱ行って正解だったな^^

[mixi] 6200人目達成〜

mixiからのお知らせです。code_air_ edge さんのページ全体のアクセス数が 6200アクセスを超えました。記念すべき6200アクセス目の訪問者は Picture@人形師 さんでした!

と、言うことで恒例の前後賞。

2007年03月25日 02:11 さんのへ
2007年03月25日 02:07 だーs
2007年03月24日 22:49 Picture@人形師
2007年03月24日 22:18 角
2007年03月24日 21:26 う゛ぇるにゃー 

ふむ、日記をこちらに書くようになったから、別にmixi経由でなくてもRSSで更新は取得できるんですよね。そのためか、足跡はだいぶ進みが遅くなってます^^;
まぁmixiの方を更新していることはほとんどありませんから、直接こちらを見ていただいたらそれでいいかな。こちらは足跡を管理なんか出来ないので訪問者はさっぱり分かりませんが^^;
あ、けど私は読み逃げはアリだと思ってますので^^
んなもん読んでコメントを残さないなんてのは読んだ側の自由だろうがっ!
「あなたここ見ましたね? 見たんならコメントを残してください。そうしないとほら、失礼でしょ?」
なんて、どっちが失礼だよと。感想を強要する日記なんてほんと勘弁してくれ。
私の周りにそう言う人がいなくてホンと良かった。
あ、でもコメントは貰えると嬉しいです^^
さて、お次は6300。気長にいきますかね〜。

なんてこった!

私の使っているディスプレイは今ではもう標準となっているSXGA(1280×1024)のサイズです。が、これ5:4なんですな。大抵のゲームはVGA(640×480)サイズないしXGA(1024×768)サイズ。比率は4:3なんですねぇ。
ウィンドウモードでゲームしてたら関係ないですが、問題はフルスクリーンモードにしたとき。基本的には引き延ばされます。横に!だったら比率が4:3になるように黒帯でも入れてくれたらいいのにとか思いますが、そんな機能の付いたディスプレイはお高いんですね。
で、私も長いことそんなこと気にもせずに使っていたのですが、なんとGeForce系のグラボならグラボオプションでアスペクト比固定にして表示が出来るらしいじゃないですか!
早速調べてみて、ドライバを新しいのにしたらできるってことで最新版をDLしてLet’s Challenge!
しようとしたら、なんとフリーズ!!!いや〜驚きましたねぇ。
再現率100%!
どういうこっちゃねんOrz
ってなわけで原因は不明ですが設定は出来ていません;; せっかくの機能なのになぁ・・・。
なんかお預け喰らったみたいだ(苦笑) まぁこれといった実害があるわけでもないから気にしなくていいか・・・?

循環バッファ作成

最近備忘録的なポストばっかだな・・・。
まぁそれだけ研究してるってことですよ。実戦向きかどうかは別として(ぁ
今日は循環バッファを作ってました。C言語版。DSPに搭載するならC言語だし。全力で循環バッファ使うならアセンブラなんだけど^^; DSPアセンブラは追々勉強していこう。せっかく手元にDSPあるんだし、あいつは弄くり倒したい。浮動小数点演算可能ではあるけれど、あえて固定小数で勝負したい。ん〜でもFFTとかのライブラリは全部浮動小数だったな・・・。PCでのシミュレーションなら固定小数と浮動小数に実はそこまで(クリティカルな)差は出ないから無理して使う必要もないけど、DSPでは実クロックは遅いからなぁ。その代わり並列処理が半端じゃないが。
だから余計にC言語じゃその真価を引き出せないからアセンブラ勉強する必要があるんだよなっと。勉強しとけば就職には強そうだ。就活に間に合いそうはないが^^; 話のネタに位はなるだろ、うん。
っと、話は逸れたけれど循環バッファ。信号処理では現時点からnサンプル前までのデータ列に対してどーのこーのという処理が多く、配列に対してのランダムアクセスという物はほとんど発生しない。データアクセスはシーケンシャルだし、データの追加、削除というものも先頭と末尾に集中。サンプル長も固定と結構狭い条件で動作します。要は汎用性は気にしなくていいから最適化を掛けやすいという環境といえますかね。
まー大抵実装するときは、nサンプル保存する配列を用意し、サンプルを追加するときはfor文かなんかで値を右ないし左の配列要素にコピーして次のサンプルを配列に書き込むってスタイル。まーシフトレジスタをイメージしたらまさにその通りだし、見やすさも抜群だけれど如何せん無駄が多い。けどシミュレーションではリアルタイム性を考慮してないからこんなコード平気で書いちゃうんだよなぁ・・・。これはすっごくよろしくない。値を1つ捨てて1つ入力するという作業だから大半の値は使い回し。にも関わらずn-1個の値をコピーするからそれだけ無駄に時間を食っちゃう。
で、そんなことするくらいなら捨てる予定だった値のところに新しい値を放り込んでやればいい。つまり、配列が輪になっているとイメージし、末尾まで来たら次は先頭にまた戻る。これが循環バッファ。概念は凄く簡単。アクセス時には先頭をどこにするかという下駄を履かせてやればいい。
配列長が4で、下駄(オフセット)が0ならば通常の配列のアクセスと同じ。この状態で右に要素をシフトしたとイメージする。配列の末尾の値が捨てられ、先頭に空きが出来たというイメージだ。これを下駄だけで表現しようと思ったら、先頭へのアクセスが実際には末尾を指していればよい。配列のある要素を指定した際、下駄を履かせた値が配列の要素数を超えた場合はその合計値から配列の要素数を引いた値が指したい位置になる。例えば、1度右にシフトされ、下駄が配列の末尾を指している(C言語に倣うとオフセット値は3)状態で、3番目の要素にアクセスしたい(C言語では指定する値は2)ときにどうするか。オフセットを合わせた値は3+2=5で要素数を超えている。よって5-4=1番目が本来3番目に用意されていた値、ということになる。
つまり、配列へのアクセス時に毎度毎度要素数を超えていないかのチェックをしなくてはならないと言うことになる。コレはたいそう無駄が多い。コピーは時間が掛かるといって循環バッファにしたのに、アクセスのたびにリミットチェックの条件分岐をしないといけないとなるとパイプラインが生成されず実行効率が悪い。実際そんなコードを書いたらコピーするのと大して処理時間が変わらない。
つまり条件分岐をしなければよいということになる。実はそれは簡単。剰余計算を使えばいい。指したい要素番号とオフセットの合計値を要素数で割ったときの余りが実際に指し示す要素番号となるのだ。例えばさっきの例で言えば、オフセットは3、指定する要素番号は2、要素数は4なので
(3+2)%4=1 (%はCでは剰余を返す演算子)
となる。見事同じ値を返す。アクセスの際にこうして剰余計算を行わせることで条件分岐を行う必要が無くなる。コンパイラによる最適化も掛かりやすくなると言うことなんですな。
が!これでもまだ問題が。剰余計算は基本演算の中ではすこぶる遅い!!! 除算がただでさえ遅いのにさらに余りを返さなくてはいけないと言うことで非常に時間コストがかかるんですな。if分岐に比べればマシですがやっぱり時間が掛かる。
そこでさらなる工夫。配列のサイズを2の冪乗にするという条件はつきますが、剰余計算がビット演算で可能になります。今回の例では配列サイズが4で、見事2の冪乗なので早速やってみましょう。指し示す要素番号とオフセットは同じとしますと
(3+2) & (4-1) = 1 (&はCではビット毎にANDを返す演算子)
となります。AND演算はマスクを掛けるだけなので非常に高速です。これで相当早くなります。信号処理ではFFTの都合などで配列サイズが2の冪乗に揃えられていることが多いですから非常に良く用いられる手法です。
私もこの手法を知ったときには「は〜よく出来てるなぁ・・・」と感心しましたねぇ。C/C++ではどうしても関数を作ってそれを通して配列を操作しなくてはいけないため見た目にちょっと野暮ったい印象がありますが、C#ではプロパティのおかげで見た目に配列と全く同じアクセス方法が使えます。これはかなり嬉しいですね。なんせ、コードの書き換えが配列の型を書き換えるだけで済みますからw ん、C++でも[]演算子をオーバーロードしたら同じコトできたっけ・・・? いやでけんか。
まぁ下駄を履かせる方法とかちょっと混乱しそうになりますが、一度作ってしまえば後はそれを使い回すだけですしね。使う側はアクセスしたい要素番号を関数に飲ませればいいだけですし。
つーことで講座の共有にでもおいとくか。ドキュメントまでつけなくても大体分かるだろう・・・つか分かってw

DSPってのは奥が深いな・・・

なんか色々と勘違いしていたことが発覚。畳み込みはあくまで小数同士の積和だから、ゆーても整数部の桁はほとんどいらないんだよな・・・。そんでもって符号付き16bit同士の積だと必要な桁数は31bitだとか。まー符号付きの16bitだと、実際に数値を表現しているのは15bitだから、15bit同士の積を考えればいいはず。必要な桁数は30bit、そんでもって符号ビットの1bitを加えれば31bitになるって計算でいいのかな?けど、DSPでは実際には小数部は30bitしか扱わないんだとか。なんでだ・・・?
最上位ビットを符号部、次のビットを小数第1位として4bit同士の積を考えてみる。
例えば、
0.111 = 0.875
0.010 = 0.25
の積を考えたら、最上位ビットを無視すると
       .111
x      .010
-----------
          0
      1.11
+    00.0
----------–
     01.110
これを3bit右シフトした0.001110 = 0.21875ってのが計算結果になる。あとは符号ビットを加えるだけ。小数同士の積では結果は必ず1以下となるから、途中結果はどうあれ最終結果は下位ビット側に乗数の小数部桁数分伸びる(今回は3bit)。小数点の位置が同じ固定小数同士を掛けるなら倍の桁数を用意しておけばその精度同士の積が誤差なしで得られることになる。ただし、途中結果は上位側に結果が伸びるため、そちらがオーバーフローする可能性がある。今回の例でも、右シフトする前の結果は整数部に値が入ってしまっている。これだと右シフトした際に正しい結果が得られない。
ただ、予め小数部に十分な桁数を用意できているとするならば、先にビットシフトをしておいてから演算を実行すれば上位ビットへのオーバーフローは防げる。つまり、
       .000111
x      .010
----------—-
             0
      0.00111
+     0.0000
----------—-
      0.001110
とすることで同じ結果が得られる。これなら上位にビットが溢れることはない(はず?)。例えば
0111 = 0.875
0111 = 0.875 の積を考えると、
       0111000
x      0111000
----------—-
     0111000000
   0111000000
+ 0111
000000
----------—-
  110001000000

となり、3bit右シフトすると0.110001000=0.765625となります。予め3bitずつ右シフトしておいたとすると、
      01110000
x     00001110
----------—-
       1110000
      1110000
+    111000
0
----------—-
   01100010000

となり、0.110001000となるため同じ結果が得られます。どちらの方法をとったにせよ、下位3ビットは確実に0となるため、本来符号bitを除けば7bit確保できるけれど6bitで十分と言うことになります。これを単純に32bitに置き換えて考えると、なるほど確かに小数部は30bitで事足りるという結論が導けてしまう・・・。ほんっと、昔の人は賢いよな・・・。
ところで、実はこれでもまだ具合が悪い。整数と見立てて考えると分かりますが、符号bitを含めて4bit同士の積を考えていますから、その結果は明らかにオーバーフローしています。これは具合が悪い。ならば今度は両方を3bit右シフトしておき、結果を3bit左シフトすることを考えます。
       00001110
x      00001110
---------------
       00001110
       0001110
+      001110

---------------
       01100010

これでオーバーフローの心配がなくなるはずです。というより、溢れた桁の分は捨て置くのでこれで4bit同士の固定小数の演算結果が得られていることになります。取り出すときにはこれの上位4bitを取得すればよいことになります。つまりは0.75となるわけですね。まぁ取り出すときだけ丸め処理を入れればいいと言うことだけ押さえておけば十分でしょう。
が、これは積の場合で、除算はまた
った結果を生むんですよね・・・。被除数の絶対値が除数の絶対値よりも大きければ絶対値が1以下に収まりますから問題になりませんが、そうでない場合、絶対値が1を超えるのでオーバーフローを起こす羽目に。
ん〜、今度実装するアルゴリズムは学習同定法がベースだし、どう考えたって絶対値は1超えてくるんだよな・・・。DSPで学習同定法を実装するときってどうやってんだろ・・・? まっさか浮動小数ではないだろうしなぁ・・・。FFTは絶対値を1以下に抑える方法がちゃんとあるからいいけれど、逆フィルタの生成とかだと除算が入ってくるだろうし・・・。調べてみるか。
ふぅむ、実用レベルまで持って行くのはかなりしんどそうだな・・・^^;