[mixi] 改訂は誇り

安斎利洋の日記

2006年04月02日
14:10

改訂は誇り

以前から買おうと思っていたヲノサトルさんの作曲の本を購入。奥付を見たら昨年暮れに「初版発行」となっている。え、そんなはずないぞ。隅々までよーく見たら、２００１年発行の改訂版である、と、すごく小さい字で書いてある。

昔、小林龍生さんと書いたＣＧの本は一度全面改訂を出すことができて、嬉しかった。改訂版が出るというのは、本が売れている証拠だから誇るべきことなのだ。最近は、改訂であることを隠すのが版元の考え方なんだろうか。

でもそういえば、類書の多いコンピュータや理科学系の本を選ぶときなど、ついつい発行日が新しい方を選んでしまう。新しければ新しいほど信頼がおける。ってことは、本より雑誌のほうがいいし、雑誌よりＷｅｂのほうがいい。コンピュータの雑誌が軒並みつぶれているのは、そのためだ。

こういうときは、古い情報のほうに置き忘れられた宝物が残っていたりする。

　

コメント

2006年04月02日
16:19

本を出すのには時間と手間がかかりますが、さらに年月を経て発酵させた結果を改訂という形で出せたら、作者冥利です。

「ヲノサトルの甘い作曲講座」は、以前に改訂前のを買いました。おもしろいですね。新旧の目次立てを比較すると、「循環進行～ループ和声の極意」が「5度を制する者は和声を制す」に変わり、「大人のコード術～密集和音と開離和音」が終章に移動しています。改訂版だということを強調しない理由はわかりませんが。

2006年04月02日
16:30

CG本で再版は立派です。実は情報には古いも新しいもなくて、差異を保ち続けているかが問題のように思う。

2006年04月02日
16:54

最近、研究仲間に「並列論理型言語GHCとその応用」という1987年の本を薦めたら、彼が出版元の共立出版から手に入れたその本は、私のと同じ初版本でした。

GHC は、普通に書くと並行プログラムになるという強烈な言語で、この古い本には、今のインターネットだからこそ使えるアイデアがたくさん詰まっているように思います。

2006年04月02日
17:31

eikoさん、プロの視点ですね。
ヲノさんの書いていることは、この数年で古くなるような知識じゃないんですが、でも５年前と今とでは、作曲ということ自体のイメージが変わるくらい、環境が変わったことは確かですね。
昔フジテレビの深夜に「音楽の正体」っていうのがあって、かなり良い番組だと思っているんですが、あれを今の環境でやったら、面白いだろうな。

2006年04月02日
17:38

>差異を保ち続けているかが問題のように思う。

その通りだと思います。最初にＣＧの本を書いたときに、Turbo Pascal2.0のソースをつけたんですが、瞬く間にその部分だけ古くなってしまった。本文は、いまでも通用すると思うんだけど。小林さんと書いた本はTurbo Pascal4.0のソースをつけたんだけれど、改訂のときソースは変えたところはないのに、Turbo Pascal5.0対応とうたったらまた売れた。

差異の座標軸とは別に、世の中すべてグローバルな「ヴァージョンアップ軸」みたいなもので価値が測られていて、とくにＩＴにからむ世界は情報はどんどん過去のヴァージョンになってしまう。

2006年04月02日
17:45

>並列論理型言語

それ、まさに今の要請にこたえますね。カンブリアンのノンリニアな知識表現をどう記号化していくかというときに、もしかするといちばん参考にしなくてはならない領域かもしれない。

２０年後に、ちゃんと評価される仕事を残していかないとなー。

2006年04月02日
22:46

びすけっと

並列論理型言語は実に面白い言語でして，当時はどうやったら
並行・分散プログラムをさりげなく書くか競ってましたね．
その手の研究に一気に水をさしたのが，wwwの登場なんですよ．
どうしようもないへたくそな分散システムが世界を征して
しまって．

2006年04月02日
22:57

>その手の研究に一気に水をさしたのが，wwwの登場なんですよ．

並列論理型言語って、スーパーコンピュータのように構造が安定なシステムを想定して作られているんですよね。

Webのように、つながっているときはつながっている、つながっているつもりで情報を取りにいくとつながってないときもある、みたいな不安定なシステムにも、うまく適用できるように考えられているんでしょうか。

2006年04月02日
23:18

まったく逆なんじゃないですかね．
Googleの登場によって，ようやく関数型プログラミングが
メジャーになったと言える．Googleでは使っている言語はC++だけど，
その中で行っている操作は並列関数型プログラミングです．
(関数型と論理型の違いはよくわかってないんですけど．)

2006年04月02日
23:46

ルールは、その世界に対して宣言しているのか、クラスに対して宣言しているのか、というのを突き詰めていくと、同じになったりしますよね。

世界は無数の違う関数をもった生物が生きている、と考えるか、無数の生物は同じ論理で動いている、と考えるか、そういうふたつの世界観があったとしたら、その中間になじみやすい世界があるんじゃないかと思うんだけど、そういうのってないんですか？　並列関数論理型、みたいなのって。

2006年04月03日
00:52

びすけっと

どうみてもえとさん
wwwが出てからGoogleが登場するまでの期間に，止めちゃう
人が多かったと思います．予算も続かなかったのかもしれ
ない．とにかく，まじめに非均質分散システムをやっていた
人たちは，一気にやる気をなくした．ただの集中システム
が複数あるというのが世界を征しちゃったんだもの．
Googleは，そのずっと後という印象です．

並列論理型の肝は論理変数のユニフィケーションを使った
暗黙の通信で，普通の並列とか関数型よりももっとすごい
概念です．値がいらなければ送らないんだから．たぶん
Googleには使われていないと思う．もっと非均質で不定型
な問題を扱うのが得意です．とうとう，それが必要とする
時代になったか，ですね．

wwwのせいというよりも，研究はドッグイヤーじゃ
ないのに，研究者がそれに釣られたせいかもしれないなぁ．

安斎さん
当時作られたシステムはどっちかというと暗黙に並列性を
向上させようという方向だったので，おっしゃる実装が
主だったと思いますが，考え方は不安定なシステムでも
使えると思います．かえって不安定なシステムの方が
その特徴を出しやすいはず．

名前としては並列関数論理型言語はありました．どんなん
だっけな．単に全部くっつけただけだったかもしれない．

オブジェクト＋並行性
vs
関係，論理型

これの融合はまだだと思う．多分，後者が前者を含む形に
なるんじゃないかなぁ．

2006年04月03日
02:28

論理型言語は、びすけっとさんが書かれているのと同じ意味になると思いますが、relation を使うもので、関数より一般的になると思います。

並列論理型言語では、プロセスを生み出しながら動く並行アルゴリズムを記述する (普通に書くとそうなる) ので、論理的にはダイナミックな分散システムを記述できます。実装はまた別の話で、複製をうまく使って、不安定なシステムでも動くように作れるのではないでしょうか。障害を前提とした分散 agreement とか commitment とか、80年代後半から90年代にかけての研究の成果がいろいろと応用できると思います。

2006年04月03日
03:44

> 並列論理型の肝は論理変数のユニフィケーションを使った
> 暗黙の通信で，普通の並列とか関数型よりももっとすごい
> 概念です．値がいらなければ送らないんだから．たぶん
> Googleには使われていないと思う．

たしかに使われてないですね。前言撤回します。:-)

論理型の話を聞いていると、SematicWebを思い浮べますけど、
あそこは研究費の面ではかなり入ってきているみたいですね。
なんだ幸せじゃんかよ、と思いました。

2006年04月03日
04:48

Grid computingではどんな言語使うのですか？

2006年04月03日
10:16

びすけっと

> 障害を前提とした分散 agreement とか commitment とか、
> 80年代後半から90年代にかけての研究の成果がいろいろと
> 応用できると思います。

そうですね．いい感じだと思います．

> 論理型の話を聞いていると、SematicWebを思い浮べますけど、
> あそこは研究費の面ではかなり入ってきているみたいですね。
> なんだ幸せじゃんかよ、と思いました。

2種類に分かれて，自明な問題をゴージャスに解いて時流に
乗る側と，ものすごく難しい問題を解きたいという気持ちを
隠して進める側．前者はお金で分野を切り替えて，後者は
問題からはずっと離れないで，お金で対象を切り替える(いまはWeb)．

Grid ComputingはC++かJavaだと思います．昔はベクトル
計算機でスーパーコンピュータを作ったのを，今はPCを
たくさん繋いでつくる．台数が増えるほど故障もしやすく
なりますから，両者がかなり近づいてきていることは
確かでしょう．知識の表現法は従来どおりで
実装技術が今風ということですね．

2006年04月03日
13:22

基本的なことかもしれないけれど、質問。

たとえばマンデルブロ集合を並列で計算するとき、複素平面のどの点も他の点から独立で計算できるから、分業したらあとは勝手にやらせておけばいい。

たとえばライフゲームを並列で計算させるときは、それぞれのセルは近傍のセルの結果をもらわないと次のステップにいけないから、待たなくてはならない。

こういう単純な話ならいいんだけど、実際のアプリケーションはもっと複雑に、並列化できるところとできないところ、並列を同期させるべきところが入り組んでいるはず。

並列論理型というのは、こういうのをプログラマが明示的に切り分けなくても、勝手に並行するプロセスを生成してくれるんでしょうか。

2006年04月03日
17:54

もういっこ質問

たとえば並列論理型で分散検索エンジンを作ろう、なんていうことをイメージすると、観測しながら観測対象が変化していくわけだから、直感的に解が収束しないような気がするんだけど、どうでしょう。むしろ、戦略をもった無数のエージェントが協調するようなモデルのほうが、ちゃんと働く姿がイメージしやすい。

>「並列論理型言語GHCとその応用」

Amazon経由で古本を注文しました。

2006年04月03日
18:33

＞実際のアプリケーションはもっと複雑に、並列化できる
＞ところとできないところ

昔、私が並列計算機に関わっていた頃はプログラマがプログラムを解析して並列化する部分の抽出やデータの配置および交換の手順を手作業でコーディングしていました。
最近の事情には疎いのですが、いまだに、完全自動化に成功しているという話は聞かないですから本格的なチューニングは実現されていないのでは？
多少は自動化されているとは思いますが。

＞並列論理型というのは、こういうのをプログラマが明示的
＞に切り分けなくても、勝手に並行するプロセスを生成して
＞くれるんでしょうか。

プログラマから見て並列性が素直に記述できるのと実際にマシン上で効率よく並列処理されるというのは全く別の問題です。
GHCがハードで実装するときの効率を意識して設計されていたという話は聞いた覚えないですね。

そもそもICOTのPIM自体最終形態は共有メモリ型のクラスタをネットワークで繋いだ極々オーソドックスな並列計算機でしたから、GHCの並列性とはセマンティカルなギャップは大きかったんではないですか？

2006年04月04日
08:52

＞並列論理型というのは、こういうのをプログラマが明示的
＞に切り分けなくても、勝手に並行するプロセスを生成して
＞くれるんでしょうか。

私は実際に並列に計算する GHC の処理系に関わったことがなく、シングルプロセスの処理系を書いたことがあるだけなので、間違ったことを言っているかも知れませんが、基本的に、GHC ではすべてが並行プロセスですから、実際の処理系では、基本が並行の中から、いかに逐次性を取り出すか、という最適化になってくるのではないかと思います。

プロセスをプロセッサに割り当てる方法は、GHC をベースにした KL1 という言語で指定が可能だったように思います。

>戦略をもった無数のエージェントが協調するようなモデル
>のほうが、ちゃんと働く姿がイメージしやすい。

そういうプログラムは、GHC でおそらく書けると思います。

2006年04月04日
15:29

びすけっと

どんどんずれていってますが，おもしろいので．
論理型言語が成功した理由は，当時のCPUでも動く効率の
よさと，宣言的な記述との按配というか配分が，うまい
レベルだったからだと思います．

で，今はもっとリソースがジャブジャブしているので，
宣言的な方向によってもいいんじゃないかと思います．
完全に宣言的というのは，「並列」などというキーワー
ドが表に出てくるはずがなく，「型」もいらなく，
論理言語でいいんだと思います．
そんで，それを最新の実装技術と，ジャブジャブした
リソースでエイヤと動かす．

最適化は，問題が決まってからとか，
検索するキーワードが決まってからとか，
情報が付加されるいろんなタイミングで行われます．

2006年04月04日
19:39

ひとつだけ
＞論理型言語が成功した

論理型言語って成功したんですか？
何を持って成功したかというのはいろいろ基準があるでしょうが、論理型言語を使わないと実現できなかったシステムとかそういう応用例とかちょっと思い出せないですけど。

2006年04月04日
21:40

びすけっと

K-Prologはちゃんと今でも売れているんですよ．H14年は
約400本だそうです．お金を出して買った人たちですから，
ちゃんと仕事で使われているってことでしょう．フリーの
Prologもありますからね．

（前のコメントで「成功」といったのは当時のブーム
の理由と置き換えてもいいです）

あれ，きのさんは安斎さんのマイミクでしたよね．

2006年04月04日
21:50

>きのさんは安斎さんのマイミクでしたよね．

きのちゃんさん、つながっています。
http://mixi.jp/show_friend.pl?id=31602
なんとなく、人柄がprologですよね。

>ジャブジャブしたリソース

そうそう、だんだん何がききたかったがわかってきた。

チューリングマシンは最もプアーな万能計算機を想定したわけだけれど、逆に最もリッチな仮想計算機を考えて、無限の並列性と、即アクセス可能な無限の記憶があったとします。

そのマシンなら、たとえばある配列の値の総和を求めるのは必ず１ステップでできます。しかし、ライフゲームの挙動は絶対に１ステップでは求められない。

並列性と逐次性、非同期と同期の切り分けっていうのは、最適化の問題というより、もっと原理的なところにあるんじゃないかな。言語からマシン臭さを取り除いていっても、最後まで残るような。

2006年04月04日
22:33

＞ちゃんと仕事で使われているってことでしょう．
その辺詳しい話が知りたいんですよ。最近その辺の状況に疎いもので

無限の並列性があれば配列の総和って1ステップで計算できる
んでしょうかね？
加算が二項演算であることを考えると本質的に不可能な気が…
単に、実現方法が見つかっていないとかじゃなくて…
log nステップより短くするのは不可能じゃないかなぁ…

2006年04月04日
22:39

びすけっと

無限のメモリーというか，理想的なメモリーというのは
lispのことです．

無限のプロセスというのだと，プロセス代数というのが
あって，π計算というのがいい感じですね．ラムダ計算
の並行システム版．実装もあったはずですが，役に立た
ないと思います．こういう思考実験に必要な考え方．

ここからプログラミング言語に繋げるには，論理式から
論理型言語につなげたような，活気的な飛躍が必要で，
いまどんな状況なんだろう．上田さんのエレメンタルっ
てそれを狙ってたのかもしれないです．
追いきれてないです．

2006年04月04日
22:43

配列の現在の状態がみんな見えているんだから、それが総和という「数」を一意的に表しているでしょう。それを整数にするのは変換の問題で。
別な言い方をすると、ＣＰＵの内部のデータ長が有限で二項演算しかできないから、ステップを必要とする。

2006年04月04日
22:53

http://www.ueda.info.waseda.ac.jp/~ueda/pub/LMNtal-prosym.pdf

LMNtal、面白げですね。じっくり読んでみよう。

2006年04月04日
22:57

http://banon.ueda.info.waseda.ac.jp/~n-kato/papers/LMNtal-cs0403.pdf

こっちだ。

2006年04月04日
22:59

＞ＣＰＵの内部のデータ長が有限で二項演算しかできないから

いやそうではなくて、加算というのは数学的定義が二項演算だということでハード的な制約を考えているわけではないですよ。
実装のことを考えるなら3項でも4項でも加算回路は設計できますよ。（回路の遅延はやっぱりlog nのオーダーで増えそうですが）

＞それを整数にするのは変換の問題で
この変換を1ステップで可能な形で定義可能あるいは記述可能かどうかがこの議論の本質的なポイントなわけで、現在の状態が見えていれば１ステップで答えが出せるということが真ならば、それはライフゲームでも同じはずですよね。

2006年04月04日
23:06

総和とライフが違うのは、計算が不簡約かどうかじゃないでしょうか。総和は初期データからただちに結果が見えている。ライフはあるプロセスをかならず経ないと見えない。

2006年04月04日
23:09

１ビットデータ長の１０個のデータの総和を計算する装置を作るのに、クロックはいらない。だからどんなデータ長のどんな配列の総和を計算する装置にもクロックはいらない。
ライフはかならずクロックを要する。とも言い換えられる。

2006年04月05日
19:00

はらこさんが混乱している理由がわかった。
ライフゲームは、パターンの変化がリミットサイクル（グライダーを含む）に入ったら停止で、ある初期状態が停止するかどうかという問題である、という定義を明示する必要がありますね。これは計算的に簡約化不可能で、総和の問題と本質的に違うわけです。

2006年04月20日
19:39

研究室が隣のsoftpadさんが何となく『TURBO GRAPHICS』という本を持ってきました。奥付を確認するとJICC出版局1987年4月10日初版第一刷発行でした。６章の「アルゴリズムをもった筆」というのが今のカンブリアンにも共通する問題意識を感じれました。これがどうやら安斎さんの２番目の著作らしい。

2006年04月20日
21:25

共著者の小林さんは
http://mixi.jp/show_friend.pl?id=80202
その当時まだ小学館の編集者だったので、他社の本を書くために偽名、じゃなくてペンネームでした。
イラストはるじるしさん
http://mixi.jp/show_friend.pl?id=45581
フォマールさんの目に触れて、本にとってラッキーでした。
時間があったら、現行の処理系に移植して、改訂したいところです。この本を読んでＣＧをはじめた人や、ペイントシステムを作り始めた人が何人もいるようです。

2006年04月21日
02:21

懐かし嬉しい話ですねえ。
ぼくもねえ、小学館からジャストシステムに移ったら、そのころ「花子」というグラフィックスのシステムを開発していたエンジニアが「ターボグラフィックス」を持っていた。「花子」にも、「ターボグラフィックス」のミトコンドリアが継承されていたりしてね。
その後、複雑系の議論とか、最近ではグリッドコンピューティングとかの話題が世間を賑わすことがあっても、ちょっとおこがましい言い方だけれど、思想的には、「マンデル貧乏」おっと「マンデルネット８６」と「ターボグラフィックス」でやっちゃった、みたいなところがあってね。今でも決して古くなっていない、という自負はある。
ぢゃあ、いま、あの本が書けるかと言ったら、もう書けないだろうなあ。体力的にも。

2006年04月21日
03:45

安齋先生に教えられてここにたどり着きました。
僕の人生を変えた「あの本」のお二方にこんなに身近にお会いできるとは！(ネット上で、ですが)

はい、今でも講義のネタに行き詰った時には『TURBO GRAPHICS』にお世話になっております。

2006年04月24日
11:35

>「マンデル貧乏」おっと「マンデルネット８６」と「ターボグラフィックス」でやっちゃった、

そうなんですよ、誰も言ってくれないから僕らで自画自賛していくしかないんだけど、早すぎたんでしょうね。

>もう書けないだろうなあ。体力的にも。

いやぁ、そんなことないって。グループサウンズ再結成じゃないけど、またいっしょに本書きましょう。

2006年04月24日
11:38

softpadさん、つい先日幸村さんの個展に行きました。時間がなくて素通りしましたが、今度中京大学に行くときにはお会いしたいですね。

2006年04月24日
14:37

ぜひお願いします！

　安斎利洋mixi日記　一覧へ　