Derive Your Dreams

12:21 06/05/28 うたひめ 先日の記事に書いたように KOKIA にハマりまして、 とりあえず片っ端から聴いてみることにしました。まずは 1st アルバムの 『songbird』 から … …４曲目の "白い雪" ヤバい。超ヤバい。なんだこれ。ツボすぎる。 ベスト盤を聴いたとき感じた揺らぎなく落ち着いた歌唱力的な曲を期待して聴きはじめたら、 予想外の声質の歌が飛び込んできてびっくりしました。もちろん抜群に巧いのに かわりはないんですが、ずっと儚げな、ガラス細工みたいなイメージの、ああ、その、 つまり白い雪みたいな雰囲気の綺麗な声で。その声と奇跡的にマッチしたメロディ。 すごいなあ。９曲目の "ありがとう…" もベスト盤でのリテイクと比べて同じ印象で、 Amazonのreview で TenderBerry さんという方が近いことを書いておられました。 しかし書いてて自分の語彙のなさが悲しくなってきたよ。 『trip trip』 も買ってあるのであとで聴こうと思います。

13:17 06/05/23 next/previous たつをさんによる 「次」と「前」の意味と並び順 という調査記事。面白い。 しかしこれ、なんでどのサービスも「次」「前」なんていうわっかりにくい言葉を 選んでいるんでしょう。例えば「新しい記事へ」「古い記事へ」 って表示すれば紛れがなくてよいと思うんですが…。 「新しい」「古い」だと、"表示中のページからの相対で" という意味が薄れる気がする？ 矢印や >> を添えて相対感を補うとか。「より新しい記事」や「もっと古い記事」 だと長く感じるのかな。

特に「次の○○件」みたいな使い方をしたい場合、 「新しい○○件」にしてしまうと確かにニュアンス違うかもしれない。 これはもう「○○件」とか具体的な件数出すのやめでいいじゃん。ダメ？

あるいは「次のページ」ならいいけど「新しいページ」だと Wiki のページでも新規作成しそうだ。

「古い」になんとなくネガティブなイメージがある？ それでも「次」「前」よりはマシではないかなあ。 ちなみに、この日記のナビゲーションは上のようなことをしばし考えた結果、 「一つ過去のページ」「一つ未来のページ」に落ち着いています。これはこれで 日本語として斬新すぎて自分でもちょっと笑えるのが最大の問題。 KOKIA 『pearl ～The Best Collection～』 を聴きまくっています。 このアルバムだと15曲目の「ありがとう」をBGM…というか効果音に使ってる動画を見かけて、 いい歌だなーと思って購入。調べてみたら有名なflashにも使われてたらしい。知らんかった。 ベスト盤だからというのはあるにしても、自分にとってハズレが一曲もないアルバムというのは とても珍しい。ほとんどの場合はよくても一、二曲は肌に合わないのがあるもんなんですが、 これは全曲好きです。知るきっかけとなった "ありがとう…" も勿論いいし、 "Desperado" も…最初聴いたときはオリジナルと比べて 薄い感じ？とか思ったけどこれもいいかと１分で思い直したり… いいし、 リズミカルな "So much love with you" も素晴らしい。

15:29 06/05/17 文字コード＆ベイズ推定 （ブラウザなりテキストエディタなりの）文字コードの自動判別を学習型の ベイジアンフィルタでやったら便利なのでは、と、さっきふと思ったりしました。 よくある実装は、「ある文字コードだと仮定したときにちゃんと読めるバイト列かどうか判定」 と「各文字コードごとのバイト値出現頻度表を用意しといて比較」と、あと適当に幾つか 場当たり的なチェックを組み合わせる感じだと思います。 auto_ef や Mozilla はそんな雰囲気。IEのはどうなんだろう。ちなみに GreenPad のはもっとずっと手抜き。 実はもっと洗練された判別アルゴリズムがあるのかも。まあいいや。 そういうのと比べると、「文字コードに関する静的な知識を持っていなくても、適当に その文字コードの文書をかき集めてきて学習させれば判別エンジンが作れる、ような気がする」 （"読み書きはもっとたくさんの対応しているけど、自動判定は ShiftJIS/EUC-JP/ISO-2022-JP/UTF-8 のみ対応です、他を含めると精度良い判別ができないので" みたいなことを言わなくて済む、ような気がする。）「いざ判定をミスったときにも、 ユーザーが指示して学習させれば次開くときはその文書（およびそれと似た内容かつ同じ 文字コードの文書）については判定を間違わないようにする、のが簡単そう」 （自動判別ミスをバグ報告されたりしたときに判定アルゴリズムを手動で改良してみたり、 無理ですごめんなさいと言ったりしなくていい。）（別にミスったときでなくても、 ユーザーの扱う文書の傾向に合わせて学習できたりするかも？）といった辺りが便利かな、と。 精度がどのくらい出るものかはよくわかりませんが…。 書いてて激しく既出な気がしてきたので検索してみると、 mikioさんの開発メモが引っかかりました。言語の自動判別まで含めてのお話ですが、 近いものは色々ありそう…。文字コードの判別だけに特化したらもっと簡単に精度あがったり しないかな。 Brouwer そういえば先週のサナギさんでブラウワーがネタになっていて笑。 はやりもの ヲタ漫画経験値 やってみました。×127 △42 ○23 ◎8。うへ、全然知らない…。 ちなみに◎は、山名沢湖、鬼頭莫宏、吉崎観音、あずまきよひこ、鳥山明、冨樫義博、 久米田康治、小畑健。なんというか、エニックス系の人が数人しかリストになくて これはきついというか、自分の買う漫画はとてもそっち方面に偏りすぎなことを改めて認識。

21:25 06/05/07 知らないこと ある日記サイトで読んだ文章が記憶に残っています。 中学生のころ、何の時間だったか、先生が黒板に小ぶりな円を描いた。

「いろんなことをたくさん勉強すれば物知りになって、知らないことやわからないことが少なくなると思いますか」

先生は一拍おいた。

「まったく反対です。勉強すればするほど、知らないことやわからないことがどんどん増えていきます」

そこで先生は、黒板の円を指した。 続きは 「日々是好日」 ２００４年１０月２０日 をどうぞ。"無知の知" 的なよくある話かもしれません。 しかし、印象に残るたとえだと思いました。どこまでスケールするかはともかく、 これを読んで以来、"知識" を漠然と "円" としてイメージする癖がついてしまっています。 たらい トラックバック受信のかわりの手動逆リンク集。 くるるさんによる証明 と、 山形さんによるそのメモ。Moore の方法を (m2,m1,m3) で回すと本質的にほとんど同じになるのかもしれません。「自然数の範囲で 考えればOK」という観察が -min(x,y,z) で、あとはmaxで外側の帰納法 → yが大きい場合は自明 → そうでない場合は中でxで内側の帰納法、という形になっているので。 確かに言われてみれば、xの帰納法には上限がありました。 住井さんによるMcCarthyの証明の紹介。すみませんScienceDirectにアクセス できるIPアドレスを得にいくのが面倒で手抜きしてました…(汗。ありがとうございます。 DTAK0(X,Y,Z) = DTAK00(X-Y,Z-Y) ここまでは、x-y や z-y 辺りを指標として使うのはありに思えました（nucさんもその方向をイメージして らしたみたい。）が、その先が物凄いですね。もう少しはなんとかなりそうな…確かに、 表現を変えればもっとわかりやすい帰納法だったりするのかもしれません。

21:47 06/05/03 Ruby と D言語 D言語の開発者である Walter Bright 氏への Bitwise誌によるインタビュー に、何度も Ruby が登場してて面白かったのでご紹介。 一部訳出してみますと Huw: つい先日、Ruby と D が同時に TIOBEのプログラミング言語 'トップ20' にランクインしました。構文の見た目は、Ruby と D では随分と違いますが、共通の特徴がいくつもあるのも確かです（例えば、かなり'純粋な'オブジェクト指向、簡潔な構文、GC、モジュールとmixin、クロージャ)。こういった Ruby と D の類似には、表面的なもの以上の何かがあるのでしょうか？ Walter Bright: Ruby と D には、興味深い共通項がたくさんあります。Ruby は Perl の reengineering として開発が始まっていて、Perl は C++ と ある意味でよく似ています（訳注: D は C++ の reengineering、という触れ込みの言語）。 Ruby は一人の開発者の、純粋にプログラミング言語が好きだという気持ちから生まれた言語であって、これも D と同じです。Ruby も D も、"プログラマの必要に応えるため" 以外の隠れた開発意図はありません ‐ だから、大企業がバックについて予算を投入したりせずとも、広くプログラマに受け入れられました。おそらく、この二つの言語の間の根本的な違いは、Rubyはインタプリタ系の、動的型の言語であることで、D はネイティブコンパイルの、静的型の言語であることでしょう。 色々突っ込みたい… D が fairly 'pure' OOP ? …ところはありますけど、それは おくとして。私も D の "template を mixin" する設計を見たとき真っ先に 思い出したのが "module を mixin" する Ruby だったりして、近いところはあるなあと いう気はしていました。 Huw: D は除くとすると、いまどきのプログラミング言語の中で、一番面白い、あるいは一番可能性を秘めていると思うのはどれですか？ Walter Bright: 疑問の余地はないですね。注目すべきは Ruby です。 だそうですよ。 ちなみにこの紹介を書いた私の隠された意図は、Rubyを褒めている記事を 引用することでRubyistの目をD言語に惹きつけてみるテスト、という下心なのですが、 そんなことをしている暇があったらむしろ自分がRubyを勉強せねば、とつい 数日前に思ったのだった…。

15:47 06/05/02 停止性 いえいえバッチリOKです。 ということで、検索してみました。Boyer&Moore の定理証明系Nqthmを使った証明 （Moore, 1979） が一発目ですね。その論文自体はちょっと見つからなかったのですが、実際の証明デモの サンプル(PDF)を発見。 三種類のメジャー m1, m2, m3 を定義して、 (m1(x,y,z), m2(x,y,z), m3(x,y,z)) で超限帰納法してるみたいです。方針はそれしかないとは思ったのですが… m1(x,y,z) = if x≦y then 0 else 1 m2(x,y,z) = max(x,y,z) - min(x,y,z) m3(x,y,z) = x - min(x,y,z) 2ω2。これどうやって思いつくんだろう…。Moore 以前にも、 McKarthy が別の（もっと複雑な）順序を入れて証明しているらしい。 TARAI が止まらない そして上記の結果を引用している論文を眺めていたら、 Tom Bailey, John Cowles, "Knuth's Generalization of Takeuchi's Tarai Function: Preliminary Report" (2000) がなかなか面白いです。Knuthが、たらいまわし関数のN引数に一般化バージョンを提唱して いるらしく。 t(x[1], x[2], ..., x[N]) = if x[1] <= x[2] then x[2] else t(t(x[1]-1, x[2], ..., x[N]), t(x[2]-1, x[3], ..., x[1]), t(x[3]-1, x[4], ..., x[2]), ..., t(x[N]-1, x[1], ..., x[N-1])) こういうもの。N=3の場合がいわゆる竹内/たらい/tak/tarai関数ですね。さて問題。 N>3 のときも、上の等式を満たす関数はそもそも存在するか？ 存在するなら、上の式に従ってcall-by-needで計算すると計算は停止するか？ 停止するなら、call-by-valueで計算したときもやはり停止するだろうか？ 1 まず１番目は…昨日向井さんに教えていただいたような、「大小関係に応じて引数の どれかを返す関数」の一般化バージョンになるんじゃないの？と予想できます。 λ(x[1], ..., x[N]). if x[1]≦x[2] then x[2] else if x[2]≦x[3] then x[3] else ... if x[N-1]≦x[N] then x[N] else x[1] 実際これは N=3 では正しかったし、N=4 でも正しい。ところが N=5 では成立しない。 t(5,3,2,0,1) が反例らしいです。これに気づいたKnuthは、↑の関数を一段複雑にしたような 関数を定義して、それが等式を満たすことを… "手ではたぶん証明できたと思うが、二度と チェックする気が起きない。誰か計算機で機械証明して欲しい" …という形でOpen Problemと して記します。しかしそのKnuthバージョンにも9年後、N=6での反例 が 発見されているとのこと。 2 Knuthは1と同時に、call-by-needなら止まる、という証明も与えていたそうなのですが、 反例が見つかってしまった誤った定式化に基づいていたので、これも一旦白紙に戻って、 Open Problem。 3 call-by-value ではどうか？ N=3 のときは、今日の記事の一番上に上げたような証明で、 止まることが知られている。しかし、N=4 のとき call-by-value では止まらない という例が2000年に示されているそうな。t(3,2,1,5) が無限ループするそうです。 ... と、こんな風な絶妙な境界線上に載っている楽しいテーマなんだそうな。 この論文自体は、1.にKnuthバージョンとは別の「今度こそ正しいはず」解を与えて、 2.については、「止まる」というConjectureを主張しているもの。 ACL2 を使って完全な機械証明を与えようとしている途中とのこと。手では証明できている つもりで何度もチェックしているけれど、Knuthの例もあるから…みたいな雰囲気で。

14:45 06/05/01 たらいまわし関数 またこの話ですすみません。 f(x,y,z) = if x <= y then y else f(f(x-1,y,z), f(y-1,z,x), f(z-1,x,y)) この計算は、経験的には、どんな整数３つを引数にしても停止するようです。 で、前からずっと気になっていたのが、これの停止性ってどうやって証明すればいいんだろう？ という疑問。あと、経験的には返値はx,y,zのどれかなんですけど、これもなんでだろう。 fの返値を再度fに与えてるので、両方同時に解かないといけない問題な気はする。 <= と -1 しかしていないので、初期値のoffsetは停止性には無関係。

なので適当にずらしながら自然数引数の場合だけ考える手があるのかもしれないが、 そうすると引数が普通の順序では単調減少でなくなるので、単純な帰納法にはならない。

うーん？ という感じで、いい考えが思いつきません。 エレガントな証明が知られてそうな予感がすごくするのですが。 追記 なるほど！ でも、例えばちと無理矢理ですが g n = if n <= 0 then 1 else g (n+1) - g (n-1) この等式は普通のフィボナッチ関数を当てはめると成り立ちますが、 この g は1以上の値を喰わせると停止しません。つまりある等式が (\x y z -> if x <= y then y else if y <= z then z else x) を当てはめると成り立つとしても、それがちゃんと停止してこの関数を 計算してくれるかどうかはただちに明らかではないような…。 （前略） …そういう閉鎖的なスタイルは、誰にとっても得がない上に誰にとっても損があるのでは ないかと。自分は、ACM会員だけ見られるページに論文があればそこにリンクするし、 dat落ちした2chスレにも必要なら言及するし、もし仮に全てのchatのlogやpersonal conversationにURIが振られる日が来たら、そのURIを全て貼り付けながら日記を書くでしょう。 （そもそもの前提として、「誰もが見られる情報のみに依存しているか、もしくは完全に 自己完結した記事しか書かない」という縛りは面白くないと思う。） そうしないことによる"損"とは、敢えてそうしていないこのエントリが示しているように、 閲覧者に無駄にネタ元を憶測させる手間でありググらせる手間であり。

presented by k.inaba (kiki .a.t. kmonos.net) under