平成19年9月26日(水曜日)
☆最近の査収物
|
． ． |
☆今日
|
．時津風親方を立件へ 力士急死巡り傷害容疑 - 朝青龍騒動のどさくさに紛れてウヤムヤにする、ということはできなかった模様。 ．地域の自立・再生と地球環境を守るためのOSS活用提案 - 蟹自重。 ．__super - 便利そうだが、多重継承可能な C++ ではちとややこしい気もする。コンストラクタでも使えるといいのに。 |
|
．死刑執行は「自動的に」鳩山法相が退任会見で見直し提案 - 余計なこと言わなきゃ良いのに。また言葉じりに嘴容れるアホが出て、本当に大切なところは議論もされずに終わるんだろうなあ。 ．言ってることは、賛成するかどうかはともかくとしてさもありなん。筋論として、いったん司法が決めたことを、行政が恣意的にどうにかするのは好ましくない。あのサインは単に司法から行政への引き継ぎ手続きに過ぎないもので、ここには冤罪防止の非常ブレーキとしての役割は、本来は与えられていない。 ．ここであえて筋を外れた話をすれば、まあそういう緊急避難的な非常ブレーキとしてこの制度を使うことはある程度構わないと思うし、そのために「自動的でない」現在の方法を残すというのも一つの方法ではある。しかしながら、それはあくまでも緊急避難であるという明確な認識が必要であるし、それができていなければ、制度の濫用ということになる。 ．死刑執行命令書にサインした法相に抗議文を送る手合いがいるけれど、これは上で述べたような意味で勘違いも甚だしいと思う。行政が非常ブレーキを常用するのは大きな禍の元なのだがなあ。そういう大局観が欠如してるのかしら。 ．むしろ、行政の手続きをそういう風に政治的に利用しようとするアホがいるから、かえって「自動的に」ということになってしまう。こうやって、「柔軟な制度の運用」ということがやりにくくなって、どんどん社会が硬直化してゆく。そんなことをしている暇があったら、本筋である刑罰制度の見直しに全力をそそげばいいのに。馬鹿馬鹿しいことだ。 ．ちなみに、私の個人的な意見としては、そもそも日本の法制度には、最初からこういう場合の非常ブレーキとして恩赦という制度があるので、その審議のための執行延期さえ緊急避難的にできれば十分だと思う(そういうことは、現行制度でも命令書へのサインという段階よりも前に行われている)。死刑制度そのものの賛否についてはあえて明言を避ける。 |
|
． ． |
|
．時津風親方を立件へ 力士急死巡り傷害容疑 - 朝青龍騒動のどさくさに紛れてウヤムヤにする、ということはできなかった模様。 ．地域の自立・再生と地球環境を守るためのOSS活用提案 - 蟹自重。 ．__super - 便利そうだが、多重継承可能な C++ ではちとややこしい気もする。コンストラクタでも使えるといいのに。 |
|
．昔のユニマガで一ページも原稿を書いたことがないというのは、自分の人生を振り返ったときの小さな後悔の一つである。なぜなら、 ．というわけで (1) _Bool b = true; b += -1; (2) _Bool b = false; b -= -1; (3) _Bool b = true; b += UINT_MAX;の結果はそれぞれ果たしていくつになるべきでせうか(答え: 全部実装依存)。 ．そもそも _Bool に対して算術演算をするのは、規格上は許されていてもあまり賢くないし、あるいは頻度が低いので、上のようなことで頭を痛めるより、いっそ最適化をうっちゃって整数の変換ルールを愚直に実装するのがいいような気もする。あと、これを警告するオプションは欲しいやね。 ．isspace パッチ - とりあえずそれで良いと思います。ただ、ロジックの変更(wctob に関係するところ)とコスメティックな変更は分けてコミットしたほうがいいかもしれませんな。 |
|
．いつのまにか金曜。 ．あたらしいノート PC 欲しいなぁ。 ．今までどおり NetBSD メインの生き方をするなら工人舎の A110 な奴でもいいような気もするが(すんなり NetBSD が動くかどうかは知らない)、そろそろ Windows + VMWare な生き方に変えたいような気もする。 ．あまりでかくない奴の中から選ぶとすれば、パワーなら ThinkPad X61 、サイズなら Lets R7 かのう。 X61 なら VisualStudio IDE もちゃんと動きそうだが、やっぱり重くて電池がもたんな。 R7 なら軽くて電池は持ちそうだが、ちと非力な印象はあるな。このあたりの兼ね合いが難しい。値段は X61 の方がおおむね安いな。 |
|
．データの更新、特に無効化というのは扱いが難しい。 ．たとえば、データリストの一部分を複数のビューワから参照したり追加削除変更したりできるようにすることを考えてみる。それぞれのビューワインスタンスは、現在表示しているデータの範囲を覚えておかなければならない。データが配列(のようにランダムアクセス可能な構造)ならば、この範囲は添字の形で覚えておけばよいのだが、挿入や削除を容易にするために、データが双方向リストで管理されているとすると、少々面倒なことになる。 ．処理の効率を考えなければ、配列と同様に、「先頭から数えて n 番目から m 番目までを表示中」というふうに記録しておいて、表示するたびにシークするという方法が考えられる。けれど、これはシークに時間がかかるので、あまり頻繁にはやりたくない。 ．代わりに、データの範囲を両端のノードのポインタ(STL の用語で言うならイテレータ)で覚えておくという方法もある。この方法は一度シークした後は再度シークする必要がなくなるものの、両端のノードの一方または両方が削除されてしまうと再シークが必要になる(たとえば STL の list クラスのイテレータの寿命は「リストが変更されるまで」となっている)。問題の焦点は、これをいかにして検出するか、というところにある。それが適切に行われないと、無効なポインタを参照することになって難解なバグの原因になる。 ．解決方法は大まかに二つある。つまり、削除前に通知するか、削除したという印を付ける。 ．まず通知については、データを参照しているビューワに紐付けしておいて、ノードが削除される直前に、その紐にぶら下がっている全てのビューワへと通知を送る。この紐の先をデータリストに結ぶか各ノードに結ぶかというような違いによってコストが変わってくるが、大差はない。通知されたビューワは、自分が参照しているノードが無効化される可能性に備えて何かしら準備をしておく。 ．印を付ける方法にもデータリスト全体に印を付ける方法とノードごとに印をつける方法があるが、こちらは大差ないというわけにもいかない。後者は多少やっかいで、ノードを削除しようとしているのだからノードそのものに印を付けてもそれが失われてしまえば意味がない。だから、削除を遅延する必要がある。たとえば、いわゆるウィークリファレンスという概念を使えばこれが可能になる。ノードをリストから削除するときに、ウィークリファレンスが 0 でなければ実際には削除せず、単に無効のマークを付けておき、以後、通常のリスト操作では無効なノードは見えないようにしてしまう。一方、ビューワのほうでは、自分の参照しているノードを見て、これが無効であると知ったら可及的速やかにこの状態を解消する。最後に参照をやめた人がこのノードを最終的に削除する。 ．ここまでの方法は、いろんなモジュールが密接に関係するので、多少ややこしい。ややこしいかわりに、いろいろ賢い最適化を行える余地はあるものの、プログラマは一般的に、あまりややこしいデータ構造を管理したいとは思わない。一方、データ全体に印を付ける方法ならばずっと簡単に実現できる。良く使われるものとしてシリアルナンバーという方法がある。これはジェネレーションナンバーとか言う人もいる。 ．データリストには、シリアルナンバーのための整数値フィールドを一つくっつけておく。データリストを参照したビューワは、そのときのシリアルナンバーを覚えておく。データリストを更新する人は、更新した後にシリアルナンバーを一つ増やす。ビューワがデータを再表示したいと欲した時、自分の覚えているシリアルナンバーと、データリストのそれとを比較して、異なればデータが変更されていることを検出したということになる。 ．この方法の利点は、仕組みそのものの実現に必要なコストがえらく低いことにある。やることといえば、整数値のインクリメントと比較だけだ。また、各モジュールは密接に関連していないため、こんがらがったスパゲッティをほどくような面倒な作業に巻き込まれる危険も少ない。一方で、仕組みが単純過ぎるので、ビューワから分かることといえばせいぜい「変更された」ということしかないし、したがって最適化の余地もあまりない。また、シリアルナンバーの更新を忘れたりすると難解なバグの原因になる可能性がある。 ．この方法にはもう一つ、完璧ではないという問題がある。つまり、シリアルナンバーには一般的に有限ビット数の整数値が使われるので、オーバーフローする可能性がある。オーバーフロー自体はさほど問題ではないのだが、ビューワーの誰かが大昔に取得して更新されないままになっている古いシリアルナンバーと、オーバーフロー後の新しいシリアルナンバーがたまたま一致してしまったりすると、誤動作の原因になる。これを衝突(コリジョン)なんて呼んだりする。 ．多くの場合、このような衝突は滅多におこらないので無視できる。しかしながら、そのためのリスク評価は必要だろう。そしてたとえば、頻繁にシリアルナンバーが更新されるようなら、普通の 32 ビット整数ではなく 64 ビット整数を使う、とかする必要がある。あるいは、もし、自分ちの原子炉の 128 本ある制御棒を操作するためのプログラムを書いているのならば、もっと堅牢な方法を使うべきだろう。いずれにしても、この方法を使ったならば、オーバーフローの可能性について備忘録に残しておいた方がいいかもしれない。 ．そういう危険があるものの、この方法は簡単な割に便利だから、いろんなものに使われている。たとえば DNS のシリアルナンバーとか X サーバのグラフィックコンテキストの実装とか。しかし、あまりに簡単過ぎるので、せっかく使える場面なのに使うのを忘れがちな方法でもある(そして複雑な通知システムを実装したりしてしまい、毎夜スパゲッティの夢にうなされる)。頭の片隅にこういう方法があるというのを覚えておくと、将来何かの役に立つかもしれない。 |
|
．ボーカロイドのマニュアルに書いてある通り、初音ミクは簡単には喋ってくれない。 ．歌と喋りの違いは音程の変化にある。歌は譜面の音にロックしてしまえば済む。あとは前後をスラーでつなぐかスタッカートで切るかという程度の違いしかない。喋りの場合は、アクセントとイントネーションによって音程が変化してゆく。 ．初音ミクに「私の名前は初音ミクです」と喋らせてみる。まずはアクセントもイントネーションも考えないで、一定の音程で打ち込むとこうなる: ．次にアクセントについて考えてみよう。日本語というのは高低アクセントが基本で、つまり音程の高低でアクセントを表す。アクセントは基本的に単語ごとに固有の属性で、標準語では三種類のパターンがある(「低高高……」「高低低……」「低高…低…」)。「わたしのなまえははつねみくです」は「低高高高低高高高低高高高低高低」ないしは「〜低低」になる。これを音程に反映させると次のようになる: ．喋りの音程変化には、アクセントの他にイントネーションがある。一つの文はいくつかのセンテンスに分けることができて、センテンスごとにひとまとまりのイントネーションを持つ。平叙文の場合、センテンスの先頭から末尾に向かって段々周波数が下がってゆくのが基本になる。「私の名前は初音ミクです」の場合、「私の名前は、初音ミクです」というふうに二つのセンテンスとして考えると自然になる。センテンスの切れ目は軽い空白を入れることがある。また、「ミク」で音程をもち上げた方が自然なイントネーションになる。これらをふまえて調整したのが次の通り: |
