Hatena::ブログ(Diary)

やねうらお−ノーゲーム・ノーライフ このページをアンテナに追加 RSSフィード

GT-Rの買取ならここですわ。どこよりも高く買取ってもらえるはず。お勧め!GT-R 買取
電王戦出場記念! 書籍化されたで! 監修したで!(`ω´) 絶版なってしもた Kindle版で復活!! 記事書いたで!
解析魔法少女美咲ちゃん マジカル・オープン!

YaneuLabs / やねうら王公式 / やねうらおにメール / twitter / プロフィール

 | 

2004-03-31 一応の結論

[][][][][] ソースコードのmodularityの低さ(4)  ソースコードのmodularityの低さ(4)を含むブックマーク  ソースコードのmodularityの低さ(4)のブックマークコメント

長々と書いてしまった。全然話しが進みやしねぇ。

もう、ソースコードがコンパイラの特定のバージョンを強要するのは別にあっても構わないと思う。COMインターフェースで特定のバージョンの実装を要求するのと同じである。

それが叶わないならば、コンパイラを自作してしまうことだ。欲を言えば、VM(Virtual Machine:仮想マシン)とJITコンパイラを用意して、その上に自分のコードを構築する。こうしておけば、新しい環境が出たとしてもVMを新しい環境に移植するだけの手間で済む。

VM仕様を考えるのが面倒なら.NETのIL(Intermediate Language:中間言語)をそのまま使ってもいい。これ、使っておけば少なくともLinuxならmonoベースで動かせなくはないだろう。JITコンパイラも作るのが面倒なら、managed C++でもC#でも好きなのを使えばいい。まあ、.NETのIL用のコンパイラは比較的作りやすいので、簡単なコンパイラなら大学プログラミングの演習程度の手間で作れなくはない。まあ、それこそ、1日か2日あれば十分だ。

ともかく、その上にいろいろ構築していく。そうすれば、コンパイラのバージョンが上がることはない。自作のコンパイラをバージョンアップしたいのならば少なくとも自己責任だし、納得はいく。(気がする)

さて、話を戻して、部品としての要件についてもう少し突っ込んで考えてゆこう。このへん、自作言語なら何でもありだ。

トラックバック - http://d.hatena.ne.jp/yaneurao/20040331

2004-03-30 もうどうでもええか..という気になってくるよな?

[][][][][] ソースコードのmodularityの低さ(3)  ソースコードのmodularityの低さ(3)を含むブックマーク  ソースコードのmodularityの低さ(3)のブックマークコメント

C++の標準もどんどん進化している。それはそれで構わないのだが、古いバージョンのコンパイラ向けに書かれたコードは新しいバージョンでコンパイルできないという事態は起こりうる。そういう事態が起こったとき、プログラマは通例FDIS/ISではどちらが正しい実装なんだ?とか調べることになる。

まあ、それはそれで真摯な姿勢なのだとは思うけど、それ以前に考えんとあかんことがあるんちゃうの?VC++5用のコードがVC++6で、VC++6用のコードがVC++.NETでそのままコンパイル出来ないという事実には変わりないし、両方のコンパイラで動くコードを書くことはもちろん大切なことだし、複数のコンパイラでコンパイルが通るようにすることは現実的にはとても大切なことだろうけど、しかしやね、同じベンダーの同じコンパイラの異なるバージョンに対してさえコードの互換性はないってどういうことよ?そこには、上位互換性すらないのよ。おまけにlibファイルすらもフォーマットが変わろうとしている。

C++の標準がどんどん変革していき、それに伴い古いコードはコンパイルすら通らなくなる。globalなstatic変数は知らない間に廃止の方向に向かい、無名namespaceで代用することになっている。それはそれで構わないんだけど、そのツケをユーザーが背負わなければならない。5年とか10年ほど前のコードを引っ張り出してくると必ずコンパイルが通らなかったりする。そんな時、とてもやるせない気持ちになる。

C++は、標準の仕様があって、VC++6とかVC++.NETとかは、その実装の一つにすぎない。必ず標準に従ったプログラムを書いて、標準から外れているならそのソースをなおさなければならない。そうするのが常識のように思われているが、よく考えるとこれはとても馬鹿げている。それこそ、ソースとコンパイラをセットにして管理するのならば、そんな手間は不要になる。逆に言えば、そうしない限りは、いつまでもC++の標準にソースを追随させていかなければならない。これは尋常ならざる手間なのだ。

ソースコードを部品として再利用することを考えようにも、その部品を作る工場(コンパイラ)が破棄され、部品が作れなくなってしまうというのは、もうそもそも話にならない。部品以前の問題なのである。しかし、プログラマはコンパイラがバージョンアップするごとに自分のソースを新しいコンパイラに追随させる苦労を繰り返す。これは、まだこの先、5年も10年も続いてゆくだろう。そんなことが慣例として行なわれ、常識と思われている。そうしてみるとプログラマはよほど馬鹿なのか、非常識な連中だと言わざるを得ないだろう。もちろん、コンパイラを作っているわけでもない、単なるコンパイラユーザーにすぎない一介のプログラマにとって、そうする以外にどうしようもないという意味もあるのだが。

トラックバック - http://d.hatena.ne.jp/yaneurao/20040330

2004-03-29 プログラマはいまだに原始人のようなことやってますよ!

[][][][][] ソースコードのmodularityの低さ(2)  ソースコードのmodularityの低さ(2)を含むブックマーク  ソースコードのmodularityの低さ(2)のブックマークコメント

バイナリレベルでの相互呼び出しに関しては、COMでもCORBAでも、まあ何でもいいのだが、それほど実現するのは難しくはない。これと同じことをソースレベルで行なえるかというと、そりゃもう、不可能に近い。

なんでか?

ソースコードが特定のコンパイラ、あるいは特定のコンパイラの特定のバージョンに依存したりしてるからである。

yaneSDK2ndはVC5/6を対象にしていた。yaneSDK3rdはVC6/.NET(7 or 7.1)を対象にしている。yaneSDK4DはD言語だし、yaneSDK4CsはC#だ。これらのソースは、水と油のようになっており、互いに混じり合うことは出来ない。

ところが、バイナリレベルでならば相互に呼び出すことは可能だろう。COMのような大がかりな仕組みでなくとも、DLLをLoadLibraryで読み込んで、そのなかの関数を呼び出すというのでも構わないし、libを作成してバイナリ生成時にリンクしてしまう、というのでも構わない。

プロセッサをPentiumに固定してしまうなら、原則的にバイナリは一種類である。どんなソースをコンパイルしてもPentiumマシンコードに翻訳されるし、それこそがコンパイラの仕事だからだ。(いまネイティブコードの吐けないC#,Javaのことは考えないことにする)

つまりは、frontendを作ってソースコードを「マシンコードよりの言語」にいったん落とし込んでやれば、それぞれの言語を混交させることが可能になってくるわけだ。「マシンコードよりの言語」って、マシンコードでは駄目なのだろうか?私は駄目だと思う。マシンコードでは、機能が分解されすぎていて、どれが関数で、どれがswitch〜caseかを見分けることすら困難になるからだ。

まあ、仮に、C++JavaD言語もすべてC言語ソースにいったん落として、ごにょごにょ加工することを考える。まあ、GC付きの言語GCなしの言語とごちゃ混ぜにするとややこしいことになるが、そのへんはいま考えないことにする。厳密に言えば、C++からCへのトランスレータが必要なのではなくて、VC++6用に書かれたソースからCへのトランスレータVC++.NET用に書かれたソースからCへのトランスレータetc..が必要なのである。

この仕組みがあって、はじめて、VC++6のソースVC++.NETのソースとを混交させることが出来る。VC++.NETの関数から、VC++6のクラスメソッドを呼び出すことが出来るようになるのである。逆に言えば、この仕組みがないから、VC++6用に書かれたソースや、VC++5用に書かれたソースは、もう.NET時代においてはリライトを余儀なくされるわけだ。過去の資産運用なんて、てんで出来てない。新しいコンパイラでは古いコンパイラ用に書かれたコードをコンパイルすら出来ない。これがC/C++言語の実情だ。いかに下位互換性を重視しながら拡張してきたとは言っても、そのへんの事情は実にさぶーいのだ。

この先、こんなことが何度も起こるだろう。.NET用のコードは.NET2005でコンパイルできないとか、.NET2005用のコードは、.NET2008でコンパイルできないとかな..。こんなのはとても正気の沙汰とは思えない。

何故こんなことが起きるのだろうか?それは、ソースコードにコンパイラがembedされていないからだ。何を当たり前の、と思われるかも知れないが、コンパイラ本体なんて小さいのだから、もうソースにくっつけちゃえばいいのだ。

..とまあ、そんなことは叶いそうにはないので、もう少し真面目にこの問題について取り組まなくてはならないだろう。(つづく)

トラックバック - http://d.hatena.ne.jp/yaneurao/20040329

2004-03-28 こんなん全然近代的じゃないっすよ

[][][][] ソースコードのmodularityの低さ(1)  ソースコードのmodularityの低さ(1)を含むブックマーク  ソースコードのmodularityの低さ(1)のブックマークコメント

いまだに、やねうらおはC++でプログラムを書かないといけないことがある。この状態はまだしばらくの間は続くと思う。C++は、ライブラリを部品のように使うことが出来ない。namespaceを使って書けば、名前空間を形成することは出来る。それは、部品ではないのか?―――断じてNo!だ。部品としての要件をほとんどと言っていいほど満たしていない。

たとえば、あるライブラリをコンパイルするときに、オプションをconfigureすることが出来るが、よく考えると、この仕組みはおかしい。

いま、部品を組み合わせて何かを組み立てることを考えるとしよう。部品は市販の標準部品だ。規格でぴったり決められている。これを購入してから必要ならばその部品を加工する。configureを変更するということは、部品そのものを購入前に加工してしまうことに相当する。オーダーメイドの部品を要求するわけだ。これは特注部品であって、部品を部品そのままの形で使っていることにはならない。そのソースはコンパイル時に、なんとかライブラリを持ってきてconfigureでこない設定してコンパイルしてくださいという但し書きをつける必要が出てくる。

わかりにくい?

あるライブラリのAという処理に対してA’,A’’という二つの実装を用意してあるとしよう。使う側からすれば、いま、このライブラリのA’の実装のほうを指定したいのだ。そのためにライブラリのconfigureをいじってAの実装にはA’を使いなさいと指定する必要が出てくる。さもなくば、templateを用いて、A’の実装を実体化する必要が出てくる。実際、そういうやりかたを目にすることは多いが、それはtemplateの濫用だと思う。もちろん、templateを用いる以外に、やりようが無いから仕方なしにやっている意味もあるのだが..。(つづく)

トラックバック - http://d.hatena.ne.jp/yaneurao/20040328

2004-03-26 携帯開発の明るくない兆し

[][][][][] 携帯ゲームプログラミングHells(2)  携帯ゲームプログラミングHells(2)を含むブックマーク  携帯ゲームプログラミングHells(2)のブックマークコメント

FOMAのような高速にJavaを実行できるマシンにすると携帯の単価があがる、だから今後はbrew(C/C++)を採用する、というauの方針は正しいと思う。

それはともかく、brewJavaについてもう少し技術的に突っ込んでみる。

brew用のアプリにキャリア側の認証が必要なのは、brew自体のセキュリティ機能が甘いからだと思われる。メモリアクセスだけの話ならばユーザーセグメント外にアクセスできないようにハード的に規制してあればそれでいいと思うのだが、悪意のあるユーザーならばAPIに対して変なパラメータを渡してバッファオーバーランのようなことは出来るだろうから、実際はそう簡単でもないのだろう。

一方Javaのほうなら、そういう心配はないのかと言えば、そうでもない。悪意のあるユーザーならば何なりと出来ると思う。まあ、そのへんの対策はベンダーにでも頭をひねっていただくとして、本当に低クロック安価で高速なJavaマシンは不可能なのだろうか?

JavaVMのバイトコードを直接実行する安価Javaチップが普及すれば、という話もあるが、あれはひいき目に見てもあまりいい構想だったとは思えない。*1

汎用チップVMJavaバイトコードを実行した場合、10〜15倍程度の遅さであるが、JITで変換したものなら、せいぜい2〜3倍、ゲームの大半は描画等の処理時間であることを考えれば、実際の影響は2倍以下である。おまけに、Javaチップで構成した場合、何もかもをJavaコードで書かなければならない。GCさえも、である。JavaVMコードは1命令の粒度がでかいので、すべての命令を1clockで実行できるように設計したりすると、逆にGCのような単純な処理は遅くなりかねない。かと言って、命令ごとにclock数を変えると、結局のところは汎用チップと比べてそんなに速くもならない気がする。

そう考えると、Javaチップ安価になるのを待つぐらいなら、汎用チップの進化を期待するほうがまともだ。

ところで、iモードFOMA(900iシリーズ)でずいぶん高速化されており、Javaでも比較的まともなアプリが書けると思われている。しかし、現状でも依然商業的な開発は地獄だ。他のアプリが15FPS(frames per second)出ているなら*2クライアント側からは、それと同じ15FPS程度は出ることを要求される。しかし、この15FPSという数字は、ゲーム中(ゲームの初期化終了後)にnewを一切呼び出さず、Cのようにプログラムを書いて、かりかりにインライン展開したりチューンしたりしてやっと到達できる数値である。それと同じスタイルのプログラムを要求されるということだ。とてもJavaのプログラムとは思えないし、こんなプログラムを書かされるぐらいならCのほうがよっぽどマシとも言える。

いつになれば、携帯Javaはこの地獄から抜け出せるのか?それは、メモリがもっとふんだんにあって、手抜きプログラムでも余裕でmax frame(60FPS?)に到達できて、チューンせずとも製品としてリリースできるようになった時である。楽観的に見てもやはり1年か2年は必要だろう。そんなわけで携帯の進化予想としては、来年brew全盛期になって、そのあとJavaが盛り返すような形になるのではないかと思う。

*1Javaの実行に特化されたチップの開発というなら方向性はわからなくもないのだが。

*2:この15というのは、たとえの話。

enraenra 2004/04/03 09:59 BREWは機種によっては範囲外アクセスを検知してリセットをかけてくれるものもありますね。

yaneuraoyaneurao 2004/04/03 10:10 あれどんな仕組みなんやろか?調べてカキコぷりーず。

enraenra 2004/04/06 07:51 最近のARMは新しい命令セットを作ってJAVAバイトコードを高速に実行するようですね。FOMAにつこてあるのはこれかな?

yaneuraoyaneurao 2004/04/07 07:54 ふーん、そうなんや。そのへん資料まとめて、書いてクレクレ。こっちからリンクはるわ。

トラックバック - http://d.hatena.ne.jp/yaneurao/20040326

2004-03-25 携帯開発は地獄だぜよ

[][][][][] 携帯ゲームプログラミングHells(1)  携帯ゲームプログラミングHells(1)を含むブックマーク  携帯ゲームプログラミングHells(1)のブックマークコメント

ABAさんが昨日の私の記事についてフォローしてくださったので紹介。

http://d.hatena.ne.jp/ABA/20040324#p1

BREWの問題点は、キャリアから認定されていないアプリ、いわゆる
勝手アプリが作れないことにある。これは単なるauの方針なのか、
それともJavaのサンドボックスモデルのようなものがないからいちいち
検証をしなければいけないのか、どっちなのかは分からないけど、
これのせいでのら開発者にとってはまったく魅力のない端末に
なってしまっている。

brew開発者にとってはまったく魅力のない端末であることは確かにそうかも知れない。この開発者っていうのを、ABAさんが言われるようにホビープログラマ(のら開発者)に限定するのならば、まさにそうだと思う。brewで開発するためには、KDDICP契約(コンテンツプロバイダ契約)を行ない、クアルコムに対してdeveloper契約を行なわないといけないからだ。

しかし実際のところ、それがどう市場に影響するのだろうか?携帯所有者の9割以上はプログラマではない。正確な数字は知らないが、プログラマのうちでも携帯で何かを開発しようという人はさらに一握りなので、実際のところ99%ぐらいは携帯プログラマではないと言っても過言ではないだろう。このようなマイノリティが市場でどんな意味を持つのだろうか?

携帯ユーザーの大半は、カメラがついていることや、月額利用料が安いことなどに惹かれて機種を買い換えたりする。プログラムが開発しやすいかどうかなんて、まったく眼中にない。FinalFantasyやリッジレーサーのようなゲームが動くことは魅力だが、機種を買い換えるほどの大きな理由にはならないだろう。まして、ホビープログラマのほにゃららさんのゲームがしたくて機種を変更しました!みたいな人は、さらに少数。市場的にはほとんど無視できると言って良いと思う。

そうなってくると、もう、携帯の開発の方向性としてはbrewでも構わない、Javaを動かすためにFOMAのように高いスペックチップを投入してそれが基本料金等に跳ね返ったら何にもならない。私もそう思うし、auの判断は正しいと思う。

ただし..私が言いたいのは、こんな素人でもわかるような議論ではなく、もう少し技術的に突っ込んだ部分なのだ。(続く)

uyumuyum 2004/03/26 05:31 ABAさんは『のら』開発者と明記されてますのでホビープログラマ限定のお話かと。

yaneuraoyaneurao 2004/03/26 07:05 そうですネ..ちょっと私の書き方がまずかったので文章手直ししました。

トラックバック - http://d.hatena.ne.jp/yaneurao/20040325

2004-03-24 GC付きの言語

[][][][][][][] GC付きの言語におけるゲームプログラミング(1)  GC付きの言語におけるゲームプログラミング(1)を含むブックマーク  GC付きの言語におけるゲームプログラミング(1)のブックマークコメント

GC(Garbage Collector)はオブジェクトを解放する手間が不要になる。世紀の大発明だったと言っても過言ではないだろう。しかし、それが便利なのかどうかは微妙なところだと思う。実際のところ、C#Javaでまともな(市販レベルの)プログラムが組まれるようになってきたのは、つい最近のことであり、公平に見て、試行錯誤段階だと言わなければならないだろう。

ファイナライザ(≒C++のデストラクタ)が呼び出されるのはGCがそのオブジェクトを解放した時なのだが、ファイナライザでリソースを解放するようなクラス設計をするとまずいことになる。たとえば、ビデオメモリのような外部リソース(.NETの用語ではunmanaged resourceと呼ぶ)を扱うと、その解放をファイナライザに期待しても無駄である。なぜなら、ファイナライザが呼び出されるのはGCオブジェクトを回収する時であり、GCは自分の管理するGCヒープから確保したメモリが圧迫されない限り働こうとはしないからだ。

結果として、メインメモリはふんだんにあるのに、GCが働かないためunmanaged resourceが無尽蔵に使用され、ソフトがハングアップしてしまうことがある。これを避けるために、unmanaged resourceを扱う場合は、マネージャクラスを作ったり何なりしなければならない。

まあ、このへんの問題を少しでも緩和するためにGCを拡張する話も出ている。

WhidbeyGCが拡張される:

http://blogs.msdn.com/brada/archive/2003/12/12/50948.aspx

何せ、GCというのはまだまだ発展途上にある技術なのだということだ。状況によってはGC付きの言語よりC++のほうがはるかにマシだと言うことを肝に銘じておく必要がある。

やや余談になるが、携帯Javaなんてひどいもんだ。同じ理由でGCが働かないためにリソースを使い切ってしまうことがある。もともとメモリが火の車なので一刻も早く解放しなければならないというのに、悠長にGCがcollectするのを待ってられない。

もうそうなってくると、携帯Javaでは、GCに期待できない。またnewのオーバーヘッドも馬鹿にならないので、ゲーム開始時とかシーンの初期化時以外にnewを使えない。残る手段はC風にプログラムを書くことだ。こんなプログラム書くのなら、C++のほうが遙かにマシである。

おまけにJavaはリフレクションのためにクラスファイルに変数名を埋め込みやがるんで、変数名が長いとその分、jarファイルがでかくなって携帯に読み込めなくなったりする。おかげで、変数の使用頻度をカウントしてハフマン符号化のようにしてなるべく短い変数名と置換するソフトを用意しないといけなかったりしてくる。携帯の進化のスピードから察するに、こんな状態がまだ1,2年は続くと思われる。携帯Javaを採用しようとか最初に言い出した奴は、とんだ食わせ者なんじゃないかしらん。

2004-03-23 アマゾンのレビューはひどい。・゜・(ノД`)・゜・。

[] アマゾンのレビューに無茶苦茶書くのは勘弁してちょうだい。  アマゾンのレビューに無茶苦茶書くのは勘弁してちょうだい。を含むブックマーク  アマゾンのレビューに無茶苦茶書くのは勘弁してちょうだい。のブックマークコメント

アマゾンのレビュー、かなりひどいんだ。まあ、レビューを書いてる人は、その本を読まないといけない人であって、本を書いている人が先生だとすれば、生徒にあたる。つまり、生徒が先生批評しているような形になるので、まともに内容の評価が出来るはずないと言ってみればそうなんだけど、それにしてもひどいんだ。

たとえば私の著書やね本2、正式名称「Windowsプロフェッショナルゲームプログラミング2」(ISBN:4798006033)について見てみると、

トレードオフを正しく評価できる人向け,

なんでタイトルのレビューがあって、中身を見ると、どうも、この人はやね本2で解説しているsoftware packed add(擬似的にpacked演算を実現する)を指して言っているようだ。さらに読み進めると..

それぞれのトピックスについて言うとウィンドウズAPIやMMXテクノロジ
の様なビットパケット処理機能を代替する類の内容であり(つまりこの本に寄
らなくてもウィンドウズやライブラリ標準の機能で実装できることが多い)、
APIコールとライブラリコールのメモリ使用量および消費CPUタイムについて、
またはペンティアムの通常/MMXモード切り替えに伴うトレードオフを
評価できるだけの能力を持った“プロフェッショナル”向けの印象を受けた。

WindowsAPIて、BitBltでadd colorは出来ないし、MMXテクノロジで可変長のpacked addは出来ない。DirectXOpenGLを使って3Dの機能でadd colorするというならわからないでもないが、どうもそのことではないような感じだ。*1 GDI+のことか?

ついでに言うなら、MMXモードとの切り替えに伴うコストがうんぬんとあるが、おそらくemmsのことを指しているのだと思うが(PentiumMMXへの切り替えコストなど存在しない)、add colorする関数を抜けるたびにemmsするような馬鹿なことは誰もしない。blter(転送ルーチン)の終了の時にemmsを実行するだけである。浮動小数点を使わない限りはそれでいい。ということで、MMXで書いていいならばMMXで書くのが速いに決まってる。トレードオフでも何でもない。ただ、可変長のpacked演算が出来ないからMMXを使う場合でも結局software packed演算が必要になってくるのだが。

他の人のレビューも見てみよう。

構成、各章の内容が中途半端なため、
初心者が読むには癖がありすぎて参考になりませんし、
ある程度経験がある人ならこの本を読む必要がありません。

なんて書いてやがる。まあ、お釈迦さまのように寛大な心を持つやねうらお(ただしそう思っているのは自分のみ)は、前2行は許してやるとしよう。しかし、最後の「ある程度経験がある人ならこの本を読む必要がありません。」はいかんだろ。まるであたかも自分が「ある程度経験がある人」だと言いたげだが、この人がアマゾンで買っている本は結城先生Javaの入門書とかそんなのだ。だとすれば、ひどい言いがかりだ。そもそも、たとえばやね本2でとりあげたゲームのタスクシステムについてだが、他のどの本に詳しく載ってると言うんだろうか。*2 本当にそういった知識をある程度できるプログラマならば誰でも知ってることだと言えるんだろうか。

まあ、いいや。ここに登場いただいたお二人に別に怨みがあるわけでも何でもないので、これくらいにしておこう。的確なレビューをするのは大変なんですよという話だ。また、こういうレビューを見ると、こういう人たちにも良さがわかってもらえるように配慮しないといけないんだなぁ、と自分自身反省したりもする。

そんな感じで初心者の人*3にとんでもないコメントをつけられていい迷惑しているやね本1,2だが、出版社のほう、そろそろ在庫が無いらしい。増刷すればいいんだが、担当のプッシュだけでは上層部は増刷に踏み切れないらしい。せっかくだから、いろいろ書き足して*4やね本1,2の合体本を出そうかとか考えたりもしている。

*1:言うまでもなくビデオカードのアクセラレーションに頼れるならそっちのほうがよっぽど速い。それはadd colorの速度がうんぬんとか言う問題ではなくて、ビデオメモリ内で転送が完結するなら、システムメモリを変にこねくり回すより速いのは当然だと思うのだが。

*2:ある人から、ずーっと昔に元ナムコの人が書いた本に載っているとかいう話を教えてもらったが、とっくの昔に絶版になっているようで入手すらできない。

*3:後者の人と違って前者の人はすぶの素人だとは思わないが、技術的見地から見ても少し見当はずれなコメントだと言う感じはする。

*43Dを使った2D描画とかについても書かないとね。

enraenra 2004/04/03 04:07 きっとそのレビュアーは未だに銀の弾丸を探しているのですね(’A`)

yaneuraoyaneurao 2004/04/07 07:57 う、、うむ。

通る人通る人 2006/07/16 11:08 ネット時代(web2.0とかいうんだっけ?)。だれが、どんな経歴の人がその文章を書いているのか?ということにみんな無頓着に感じますね。
バイナリだけみてソースコードがないような物でオープンソースとして成り立ってないようなものなのに。

トラックバック - http://d.hatena.ne.jp/yaneurao/20040323

2004-03-22 最近読んだ良書

[][] そりゃもう、自分が天才かと思うほどわかりやすかった本!  そりゃもう、自分が天才かと思うほどわかりやすかった本!を含むブックマーク  そりゃもう、自分が天才かと思うほどわかりやすかった本!のブックマークコメント

「これならわかる応用数学教室」(ISBN:4320017382)これがわかりやすくてたまらなかった。本当は別の射影幾何学の教科書を買ったついでに、図書券が余っていたので安かった(2900円)ので衝動買いしただけだったのだが、ホントよかった。射影幾何学の本そっちのけで読んだ。それも、なんか、すらすら読めて、ルジャンドル・チェビシェフ・エルミート・ラゲールの多項式、あと、離散コサイン変換、主軸変換、ウェーブレット解析まで数時間でわかってしまった。(元々知ってたのもいくつかあるが)

本の章立てがホント、系統立てられていて無駄がない。こういう無駄のなさ、好きだなぁ..。同じ手法で押していくのでわかりやすいし。段階もきちんと踏んである。高校卒業程度の知識で十分読める良書である。

なんか3D勉強することに決めてから、数学力をちょっと取り戻そうと寝る前に数学の「30講シリーズ」やら何やらを順番に読んでいたりするのだ。理解できるとか出来ないとかそんなの関係ない。 小説のように読む。読みたいから読む。知的好奇心で読む。興味本位で読む。週刊文春のゴシップ記事を読むのと同じ感覚で読む。それくらいの気持ちで読むのがヨロシイ。あまり肩肘張ると長続きしない。

系統立てるとか、無駄のないようにする、というのは、こういう教科書や本の構成の次元のみならず、プログラミング、そして文学にも共通することだ。プログラムを正しく構築していける人は、つねに自分のプログラムについて系統立てて(矛盾のない)無駄のない説明をすることが出来る。これが出来ない人のプログラムは信用できない。そして、そういうプログラムを書く人の人間性もなんだか怪しい気がしてくる。もちろん、それはある種の拡大解釈なのだろうけど、実際のところ私の場合プログラムを20年以上やっているわけだし、プログラムを通じて相手が何を考えているか想像がつくことがある。ここの一行を書いたときに、相手はモニターの向こうで歯ぎしりをしていたなとか、この一行に至っては、眠い目をこすりながらやっていただろうだとか、ここは会社に行く前に急いで修正したのだとか。そういう風にプログラムを一種のフィルターとして相手を見てしまう。しかし、決して「プログラムにバグがあるからこの相手の人間性は信用できない」とかそういう判断はしてはいけないと肝に銘じている。

実際のところバグは、そういう単純なものではないのだ。バグが産まれてくる過程は、もっといくつものファクターが絡んでくる。時には、ちょうど推理小説で作者が仕掛けた罠に読者がミスリードされるかのようにして、産まれてくる。そんな作者の罠にひっかかった読者の人格や人間性を否定してはいかんと思う。むしろ、めったにバグを起こさない人間は、他人のあら探ししか出来ない人間不信者かも知れない。

それはともかく。話を少し戻そう。系統立てて小説を構成すると言えば、三島由紀夫の「金閣寺」を思い出した。以前、稲葉さんが「なんと無駄のない小説だ」と書いてたが、私もそう思う。

主人公は、空襲によって焼け滅ぶ金閣寺と共に滅んでゆく自分の死を渇望している。美しい日本の美とともに、自分も死ぬ。その同時完結性を望むわけだ。ところが金閣寺は焼けずに残る。そのとき主人公に言いようのない断続感が生じる。要するにこれは殉教の美学なのだ。主人公は金閣と共に滅ぶことで永遠性を獲得しようとした。これが叶わんなら、もう、いっそうのこと燃やしてしもたろかい!とか考えだすわけだ。

もっとわかりやすい言葉で言えば、「オレ、あぶらギッシュなロリコンメガネデブオタク。自分でも自分はキモヲタだと思うけど、だからってどうしようもないぜ。あっ、あそこにカワイイ幼女が。あいつにいたずらして幼女のエキスを得て、パワーアップだヽ(`・ω・´)b」..って、それはぜんぜん違うような気がしてきた。なんか日本で一番馬鹿な三島評論を書いてしまった気がする..それも歴史に残るぐらいの馬鹿さ加減で。もう今日は寝よう。おやすみ。

2004-03-21 日本で天才は潰される

[][]日本数学者は育たない? 日本で数学者は育たない?を含むブックマーク 日本で数学者は育たない?のブックマークコメント

日本に大数学者は居ないんじゃないか」とか書くとあちこちから怒られそうだが、遠山啓、矢野健太郎など名前は知っていてもその業績についてはいまひとつわからない。そもそも高校や大学数学物理の教科書に出てくる公式や定理の名前はほとんどすべて外人名前が付いている。*1

日本人は頭が悪いのか?と言うと、そんなことは無いと思うのだが。日本語圏と英語圏の人口格差のせいだろうか?そりゃたくさん居たら居たほうが有利のような気はする。たぶん英語を日常的に話す人の数は5億人ぐらいは居るはずだ。日本の4倍ぐらいだろうか?しかし、それを言えば、中国なんぞは12億人は居るだろうが中国人の数学者なんてほとんど名前すら聞いたことが無い。教育レベルが違うのかも知れないが、単純に人数に比例するというわけでもなさそうだ。

そういう意味では日本人が馬鹿なのは日本教育制度の問題なのかも知れない。若いころに神童と呼ばれたような少年が、結局は自分の好きな科目しかしないために頭の悪い学校にしか進学できず、自分のしたくもない科目を嫌々やってそのうち勉強嫌いになったりする。そう考えるとなんだか気の毒だ。彼らは悪しき教育制度による被害者なのだ。日本の風土では天才の大半は若い内にその才能の芽をついばまれる。

次に言語の壁だ。専門書や文献はたいてい英語で書かれている。学会で発表するのも英語にならざるを得ない。小学校の、一番よく覚えられる時に英語を教えずに中学からやったところで、覚えられないものは覚えられないのである!(自信たっぷりに言うことではないだろうが)

それからマーケットの小ささだ。日本でまともな技術書の書き手が居ないのは、こういった糞みたいな教育によって書き手がスポイルされていることもあるだろうが、マーケットが(英語圏に比べて)小さいというのもある。おまけに、頑張って書いても難しい本は売れない。初心者向けの、それこそインターネットで探せばオンラインで読めるような内容の本がよく売れたりする。ついでに言えば、技術書の場合、よほどベストセラーにならない限りは、ビジネスアプリでも書いているほうがよっぽど儲かるというのもある。優秀な技術者であればあるほどその傾向は顕著だ。よって、優秀な技術者による本というのはほとんど考えられない。私の場合も(自分が優秀な技術者と言うわけではないが)目下のところ、本を書いているよりはプログラムを書いているほうがはるかに儲かる。

なんかそう考えると日本の出版業界は全般的にサブーイ気はする。考えてみるに、ここ数年間に読んだ日本研究者によるコンピュータ関係の書籍(翻訳本は除く)で良かったと思うのは中田先生の「コンパイラの構成と最適化」と結城先生の「Java言語で学ぶデザインパターン入門 マルチスレッド編」*2だけだった。洋書の中で良かったと思う本は枚挙いとまないほどなのだが。

そうは言っても、自分自身マニュアル本のような本に助けられることも多々ある。自分で試行錯誤を繰り返す時間を大幅にはしょれることがあるからだ。そういう本を「内容の薄い本」だと批判するのは簡単だが、意味のない、売れない本という認識は間違っていると思う。

以上、とりあえず、だらだら書いてみただけなので結論めいたものは控える。

*1:これについてはこんな意見をいただいた→http://yaneu.com/cgi/yanebbs/dobbsr.cgi?a=view&topic_id=1077382762&res_id=46-47
あと、確率積分で「伊藤の公式」というのがあるそうな。日本人名前がついててちょっと嬉しかったり。

*2:この本、良書だけにJavaに限定しないほうがよかった気がする。おそらくはC++Javaと同じものを説明するのが泥臭いと感じたからだと思うが、大変惜しい。手前みそではあるが、やねうらおの「Windowsプロフェッショナルゲームプログラミング2」(ISBN:4798006033)では、この本にあるマルチスレッドデザインパターンC++で書いたものを用意しているので興味のある人は読まれたし。

atuyaatuya 2004/03/21 01:36 岡潔、高木貞治、小平邦彦など外国の数学者でも絶対知っている大数学者ですよー

atuyaatuya 2004/03/21 01:38 中国の数学者ではTuさんやChernさんなどはめちゃくちゃ有名ですよー

atuyaatuya 2004/03/21 01:39 数学英語はめちゃくちゃ簡単なので言語の壁は無いに等しいですよー

atuyaatuya 2004/03/21 01:40 たくさん書いてごめんなさいm(__)m

yaneuraoyaneurao 2004/03/21 03:13 高木さんしか知らない..(´Д`) 不勉強でごめんなちゃい。

yaneuraoyaneurao 2004/03/21 03:53 数学の英語は数式とかは日本語と1対1に対応するんで読みやすいですけど、それでも論文とかはやっぱし難しいです(´Д`)

詠み人知らず詠み人知らず 2004/05/05 21:53 Fermat の証明では日本人の出した予想や証明が中心にあります

詠み人知らず詠み人知らず 2004/05/05 21:53 たとえば谷山-志村-Weil 予想とか Bloch-加藤 予想とか肥田氏の p進 Hecke 環だとか

2004-03-20 将棋−形の理解

問題局面

[][][]形勢判断の基本事項(1) 形勢判断の基本事項(1)を含むブックマーク 形勢判断の基本事項(1)のブックマークコメント

何手先を読もうが、終盤で詰みまで読み切れる局面でない限りは、非終端ノードでの、何らかの形勢判断を行なう必要がある。

この形勢判断を正しく行なうのは、意外と難しい。そもそも、絶対的に正確な形勢判断が出来るのならば、1手だけ先を読んで形勢を判断すればそれで最強なのである。

実際は、先を読まないと駒損することが判明しないことだってある。駒損すると、たいていはそれが形勢に直結するので、そのようなラディカルな局面においては、静的に局面評価を行なうと実際の形勢を大きく誤認する原因となる。だもんで、そういう局面では、駒の取り合いが終わる部分まで延長探索をして静止評価するのが普通である。

それはともかく、ちょっとの盤面を見て欲しい。序盤でよくある形だ。後手が7七角成と角交換をして来た形なのだが、この馬の取り方は3通りある。同銀、同金、同桂である。有段者ならば「形」からして有無を言わず同銀ととるだろうが、これをコンピュータに理解させるのは難しい。そもそも、どの駒でとったところですぐに駒損するわけではないからだ。

コンピュータの場合、駒損は簡単に判定できるのだが、それ以外の「利かし」〜「利かされ」や「形」は、比較的数値化しにくい、難しいパラメータだと言えるだろう。「利かし」〜「利かされ」については、人間でもアマ五段ぐらいでは理解しているとは言い難い。*1

さて、この問題の局面だが、この形では銀で取る、という知識データベース的なIF構造を積み重ねても強くなるとはとても思えない。それは本質的に問題解決の方向性を誤っていると思う。3手とか5手読みの時代ならばそれでも良いかも知れないが、そういう処理をする限りは「形」を本当に理解しているとは言えず、少し形から外れれば平気で変な手を指してくる。だもんで、その手のIFは一切導入せず、正しく評価できるように局面評価関数をチューンしていかなければならない。

能書きはこれくらいにして、この問題の局面についてもう少し深く考えてみよう。同桂ととらない理由は、同桂のあと、後手から飛車先を交換されるからである。先手からの飛車先の交換は成立しない(42銀〜33銀で拒否できる)のに対して後手に一方的に飛車先を交換されるのは大損である。だもんで、形を理解していないとしてもこの部分を読めば同桂とは指さない..と思うのだが、そう簡単でもない。同桂に対してすぐに8六歩同歩同飛に対しては、7五角やあるいは6五桂と跳ねて鬼殺しの成功図のようになるのだ。だから、4二銀(7五角の防ぎ)としてから8六歩が必要になる。ついでに、4二銀68玉86歩同歩同飛4八銀8二飛と局面が収まるところまで読まなければならない。しかし、同飛のときに、2二角と打ち込む手があり、3三角と合わせても、1一角成、同角、8七香、7六飛、8一香成、6二銀、8三歩となると難しい局面になる。先手駒損ながらも、後手からは大駒だけなので有効な手段がなさそうだからである。やや先手がいいような気もするがもっと先まで読まないと、とても形勢を判断できそうにない。そんなわけで後手は4二銀のあと飛車先を交換しに行く前に3二金が必要なのだ。これがあれば2二角の打ち込みはない。結局は先手は後手の飛車先の交換を拒否できない。ところが、4二銀6八玉3二金4八銀8六歩同歩同飛ときたときに、8五歩とか飛車をとじこめて、この間に8三角から馬を作るような手順がある。この飛車が本当に生還できるのかどうか怪しい局面になる。とまあ、本当のところ、すぐに飛車先を交換しに行く手は成立するかどうかはかなり先まで読んでも見極めることは困難だ。どのみち後手からすれば8八の銀が壁になっていて進展性がないことを見越して囲い合うようにすれば自然に作戦勝ちになると思うのだが、そのことをコンピュータに静的評価で理解させるためには、「囲いの進展性」というパラメータが必要になる。しかし桂跳ね自体が急戦志向の手で、急戦が成立する場合、「囲いの進展性」はあまり重要なパラメータではないので、このあと急戦が成立するようであれば、囲いの進展性が無いことはデメリットではなくなる。実際は、このあと急戦は成立しないので損なのだが..。

かと言って玉を8九までは移動できるわけで、玉の囲いやすさ自体は悪くはないと思う。桂を跳ねてその桂があった場所に玉を囲う手を否定するなら、振り飛車に対する西田スペシャル(かまぼこ囲い)をも否定することに成りかねない。また、仮に組み上がるころに飛車先を仮に交換されたとしても、そこから銀冠に囲えるならたいした損ではないかも知れない。実際は、このあと後手は角換わり棒銀、先手はしゃがみ矢倉でそれを受けるような形になって先手はいずれ手詰まりになると思うのだが、ともかく、同桂の変化は難解だ。何か明確に咎める手段があると思うのだが調べれば調べるほどわからなくなる。ここに来て、現代将棋は組み上がり形を想定して指し手を進めていることに気づく。矢倉に対して飛車先の歩を突かないのもそうだし、角交換に5筋の歩を突かないのもそうだ。「組み上がり形を想定する」のをコンピュータにやらせるには、「組み上げる」(駒をぶつけずに進展させていく)という概念をもう少し明確に定義する必要がある。これはこれで長くなりそうなのでまた別の機会に書くことにする。ただ、いまのコンピュータ将棋に一番不足している部分だとも言っておこう。

次に問題の局面で同金としない理由について考えてみる。同金は一応は飛車先の交換を拒否できる。しかし、金が上ずった形なので見るからに損だ。銀の進展性もない。おまけに、8一の桂が跳ねてくれば将来的に当たってくる。敵の桂の進路に金や大駒があるのは嫌な形だ。玉も囲いようがない。かと言って、すぐにこの金上がりを咎められるかというと難しい。将来的に〜になると言うのは、そこまで読まないといけないので、それを読まずに済ませたいのならば、この場合「駒の進展性」「玉の囲いやすさ」「敵の安い駒(桂)の進路にこちらの価値の高い駒があるか」というようなパラメータを導入しないといけないことになる。「金の上ずり具合」に対して駒の働きとしてペナルティを与えても良いが、入玉の時や、たこ金戦法のような局面の評価を誤りかねないので導入にはよっぽど気をつける必要があるだろう。

ともかく、これくらいやればコンピュータにも少しは形の理解が出来るというのはおぼろげながら見えてきた。しかし、たくさんの評価パラメータを導入すると今度はパラメータ間のチューンをするのが難しくなってくる。形勢互角の局面をたくさん入力しておき、それらに対して最小二乗法等で各パラメータの重み決定を行なうのだが、それぞれのパラメータが線形結合とは限らないので、なかなか大変である。このへん、いい加減にやるならニューラルネットワーク等を使ってもいいのだが、あれは、経験上、相関関係とか関数モデルとか全然わからない時に「まー許せる範囲の結果が出るのであればアルゴリズム考えんでいい分楽でええわー」ぐらいの気持ちで導入するものなので、まともにチューンしたものに勝ることはまずあり得ないので最初から使わないと決めておく。

そんなわけでパラメータ調整について詳しいことは次回にでも書くことにする。

*1:くどいようだが、やねうらおはmy com認定でアマ五段であるが、羽生名人が盤面解説で「これは利かされですから」と言っているのが、少し見ただけでは理解できない時がある。アマ五段なんて所詮その程度のものなのである。

krackmaniakrackmania 2004/03/19 13:48 羽生名人で思い出したんですが、羽生名人の頭にカメラを付けて視点から思考ル−チンを研究すると言う面白い話を聞いたんですが、どこだっけかなあ・・。やねさんは囲碁とかもやりますか?

yaneuraoyaneurao 2004/03/19 19:02 記事はこれですネ → http://www.yomiuri.co.jp/net/feature/004/20030820fe02.htm

yaneuraoyaneurao 2004/03/19 19:04 囲碁もやりますけど、囲碁のほうはまだ始めたばかりで初段にも届かないです(´ω`) まあ、続けてればいずれは四段ぐらいまではなれると思いますけど..

トラックバック - http://d.hatena.ne.jp/yaneurao/20040320

2004-03-19 近未来的プログラミング

[][][][][] 近未来プログラミング(1)  近未来的プログラミング(1)を含むブックマーク  近未来的プログラミング(1)のブックマークコメント

D言語のテンプレート機構は、明示的なインスタンス化が必要になる代わりに、C++には出来ないようなことまで出来る。それば事実なのだが、それがいいか悪いかは別問題である。思えばJavaC#にもGenericsが導入され、いよいよ本格的に足並みをそろえた感もある。

また、やねうらおも通常はC++でテンプレートを用いてかなり複雑なメタプログラミングを行なうこともある。しかしだ。やればやるほど、こういう方向性は根本的に誤っているのではないかという疑念をいだくようになった。

それぞれの言語がそれぞれの方法でテンプレートをサポートしたり、それぞれ異なる仕様のプリプロセッサを持っていたりするのは非常にばかげていると思う。現実問題として、C++ソースC#、あるいはJavaに移植しないといけないことがある。この逆をしないといけないこともある。そういったときに、言語に依存する機能ほど移植を難解にするものはない。

その言語を使う限りは気持ちよくプログラミングできるのかも知れないが、そんなプログラムを移植させられる者はたまったもんではない。最近、それを特に感じる。

結局何が悪いかというと、Genericsやらメタプログラミングやら、プリプロセッサやら何やらかんやら。そういったものは、言語間で共通するサードパーティ製のツールで実現するべきであって、決して、言語仕様そのものを改定すべき問題ではなかったと思うのだ。たとえばmix-inにしても、AspectJ/C#/Cppを用いることで比較的すんなり実現できる。言語そのものにmix-inを取り入れて、それをその言語のアドバンテージかのように言うのは、もういい加減やめにしないか?DbyC(design by contract:表明つきプログラム)にせよ、何にせよだ。

結局何が必要かというと、もっと汎用的なテンプレートやDbyCを実現するための、Aspectほにゃららをも包括するようなツールと、そういったツールを受容する言語側の仕組みなのだ。決して、必要なのはGenericsでも何でもない。その言語にしかないような言語固有の機能なんてメリットでも何でもないのだ。いい加減、みんな早く目を醒ませ!

.NETによってどの言語でもライブラリを対等に呼び出せるようになったが、次にこの仕組みにより、どの言語も等しいgeneric programming、DbyC、mix-in、delegate、inner function、lambda、property etc..に関する機能を享受することが出来るようになるわけだ。CでもC#でも同一のステージに立つことが出来るようになる。言語間の差異は極限まで縮まる。まずは、そこまで思考を推し進めよう。続きは次回だ。

トラックバック - http://d.hatena.ne.jp/yaneurao/20040319

2004-03-18 理想的なプログラミング言語

[][]記事書いたっすよ! 記事書いたっすよ!を含むブックマーク 記事書いたっすよ!のブックマークコメント

今日発売の「Software Design」誌に11ページもD言語の記事を書いた。はっきり言って書きすぎである。

ここ半年間はD言語の先見性に惹かれ、毎日いろいろといじってみる日々であった。

しかし、結局のところは、またC++(あるいはJavaC#)での開発に戻らねばならないと痛感している。これは、D言語の未成熟さもあるが、それ以前の問題として、携帯を始めとしてC++Javaを使わなければならない状況というのは依然として存在するからである。

どの言語が優れているかとかそういう問題ではなく、その携帯端末ではJavaしか動かなかったり、韓国人に作ったパチモンのCしか動かなかったりと、まあそういった状況だからである。

それにしても、C++言語デザインは忌むべきものだと思う。「Effective C++」や「More Effective C++」、あるいは「Modern C++ Design」、あと「Effective STL」有名なのが、この4冊。あとARM(The Annotated C++ Reference Manual:注解C++リファレンスマニュアル)、それからFDIS(C++ Final Draft International Standard) ついでに「Exceptional C++」とか「More Exceptional C++」とかもか。

プロのまともなC++プログラマならば、これらをすべて読んでいて然りだし、少なくともFDIS以外は精読していて然りである。

そうは思うものの、いま「Effective C++」やら何やらを読み返してみると、ホント頭悪いなぁと思う。もちろん「Modern C++ Design」もだ。書いている人が頭が悪いと言っているのではない。こんな解説書が必要になり、また必須であると思われている状況が、もうどうしようもなくやるせなくなるのだ。こんな解説書が必要になるというのはC++言語デザインの悪さゆえなのに。

「Modern C++ Design」を知らずしてテンプレートを語るなと言われる。確かにそうかも知れない。この本以前のテンプレート批判は本当に的はずれだった。かと言って、「Modern C++ Design」が珠玉のテクニック集か何かと思われている雰囲気、これがもうたまらない。

はっきり言って、こんなテクニックを理解する時間があれば、まともなコンパイラが実装できるのに。そっちのほうが、何倍も有益で、普遍的なものなのに。

などといつも思うのだが、自作のpreprocessorというのは(作るのは簡単だが)それはそれでまたいろいろ問題がある。C++Javaでは外部ツールでの言語拡張を想定していないということだ。たとえばAspectJと、この自作のpreprocessorを組み合わせるとどうなるか?そもそも組み合わさるのか?EPP*1などはこの問題をうまく回避している。

このへんについて詳しいことは、C++/C#/Javaで共通して使えるシュゴー(゜Д゜)なpreprocessorを作ってからまた書くことにする。

k_ahiruk_ahiru 2004/03/17 21:51 うちの近くにSD売ってる店が…。読みたい(゜ω゜)

yaneuraoyaneurao 2004/03/17 22:06 ホントに紹介記事なのであひるさんだとたぶん読んでも得るものが..

akirameiakiramei 2004/03/17 23:17 ついにSD発売ですね! 早速立ち読みしなければ!!<買えよ・・・

yaneuraoyaneurao 2004/03/17 23:20 meiさんも立ち読みでいいでしょう(^^;

kiku_tkiku_t 2004/03/18 17:12 横から失礼します.最近C++に興味を持ってる者です.MCDもすこし読んだのですがなんともいえない違和感におそわれ,これをyaneuraoさんが上記で代弁してくださってるような感じがしました.よかったら今後もよろしくお願い申し上げます.

yaneuraoyaneurao 2004/03/18 17:27 よろしくですm(_ _)m

2004-03-16 リバーシの現状

[][][]リバーシの現状 リバーシの現状を含むブックマーク リバーシの現状のブックマークコメント

本を整理している時に1980年代アスキー誌が出てきて、コンピュータオセロのトーナメント記事を読み返した。当時、Z80で、最強のオセロは森田オセロ。序盤は定石、終盤は8手を完全に読む。中盤がやや弱く、そこを改良していくことが今後の課題とされていた。

いまはどうなんだろう?試しに、コンピュータと対戦できるリバーシ(オセロと同等のルールオセロがツクダオリジナルの商標なのでこの名前を用いてある)をやってみると..。

Zebra:

http://www.nada.kth.se/~gunnar/othello.html

なんと最強のモードにすれば終盤の26手が完全読みである。にもかかわらずそのモードにしても私のマシンで、1手5秒程度しか掛からない。序盤はかなりの範囲まで定石データベースがあるようだ。まあ、26手も読んである程度正しく形勢判断が出来るのならば定石なんて必要ないのかも知れない。

それにしても、オセロは8×8=64、最初から4つ置いてあるので60手しか無いゲームで、序盤の30手ぐらいが定石で、終盤の26手を読み切られたら中盤は4手しか無いことになる。とてもじゃないが勝ち目が無い。さらに言えば、34手以上の定石に関しては定石終了時点で、先手勝ちか後手勝ちかが終盤の読み切りにより確定してしまうことになる。はっきり言って無茶苦茶である。

思うに、オセロは終盤は手が限定され収束していくので組み合わせ爆発が生じにくい。あと10年後のパソコンでならば40手ぐらいは完全読み切りが出来るんじゃないだろうか。そうなってくると、定石自体の善悪まで問われてくることになる。兎定石は20手目で後手勝ちとか。鼠定石は20手目で先手勝ちとか。うーん。そこまで来るとやる気なくすなぁ。

それはともかく、強いプレイヤーと対戦できると得るものが多い。これはどんなゲームでもそうだ。いわばリバーシの世界チャンピオンがあなたと遊んでくれるわけだ。その結果、形勢判断にシビアになり、すぐにでも有段者になれる。実に恵まれている。

将棋囲碁もそれくらい強いソフトが出来ればいいと思うのだが..。*1

*1:ちなみに、やねうらおは将棋はmy comの認定によるとアマ5段の棋力。最強と言われている東大将棋6でも少し物足りない。

10年後の使者10年後の使者 2014/03/26 23:14 それくらい強い将棋のソフトをあなたが10年後に作りました。

トラックバック - http://d.hatena.ne.jp/yaneurao/20040316

2004-03-08 本がめきめき整理できちゃう!

[] ドキュメントスキャナ  ドキュメントスキャナを含むブックマーク  ドキュメントスキャナのブックマークコメント

そんなわけで、fujituのfi-5110EOX*1を買った。ソフマップで49,800円だった。

価格.comでインターネット通販を使えば42,000円で買えることは知っていたが、私の場合、無茶してすぐ壊しそうだったので、5年保証にしてもらうためにあえてソフマップで買うことにした。

そんなわけで、買ってきて20時間ぶっつづけでスキャンした。寝るのも忘れていた。面白いように取り込める。コンビニのコピー機より速い。一晩で、ダンボール1箱分の本をスキャンした。このスピードは異常だ。本をカッターナイフで解体するのだが、その解体が追いつかないぐらいだ。今日、裁断機を買ってこよう。(裁断機のほうがこのスキャナより高い気がしなくもないが)

こんなペースだと、部屋の本ぜんぶスキャンする日も近いぞ。しかも両面スキャンできている。自動的に傾き補整してカラーか白黒かを判別してpdfファイルになる。紙詰まりが発生しない限りは、スキャナ側についている開始のボタンを1回押すだけだ。パソコン側では何も行なう必要はない。これがすごい。

買えば3万するらしいAdobeのAcrobat6.0もついてくる。pdfファイルタブレットからメモを書き込んだり出来る。ホント、pdfが紙のようだ。

古い雑誌で特集記事のためだけに捨てられずにいるのとか、全部スキャンしてやった。ほんとスゴーだ。

そんなわけで、お前ら、買え!これを買わないでどうする!彼女をソープに沈めてでも買え!*2 超おすすめだ。

*1:参考記事→
1.槻ノ木隆のPC実験室 http://pc.watch.impress.co.jp/docs/2004/0303/pclabo21.htm
2.スパタ斉藤のスパトロニクスmobile http://k-tai.impress.co.jp/cda/article/stapa/18032.html

*2:当方は一切責任を負わないのであしからず

2004-03-06 本は邪魔なりよヽ(`Д´)ノ

[] 本をデジタルデータに  本をデジタルデータにを含むブックマーク  本をデジタルデータにのブックマークコメント

だいぶ処分したけど、まだ書籍が数千冊あるんだ。これが邪魔で仕方ない。

そこで、ドキュメントスキャナで取り込んでしまえって思った。

思えば86年の夏にパーソナルユースでGT3000というスキャナが初めて発売された。50dpiで8色。定価は198,000円だった。取り込み速度も非常に遅かったと記憶している。それでも当時は心底すごいと思ったんだ。

その数年後に、GT3000を5万円で譲り受けた。初めてのスキャナで、楽しくて毎日何かしらスキャンしてたな。

いま買おうと思っているのは

・fi-5110EOX

http://scansnap.fujitsu.com/jp/products/products.html#specifications

だ。相場は45,000円前後。はっきり言って、この速度でこの性能でこの値段は安すぎる。

→買ったゾ。レポートはこちら。

さて。自動ページめくり機能がない場合、本を解体してスキャンしなければならない。職人芸でもなければ一度解体したものを元の本に戻すのは不可能だろう。もう、そうなってくると、スキャン後の残骸は捨てるしかない。しかし、これを捨てるとなると著作権上ややこしい問題に逢着する。

原本を捨てているわけで、所有権は放棄していることにはならないだろうか?所有権を放棄した本のコピーを所有しているのは著作権法上は許されないのではなかろうか?

どうも真面目に考えるとややこしいことになりそうだ。とりあえず取り込み後の原本はダンボール箱にでも入れて物置に入れておくしかなさそうだ。困るなぁ..(´Д`) 著作権法、このへん改善してくれないかなぁ..もう、いっそうのこと最初からデジタルデータで販売してくれればそれでいいんだけどな。しかしデジタルデータだと譲渡とかの扱いが難しいんだろうな。

↑ 2007/02/02 08:58 まぁもう見てないと思うけど、著作権上問題ありません。

yaneuraoyaneurao 2007/02/02 09:40 詳しい説明きぼんぬ。

2004-03-03 web book

[]web本の紹介コーナー web本の紹介コーナーを含むブックマーク web本の紹介コーナーのブックマークコメント

そんなわけでwebで公開されている本を紹介するコーナーを用意した。

http://www.sun-inet.or.jp/~yaneurao/webbook/

みなさんの投稿等、お待ちしてますm(_ _)m

[][] あの本がタダで!?  あの本がタダで!?を含むブックマーク  あの本がタダで!?のブックマークコメント

「実践CGへの誘い」(絶版本)の寄贈のご案内

http://www.kke.co.jp/product/book_present.html

もらえるぞ!!いそげ!!!送料は600円前後だそうな。

→めでたく終了したそうな。

jellyfish_lifejellyfish_life 2004/03/15 03:27 やねうらお様、はじめまして。jellyfish_life といいます。

jellyfish_lifejellyfish_life 2004/03/15 03:27 便利なサイトを紹介して頂きましてありがとうございます。

jellyfish_lifejellyfish_life 2004/03/15 03:28 あと、http://d.hatena.ne.jp/yaneurao/20040308#p1 のドキュメントスキャナのレポートも非常に参考になりました。

jellyfish_lifejellyfish_life 2004/03/15 03:28 ちょくちょく寄らせて頂きますので、宜しくお願い致します。

yaneuraoyaneurao 2004/03/15 03:31 いらはいいらはい。情報等あればタレコミもどうぞ(^^;

jellyfish_lifejellyfish_life 2004/03/15 03:32 ...早い!! コメントありがとうございます。↑了解しました。

トラックバック - http://d.hatena.ne.jp/yaneurao/20040303

2004-03-02 Schemeだってやっちゃうゾ!と

[][][] を含むブックマーク のブックマークコメント

もう時代は超並列言語だぜよってなわけで

PICT:π-calculusに基づく言語

論文(紹介?)で、以下のが秀逸だったので紹介。

http://www.cs.indiana.edu/cgi-bin/techreports/TRNNN.cgi?trnum=TR476

それで先日買ったMilnerたんの本*1、さらさらっと軽く読んだけど、別に関数プログラミングするのにλ-calculusについて考えたりしないしなー。こんなもん読まなくてもπ-calculusを用いるプログラミング言語、使えるんだろなーとか勝手なことを考えて終了。(いい加減な)


あとは、稲葉さんの日記で紹介されてたやつが、気になった。

http://mitpress.mit.edu/sicp/full-text/book/book.html

> SICP (「計算機プログラムの構造と解釈」、Scheme を使って

> プログラミング言語の基礎概念を解説した名教科書です)

> ってWebで全文公開されてるんですねー

うひょー。

そだそだ。Webで公開されているこの手の本へのリンク、誰か集めて公開してもらえませんか?*2

*1ASIN:0521658691 Communicating and Mobile Systems: The Pi-Calculus

*2:誰もやらないようなら私がやろっかな..

akirameiakiramei 2004/03/03 02:32 SICP、英語が苦手で本を買った根性無しです(^^;

akirameiakiramei 2004/03/03 02:33 あ、既に名前取られてたakirameiことmeiです。

yaneuraoyaneurao 2004/03/03 02:35 いらはいいらはい。>meiさん

TELLTELL 2004/07/05 22:07 遅レスで、もうすでにご存じかも、しかもあまりテーマにあっていない気がしますが、http://www.sci.kagoshima-u.ac.jp/~ebsa/というサイトがあります。

トラックバック - http://d.hatena.ne.jp/yaneurao/20040302
 | 

1900 | 01 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2013 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2014 | 01 | 02 | 03 | 04 | 06 | 08 | 10 | 11 | 12 |
2015 | 01 | 02 |


Microsoft MVP
Microsoft MVP Visual C# 2006.07-2011.06