今年はこれでおしまいだからって、まだまだCOMFRKは終わりません。
だからこれはCOMFRK VOL.3 Advent Calendarの記事。
みなさんエミュレータとシミュレータの区別は付きますか？
こっちがエミュレータで、こっちはシミュレータです。計算機のエミュレータはよく見掛けますが、計算機のシミュレータはどうでしょう？これとかがそうですね。
COMFRKも毎回記事集めやネタ出しに苦労しているので、今回から連載を始めることにしました。連載を通しての題材は、そう計算機のシミュレータを作っていこう！です。これはその一回目。
12.29.2011
COMFRK VOL.3 Advent Calendar 2
忘れてたわけじゃないけれど、忘れていることを忘れていただけです。
だからこれはCOMFRK VOL.3 Advent Calendarの記事。
プログラマは大きく分けてREALな型とINTEGERな型に分けられるのは皆さんよくご存知ですね？INTEGERなプログラミングと比較してREALな方は泥くさい部分が少なくありません。もちろん両者は互いに手を取り合うべき存在なわけですが、ことREALな方は計算機の上で論理的に考えるよりも、黒板の前で筋肉を弾ませることを好むため、なかなか上手くいきません。
そんなREALなプログラミングの四方山話…
だからこれはCOMFRK VOL.3 Advent Calendarの記事。
プログラマは大きく分けてREALな型とINTEGERな型に分けられるのは皆さんよくご存知ですね？INTEGERなプログラミングと比較してREALな方は泥くさい部分が少なくありません。もちろん両者は互いに手を取り合うべき存在なわけですが、ことREALな方は計算機の上で論理的に考えるよりも、黒板の前で筋肉を弾ませることを好むため、なかなか上手くいきません。
そんなREALなプログラミングの四方山話…
12.25.2011
COMFRK VOL. 3 Advent Calendar
今年は出ないかと思われた(思った)COMFRKですが、出る(出す)ようです。
だからこれはCOMFRK VOL.3 Advent Calendarの記事。
突然ですがProlog復興会議準備会というイベントがあります！
twitter-id: TakaoOzaki=サンというPrologに対し並々ならぬ愛情をお持ち(のように見受けられる)方が主催で、twitter-id: Nikoriks=サンというこれまたPrologに対して多大な貢献をされている方もいらっしゃるようです。Prologに関心があれば参加して損は無いんじゃないかしら？
ところで皆=サンにとってProlog=サンって何でしょうか？たぶん多くの人にとって思うようにならないニクい奴って感じなんじゃないですか？僕は一時期ですが真面目な交際をしていました。結局この関係は長続きせず、今はまあ友達以上、恋人未満、むしろ友達です。そもそも僕が講義をサボっていたら偶然出会った先輩、それがProlog=サンなんです。青春ですね。
そんなProlog=サンの良い面や可能性を集めてファンブックを作ろうかと思ったんですが、そういうペーパーはかつて山のように書かれていたし今更おもしろく無いなと気付きました。だから今回は、ちょっと気恥しいんだけどProlog=サンと僕の思い出について書いてみます。青臭いです。正直なところ書くのが辛い。だけど僕はもう大人なんだから一度ケリを着けなきゃいけない…、そう考えて突き通しました。
というわけでCOMFRK VOL.3ではPrologと僕の青春の何ページかを書きます。
だからこれはCOMFRK VOL.3 Advent Calendarの記事。
突然ですがProlog復興会議準備会というイベントがあります！
twitter-id: TakaoOzaki=サンというPrologに対し並々ならぬ愛情をお持ち(のように見受けられる)方が主催で、twitter-id: Nikoriks=サンというこれまたPrologに対して多大な貢献をされている方もいらっしゃるようです。Prologに関心があれば参加して損は無いんじゃないかしら？
ところで皆=サンにとってProlog=サンって何でしょうか？たぶん多くの人にとって思うようにならないニクい奴って感じなんじゃないですか？僕は一時期ですが真面目な交際をしていました。結局この関係は長続きせず、今はまあ友達以上、恋人未満、むしろ友達です。そもそも僕が講義をサボっていたら偶然出会った先輩、それがProlog=サンなんです。青春ですね。
そんなProlog=サンの良い面や可能性を集めてファンブックを作ろうかと思ったんですが、そういうペーパーはかつて山のように書かれていたし今更おもしろく無いなと気付きました。だから今回は、ちょっと気恥しいんだけどProlog=サンと僕の思い出について書いてみます。青臭いです。正直なところ書くのが辛い。だけど僕はもう大人なんだから一度ケリを着けなきゃいけない…、そう考えて突き通しました。
というわけでCOMFRK VOL.3ではPrologと僕の青春の何ページかを書きます。
11.09.2011
ぼくがかんがえたさいきょうの10さつ
@natsutanさんが言ってたから考えました。数値計算篇。
1. 数値計算の常識
計算機の小数点と数学の実数は全く別物だということを忘れがち。
また所詮近似だからと言って誤差が野放しだと思っても大間違い。
過大評価も過少評価もいけません。
本当の数値計算のはなしをしよう..
2. HP-15C Advanced Functions Handbook
基本を押さえたら実践、の前に歴史から学ぼう。
HP-15Cという古の名機を手に、限られた資源の使い方を知る。
ちなみにこっちが本機のマニュアル。
3. Modern Fortran Explained
過去だけに囚われていては人類は進歩しない！
現代を生きよう、これが明日から諸君の武器となる。
Fortran2008に準拠した言語詳説。
配列演算も演算子オーバーロードもローカルビューもアリだ。
4. Fortran 77 応用ソフトウェア作成技法
これで準備は整った、戦争だ！と思った貴様は甘い！！
何故この時代にFortranがあるのかを少しは考えてみろ。
過去の遺産があるから仕方無くに決まってるだろうが！
静的解析が容易？Cと比較すればそうだろう..
だがな！だったらどうして強い型付けの関数型言語でない？
諸君の仕事がたとえ現代兵器でなされようとも、
戦場は弓矢や落とし穴といったベトコン仕込みの罠で一杯だ。
だからリストやツリーのデータ構造がどう定義出来るかなんて話じゃなく、
どうDOするのかってことを身体で憶えるんだ。
5. Theoretical Numerical Analysis
悪い兵士は居ない。居るのは馬鹿な指揮官だ。
武器や技術が幾ら凄かろうと正しい判断が伴わなければ無意味だ。
生き残りたければ各自が有能な指揮官となって戦わねばならん！
プログラムの意味論が領域理論やラムダ計算を基礎とするように、
数値計算もまた線形代数と関数空間を基礎としていることを知れ。
6. Numerical High Performance Computers
ようこそ戦場へ！！だがまだここは前線じゃない。
諸君にはこれより奥地の湿地帯で展開している部隊に物資を届けてもらう。
まずは我々がこれまでどのようにこの地で戦ってきたかを知ってもらおう。
7. Iterative Methods for Sparse Linear Systems
ヒーホー撃てば当たるぜ！！ここじゃあ何でもヤったモン勝ちよお！
新しい関数系や補間法、補空間なんでも構わねぇ、試せばザッツライト。
大体は何かに当たるからそれでオールクリアだ畜生めっ！！
8. Direct Methods for Sparse Linear Systems
よくここまで辿り着いたな、物資は確かに受け取った。礼を言うぞ。
諸君の勇気をたたえ、ここは一つとっておきの武器をくれてやろう。
コイツを使えば原理的にはどんな敵も倒せる、計算機が十分タフならな。
後方の奴らはこんなもん使えないとほざきやがるがそんなことはない。
コイツこそが使えるんだ！上手く使えば幾らだって速くなる！
では敵地に単独潜入している人物にこの封筒を届けてくれ。検討を祈る。
9. Graph Algorithms in the Language of Linear Algebra
オットあぶないぜ兄ちゃん、もう一歩で竹ヤリが飛び出してくらぁ。
ここは四方敵だらけの未踏の地さ、味方は他にゃあ居ないぜ。
フムなるほど、情報ありがとよ。
礼と言っちゃあなんだが、ここで知ったことを教えるよ。
グラフを線形代数で考えるんだ。
場合によっちゃあ必要なメモリサイズやアクセスパターンが分かる。
いつか役に立つかも知れねぇよ。
10. スーパーコンピュータを20万円で創る
そして伝説へ..
どうしてこうなった？
もっとFEMとか流行の粒子法とか方法論をカバーすれば良かったかも。
あと数値計算で大事な非線形へのアプローチとか。
数値計算と言えばNumerical Recipesも原著3版は良くなってるらしいです。
ただ個人的にああいったカタログみたいなの薦めるのは気が引けます。
基礎を知らないと、式を追ったところでよく分からないと思うので。
1. 数値計算の常識
計算機の小数点と数学の実数は全く別物だということを忘れがち。
また所詮近似だからと言って誤差が野放しだと思っても大間違い。
過大評価も過少評価もいけません。
本当の数値計算のはなしをしよう..
2. HP-15C Advanced Functions Handbook
基本を押さえたら実践、の前に歴史から学ぼう。
HP-15Cという古の名機を手に、限られた資源の使い方を知る。
ちなみにこっちが本機のマニュアル。
3. Modern Fortran Explained
過去だけに囚われていては人類は進歩しない！
現代を生きよう、これが明日から諸君の武器となる。
Fortran2008に準拠した言語詳説。
配列演算も演算子オーバーロードもローカルビューもアリだ。
4. Fortran 77 応用ソフトウェア作成技法
これで準備は整った、戦争だ！と思った貴様は甘い！！
何故この時代にFortranがあるのかを少しは考えてみろ。
過去の遺産があるから仕方無くに決まってるだろうが！
静的解析が容易？Cと比較すればそうだろう..
だがな！だったらどうして強い型付けの関数型言語でない？
諸君の仕事がたとえ現代兵器でなされようとも、
戦場は弓矢や落とし穴といったベトコン仕込みの罠で一杯だ。
だからリストやツリーのデータ構造がどう定義出来るかなんて話じゃなく、
どうDOするのかってことを身体で憶えるんだ。
5. Theoretical Numerical Analysis
悪い兵士は居ない。居るのは馬鹿な指揮官だ。
武器や技術が幾ら凄かろうと正しい判断が伴わなければ無意味だ。
生き残りたければ各自が有能な指揮官となって戦わねばならん！
プログラムの意味論が領域理論やラムダ計算を基礎とするように、
数値計算もまた線形代数と関数空間を基礎としていることを知れ。
6. Numerical High Performance Computers
ようこそ戦場へ！！だがまだここは前線じゃない。
諸君にはこれより奥地の湿地帯で展開している部隊に物資を届けてもらう。
まずは我々がこれまでどのようにこの地で戦ってきたかを知ってもらおう。
7. Iterative Methods for Sparse Linear Systems
ヒーホー撃てば当たるぜ！！ここじゃあ何でもヤったモン勝ちよお！
新しい関数系や補間法、補空間なんでも構わねぇ、試せばザッツライト。
大体は何かに当たるからそれでオールクリアだ畜生めっ！！
8. Direct Methods for Sparse Linear Systems
よくここまで辿り着いたな、物資は確かに受け取った。礼を言うぞ。
諸君の勇気をたたえ、ここは一つとっておきの武器をくれてやろう。
コイツを使えば原理的にはどんな敵も倒せる、計算機が十分タフならな。
後方の奴らはこんなもん使えないとほざきやがるがそんなことはない。
コイツこそが使えるんだ！上手く使えば幾らだって速くなる！
では敵地に単独潜入している人物にこの封筒を届けてくれ。検討を祈る。
9. Graph Algorithms in the Language of Linear Algebra
オットあぶないぜ兄ちゃん、もう一歩で竹ヤリが飛び出してくらぁ。
ここは四方敵だらけの未踏の地さ、味方は他にゃあ居ないぜ。
フムなるほど、情報ありがとよ。
礼と言っちゃあなんだが、ここで知ったことを教えるよ。
グラフを線形代数で考えるんだ。
場合によっちゃあ必要なメモリサイズやアクセスパターンが分かる。
いつか役に立つかも知れねぇよ。
10. スーパーコンピュータを20万円で創る
そして伝説へ..
どうしてこうなった？
もっとFEMとか流行の粒子法とか方法論をカバーすれば良かったかも。
あと数値計算で大事な非線形へのアプローチとか。
数値計算と言えばNumerical Recipesも原著3版は良くなってるらしいです。
ただ個人的にああいったカタログみたいなの薦めるのは気が引けます。
基礎を知らないと、式を追ったところでよく分からないと思うので。
8.04.2011
Realtek8192se on Linux 2.6.40-
Kernelアップデートしたら蟹のWirelessドライバが刺さった。
TSFタイムスタンプをMPDU(MAC Protocol Data Unit)の先頭で与える事を示すためにRX_FLAG_TSFTを使っているのが(意図が不明瞭で)ダメらしい。これはRX_FLAG_MACTIME_MPDUに置き換えなさいとのこと。
以上のことは別に最近の話では無いみたいだけどRealtekにあるドライバには反映されていない。少くとも8192seは。まぁすぐに修正されるだろうけど。
TSFタイムスタンプをMPDU(MAC Protocol Data Unit)の先頭で与える事を示すためにRX_FLAG_TSFTを使っているのが(意図が不明瞭で)ダメらしい。これはRX_FLAG_MACTIME_MPDUに置き換えなさいとのこと。
以上のことは別に最近の話では無いみたいだけどRealtekにあるドライバには反映されていない。少くとも8192seは。まぁすぐに修正されるだろうけど。
2.13.2011
2.03.2011
NAMIKI 2
| 6 | 27 |
|---|---|
| 7 | 12 27 42 47 |
| 8 | 10 10 27 40 42 54 |
| 9 | 27 57 |
| 10 | 42 |
| 11 | 17 42 |
| 12 | 17 42 |
| 13 | 17 42 |
| 14 | 17 52 |
| 15 | 17 33 42 |
| 16 | 17 42 42 |
| 17 | 17 42 |
| 18 | 17 37 57 |
| 19 | 14 22 37 |
| 20 | 07 22 47 |
| 21 | 12 42 |
| 22 | 07 32 |
12.29.2010
この先生きのこるTLS
C++ Advent Calendar jp 2010の記事です。
並列性の導入に伴うメモリモデルの変更についてCryoliteさんが丁寧な説明を書いてくれてますから是非読みましょう。時代は並列です。それもマルチホストやマルチノードではなくて、共有メモリ型のマルチプロセッサ(マルチコア)です。ふらっと電器店に入ったパウリ体質の親父さんが4-core(論理)マシンを数万円で手に入れてしまえるわけですから、並列性を考えてプログラミングしないわけがありません。
ところで並列ってどうして必要なんですか？パフォーマンスです。一口にパフォーマンスと言ってもMan-Machine Interactionの応答パフォーマンスから、CAEシミュレーションや健康診断の結果待ちまで色々なものがありますが、回路の遊び時間を減らし、処理の待ちを減らそうというのが基本的なモチベーションです。
だからおまえはまずlock-freeな実装を考えるんだ!待たせるな!!そういうわけでyamasaさんの記事を読みましょう。
それで僕です。みんなちょっと待て、C++0xで明日の生活を支えることは難しいぞ。だから今日は、昨日から使えていたC++0xの機能Thread-Local Storage(以下TLS)のお話です。
まずTLSって何かと言うと、スレッド毎に個別に持ってるストレージです、まんまだけど。コレどうして要るのかって言うと、スレッド毎にスタックがあるんだからソッチで持ってよ!!とかそういう単純な話です。
「おいィ？メモリ空間共有してるのがスレッドのメリットだろ。
なんでプロセスみたいな事するんだ!？」
それは一理あるんですけれど残り九十九理はないですね。おまえはコピー持つなら必ずフォークするのかとかそういう。で、使い方なんですけどとても簡単です。TLSとして扱いたいデータ(PODに限る)に thread_local と付けるだけです。あとまあPODじゃないと困るとかいうのは、それこそCryoliteさんの記事よく読みましょう。
ちなみにC++0xではthread_localですけど、大抵の処理系で以前からサポートされています。!!yamasa さんから指摘頂きましたが、C++0x以降はPODでない変数もTLSとなる(N3225 3.7.2 Thread storage duration参照)ので以下の内容はC++0x以前の話です。!!
それで実際(僕が)よく見るケースなんですけど、こんな感じのコードがあって..
これでfuncのcallerをOpenMP化したい時とか困りますよね。しかもfuncが1つや2つじゃなくていーっぱいあると、ほんとヤダなーって感じです。でもhogeはPODじゃないんで(!!C++0x以前だと!!)TLS化出来ないんですよ。かと言ってhogeを触ってるところ全てでlockしてたらヤバい、遅くて死ぬ。しかし並列版funcを用意する気がとても起きない(or優先順位が低い)。そんな時はこうすると良いですね。
まあ別に面白いコードでも何でも無い。だがこれでこの先生きのこることができる。精々明後日までだろうが..
ところでこれからのクラス設計という観点ではcoiledcoilさんの記事など参考になりますね、読みましょう。!!それからC++0xでTLSばんじゃ〜いしても、コンストラクタにロックなんて無いから安心して心配しろ、泣くぞ(3.6.2 Initialization of non-local variables参照)!!
それでは次の方、良いお年を。
並列性の導入に伴うメモリモデルの変更についてCryoliteさんが丁寧な説明を書いてくれてますから是非読みましょう。時代は並列です。それもマルチホストやマルチノードではなくて、共有メモリ型のマルチプロセッサ(マルチコア)です。ふらっと電器店に入ったパウリ体質の親父さんが4-core(論理)マシンを数万円で手に入れてしまえるわけですから、並列性を考えてプログラミングしないわけがありません。
ところで並列ってどうして必要なんですか？パフォーマンスです。一口にパフォーマンスと言ってもMan-Machine Interactionの応答パフォーマンスから、CAEシミュレーションや健康診断の結果待ちまで色々なものがありますが、回路の遊び時間を減らし、処理の待ちを減らそうというのが基本的なモチベーションです。
だからおまえはまずlock-freeな実装を考えるんだ!待たせるな!!そういうわけでyamasaさんの記事を読みましょう。
それで僕です。みんなちょっと待て、C++0xで明日の生活を支えることは難しいぞ。だから今日は、昨日から使えていたC++0xの機能Thread-Local Storage(以下TLS)のお話です。
まずTLSって何かと言うと、スレッド毎に個別に持ってるストレージです、まんまだけど。コレどうして要るのかって言うと、スレッド毎にスタックがあるんだからソッチで持ってよ!!とかそういう単純な話です。
「おいィ？メモリ空間共有してるのがスレッドのメリットだろ。
なんでプロセスみたいな事するんだ!？」
それは一理あるんですけれど残り九十九理はないですね。おまえはコピー持つなら必ずフォークするのかとかそういう。で、使い方なんですけどとても簡単です。TLSとして扱いたいデータ(PODに限る)に thread_local と付けるだけです。
thread_local int x; // おまえはスレッド毎に保持されるちなみにC++0xではthread_localですけど、大抵の処理系で以前からサポートされています。!!yamasa さんから指摘頂きましたが、C++0x以降はPODでない変数もTLSとなる(N3225 3.7.2 Thread storage duration参照)ので以下の内容はC++0x以前の話です。!!
+--------------------+--------------------+--------------------+
| GNU/Sun | Intel/MS | C++0x |
+--------------------+--------------------+--------------------+
| __thread | __declspec(thread) | thread_local |
+--------------------+--------------------+--------------------+
それで実際(僕が)よく見るケースなんですけど、こんな感じのコードがあって..
void func(int a) {
static Hoge hoge;
// 以下、数百行のナンバークランチが続く
}これでfuncのcallerをOpenMP化したい時とか困りますよね。しかもfuncが1つや2つじゃなくていーっぱいあると、ほんとヤダなーって感じです。でもhogeはPODじゃないんで(!!C++0x以前だと!!)TLS化出来ないんですよ。かと言ってhogeを触ってるところ全てでlockしてたらヤバい、遅くて死ぬ。しかし並列版funcを用意する気がとても起きない(or優先順位が低い)。そんな時はこうすると良いですね。
#define hoge _hogeLocal_()
thread_local Hoge *gl_hoge = static_cast<Hoge *>(0);
Hoge &_hogeLocal_() {
if (!gl_hoge) {
// LOCKしてnew
}
return *gl_hoge;
}
void func(int a) {
//static Hoge hoge;
// 以下、コードは弄らない
}
#undef hogeまあ別に面白いコードでも何でも無い。だがこれでこの先生きのこることができる。精々明後日までだろうが..
ところでこれからのクラス設計という観点ではcoiledcoilさんの記事など参考になりますね、読みましょう。!!それからC++0xでTLSばんじゃ〜いしても、コンストラクタにロックなんて無いから安心して心配しろ、泣くぞ(3.6.2 Initialization of non-local variables参照)!!
それでは次の方、良いお年を。
12.26.2010
COMFRK vol. 2
夏に引き続き冬も出しマス、そういうマスが発見されました。
を予定していますが、まだ編集を終えてないので必死です。
なお既刊はデジタル版(PDF)を COMFRK にて無料公開します。
名前: COMFRK新刊の内容は..
日時: 12/31(金) 三日目
場所: 東ヘ51a
内容: 新刊 COMFRK vol. 2
既刊 COMFRK vol. 1
価格: 各300円
- Prologressive Meta-ル by m0h1can
- なれる!?C++0x PG ～ムーブセマンティクス編～ by lyrical logical
- 至極簡単なメモリプール by cubicdaiya
- 型理論におけるパラドクス by ranha
- ATiの職人技が現代に息衝くこだわりGPGPU by m0h1can
- Game Seeker vol. 1&2 by mascalade
を予定していますが、まだ編集を終えてないので必死です。
なお既刊はデジタル版(PDF)を COMFRK にて無料公開します。
12.08.2010
プログラマが予約しておくべき本10冊
未だ無い本だからテキトーな事が書ける。大天才！
…まあつまり、自分が読みたい本のリストってことだ。
- Learn You a Haskell for Great Good! なんか表紙とタイトルがイカす。
- Modern Fortran Explained 今なお進化を続ける太古の言語Fortran.. その最新仕様2008を網羅する一冊！
- The C++ Programming Language 4th C++0x。
- PROLOG programming for Artificial Intelligence 4th Common LispでPrologを書くAI本はあるけど、PrologのAI本はまた違った味わいが.. 待望の最新版！
- Scientific Computing with Multicore and Accelerators 安心のドンガラ印。
- TAOCP vol.4 チャールズ・ストロスの小説だとTAOCPの四巻は永遠に(公には)出ないことになってたけど分冊出てるな。
- Finite and Algorithmic Model Theory 有限モデル理論をアルゴリズムに応用云々と言えば…そうNP問題のアノ論文。
- プロセッサを支える技術 安心のHisa Ando印。
- 丸ごと型理論の本 誰かが書くハズ。
- COMFRK vol. 2 がんばって書く。
…まあつまり、自分が読みたい本のリストってことだ。
8.30.2010
8.29.2010
C78おつかれさまでした
http://comfrk.info/
ギリギリまで仕事で、学部時代の実験レポートを思い出させる過酷な作業の末、関係各位の協力によって前日の夜八時頃に無事製本を終えた50部の創刊号たちは、この訳が分からない雑誌だれ得ですか？という予想とは裏腹に、午後1時を待たずして完売してしまうという…
次は既刊とVOL.2を予定しておりますのでよろしくお願いします。
VOL.2予告
あと執筆者は随時募集しております。巻頭漫画の枠がまだ空いているので漫画が描ける人を強く希望します！！
ギリギリまで仕事で、学部時代の実験レポートを思い出させる過酷な作業の末、関係各位の協力によって前日の夜八時頃に無事製本を終えた50部の創刊号たちは、この訳が分からない雑誌だれ得ですか？という予想とは裏腹に、午後1時を待たずして完売してしまうという…
次は既刊とVOL.2を予定しておりますのでよろしくお願いします。
VOL.2予告
- エヴェレット解釈によると、我々の宇宙と平行してC++0xの別の仕様が存在するという…。そこではConceptが生き残っていた！？
- メタプログラミングRubyという本が売れているそうなので、メタプログラミングPrologという本も売れるんじゃないですかね？
- ???
あと執筆者は随時募集しております。巻頭漫画の枠がまだ空いているので漫画が描ける人を強く希望します！！
8.01.2010
COMFRK vol. 1
紆余曲折あって今年は転職した私ですが、それとは何の関係も無くC78にサークル参加します。既に売り子は確保出来ていますいませんが、コスプレして手伝いたいというヴァーチャルな方がおられましたら twitter-id: m0h1can までDM下さい。
名前: COMFRK
日時: 8/14(土) 二日目
場所: 東ア47a
内容: 雑誌1部 COMFRK vol. 1
価格: 300円
何気にまだ確定してない記事があって編集長としては心穏やかではないのですが、少くとも創刊号が落ちることは無さそうです…
1. 夏休み子供λ相談室 by ranha
2. Haskellコミュニティ探訪 - 処理系とライブラリを中心にして - by shelarcy
3. 差分のアルゴリズム by cubicdaiya
4. メインメモリアクセスマニュアル by nish
5. C++0xの空、Variadic Templatesの夏 by lyrical logical
6. PrologでSchemeの操作的意味論を実装 by zick
7. ゲームオーバーのすゝめ by mascalade
当日はranhaさんがウェイトリー家に生まれた双子の子供のうち異次元の血が濃い方のコスプレをするそうなので、深きものどもとか来ると良いよ。
名前: COMFRK
日時: 8/14(土) 二日目
場所: 東ア47a
内容: 雑誌1部 COMFRK vol. 1
価格: 300円
何気にまだ確定してない記事があって編集長としては心穏やかではないのですが、少くとも創刊号が落ちることは無さそうです…
1. 夏休み子供λ相談室 by ranha
2. Haskellコミュニティ探訪 - 処理系とライブラリを中心にして - by shelarcy
3. 差分のアルゴリズム by cubicdaiya
4. メインメモリアクセスマニュアル by nish
5. C++0xの空、Variadic Templatesの夏 by lyrical logical
6. PrologでSchemeの操作的意味論を実装 by zick
7. ゲームオーバーのすゝめ by mascalade
当日はranhaさんがウェイトリー家に生まれた双子の子供のうち異次元の血が濃い方のコスプレをするそうなので、深きものどもとか来ると良いよ。
12.31.2009
The End of 2009
コミケから帰ってきて身体がクタクタだし大掃除が出来なかったしお腹へったしシュタインズゲートをやれなかったしロクでもありませんね。じゃあ今年は何がロクだったかなと振り返ってみたところ、SchwartzのDistributionやScattering Theoryが使えるようになったのは良かったなと思いますね。そして今年も佐藤超関数は理解できなかった…。とりあえず岡潔の多変数関数論を読み始めたので、来年は何とかしたい…。
そうそう、今年は仕事を辞めた一年になったので、来年は仕事を始めた一年になると良いですね。欲を言えば、仕事をせずに暮せた一年になるほうがもっと良いですけど。
そうそう、今年は仕事を辞めた一年になったので、来年は仕事を始めた一年になると良いですね。欲を言えば、仕事をせずに暮せた一年になるほうがもっと良いですけど。
12.27.2009
Reading The Craft of Prolog
The Craft of Prologを読んでProlog的テクニックを学ぼうという集りがありました。
高等魔術の教理と祭儀
当日つかったスライドです。本を読む上で道案内になれば幸いです。
スライドを見ながら、あーだこーだらむだと話していると大体16時過ぎには終わってしまったので、後はかなり自由なトーキングセッションとなってしまい、ハイ、その辺は準備が不十分だったなーと痛感しています。ごめんなさい。
ranhaさんが、式は戻り値ほしーと言ってましたがPrologは記号処理をしたいのであって数値計算をしたいわけじゃないのでソレです。つまり、
ということになっていて、計算の開始を指示しているのはis/2述語です。導出が始まると+-*/などの演算子はラベルのようなもので、prim_add/3述語(これは仮想的な述語ですが)のような処理系のプリミティブにぶつかると値が決まるという感じです。is/2をユーザ定義で勝手に拡張しても良い(arithmetic_function/1などで追加出来ます)のですが、実際はisp/2やism/2などユーザ側で独自なis/2述語を定義します。多項式演算ライブラリなどの実装で使われる場合が多いです。
kinabaさんが穴のある構造を使ったのってもっと無いかなー、と言ってたのですが、それは僕も探しているので思い付いたら教えて欲しいです。
高等魔術の教理と祭儀
当日つかったスライドです。本を読む上で道案内になれば幸いです。
スライドを見ながら、あーだこーだらむだと話していると大体16時過ぎには終わってしまったので、後はかなり自由なトーキングセッションとなってしまい、ハイ、その辺は準備が不十分だったなーと痛感しています。ごめんなさい。
ranhaさんが、式は戻り値ほしーと言ってましたがPrologは記号処理をしたいのであって数値計算をしたいわけじゃないのでソレです。つまり、
?- X = 1 + 1.
X = 1 + 1.
?- X is 1 + 1.
X = 2.
:- op(500, xfy, +).
:- op(500, yfx, -).
C is A + B :- prim_add(A, B, C).
C is A - B :- prim_sub(A, B, C).
ということになっていて、計算の開始を指示しているのはis/2述語です。導出が始まると+-*/などの演算子はラベルのようなもので、prim_add/3述語(これは仮想的な述語ですが)のような処理系のプリミティブにぶつかると値が決まるという感じです。is/2をユーザ定義で勝手に拡張しても良い(arithmetic_function/1などで追加出来ます)のですが、実際はisp/2やism/2などユーザ側で独自なis/2述語を定義します。多項式演算ライブラリなどの実装で使われる場合が多いです。
kinabaさんが穴のある構造を使ったのってもっと無いかなー、と言ってたのですが、それは僕も探しているので思い付いたら教えて欲しいです。
12.24.2009
筑波にお年玉あらため落とし本
筑波というガイコクには、東京国と比べるとそれは酷い生活環境を強いられる恵まれない子が沢山居ると聞きました。だから僕は、お正月になったら筑波という隣のガイコクに行って、彼等には高くて手の出せないような本を恵んで、やがて彼等が筑波を豊かな国に出来る立派なオトナになる手助けをしたいと考えました。お返しに僕は、ランランという量がやたらと多い現地の食べ物をご馳走になろうと思います。
本当は部屋の本棚から本が溢れて仕方無いので本を譲りたいですが、面倒くさがり屋さんなので郵送なんかする気はありませんし、直接持って行くので欲しい人が居たら探して襲って奪って下さい。既に先約済みの本もあります。別にランランをご馳走しなく構いません。僕はオトナです。
シリーズ物その4が無いのは欠品ではなくて、そもそも発刊されて無いんです！どうしてこうなった…
日程: 2/1(月)
流れ: 午後に筑波に着いて、だらだら過ごして、夜RanRan食べて帰る
本当は部屋の本棚から本が溢れて仕方無いので本を譲りたいですが、面倒くさがり屋さんなので郵送なんかする気はありませんし、直接持って行くので欲しい人が居たら探して襲って奪って下さい。既に先約済みの本もあります。別にランランをご馳走しなく構いません。僕はオトナです。
- Effective C++ 3版 - y_benjoさん予約済み
- More Effective C++ 新訂版 - y_benjoさん予約済み
- Thinking Forth - Forthらしく考える本というより入門書
- Numerical Linear Algebra - 線形代数じゃなくて線形ソルバの本、割りと有名な著者だと思いますが、わりと平易な本でした
- シミュレーション物理学1 電磁気学 - シリーズ物その1
- シミュレーション物理学2 量子力学 - シリーズ物その2
- シミュレーション物理学3 力学 - シリーズ物その3
- シミュレーション物理学5 量子論 - シリーズ物その5
- シミュレーション物理学6 カオス力学入門 - シリーズ物その6
- モデルの理論 - ranha さん予約済み
- 逆数学と2階算術 - ranha さん予約済み
- 技術者のための高等数学1 常微分方程式 - 思い出したい事があって買ったけど立ち読みで良かった…、良書ではあるので若い学生さんに
- 技術者のための高等数学3 フーリエ解析と偏微分方程式 - 上に同じ
- 技術者のための高等数学4 複素関数論 - 上に同じ
- 技術者のための高等数学6 最適化とグラフ理論 - ranha さん予約済み
- …また後で増えます
シリーズ物その4が無いのは欠品ではなくて、そもそも発刊されて無いんです！どうしてこうなった…
日程: 2/1(月)
流れ: 午後に筑波に着いて、だらだら過ごして、夜RanRan食べて帰る
12.23.2009
Fourier on Hilbert
前回の続き
果たしてFourierの着想は妥当なものだったのでしょうか？得られた係数
と再構成された関数
から、これを確認してみましょう。
現代的な立場で言うと、これは丁度
の関数に限定した場合のみ有効です。係数を求めるのに使った正弦関数は
としてスケールすることで正規直交系
を構成し、フーリエ級数とフーリエ係数は次のように与えられます。
さて、Fourierはこの手法を一歩進めて次のように考えたのではないでしょうか。三角関数の周期を[0,π]に限定しなければ、より広い問題に適用できるのではないか？正弦関数による直交関係が有効であれば、余弦関数が有効な場合もあるのではないか？1807年にFourierは仏科学アカデミーに提出した論文において、積分区間[-π,π]で正弦関数と余弦関数を重ね合わせることで、関数の級数展開が可能であると述べます。つまり正規直交系として、
を選び、この関数が供える偶奇性
を利用して、次のような展開を得たのです。
この時、展開した係数は次で与えられます。
ここで現代的な見通しの為に少し表示を変えることにしましょう。先の直交系は
とまとめて書く事が出来ますから、直交関係は
となりますね。Fourierの対応は次のように改めましょう。
当時既にオイラーの関係式
は広く知られていましたが、これを使えば先程の正規直交系は
となります。直交関係はヒルベルト空間での内積を考えることで解決します。
これで複素領域まで広げたヒルベルト空間
の関数についてFourierの対応を述べることが出来ます。
ところでFourierは熱方程式を考えていた為に正規直交系として正弦関数を発見しましたが(Fourierの研究の後にRayleighも音に関する研究から余弦関数による展開を発見しています)、他の正規直交系は無いのでしょうか？工学の分野では有限要素法などで利用する直交系にLegendre多項式があります。関数列
からGram-Schmidtの方法を利用して直交した基底関数列を構成することが可能で、こうして得られた正規直交系
がLegendre多項式です。直交関係は直接計算によって
と確認できます。これを利用した場合にFourierの対応が有効な関数は
です。
to be continued..
果たしてFourierの着想は妥当なものだったのでしょうか？得られた係数
と再構成された関数から、これを確認してみましょう。現代的な立場で言うと、これは丁度
の関数に限定した場合のみ有効です。係数を求めるのに使った正弦関数はとしてスケールすることで正規直交系を構成し、フーリエ級数とフーリエ係数は次のように与えられます。さて、Fourierはこの手法を一歩進めて次のように考えたのではないでしょうか。三角関数の周期を[0,π]に限定しなければ、より広い問題に適用できるのではないか？正弦関数による直交関係が有効であれば、余弦関数が有効な場合もあるのではないか？1807年にFourierは仏科学アカデミーに提出した論文において、積分区間[-π,π]で正弦関数と余弦関数を重ね合わせることで、関数の級数展開が可能であると述べます。つまり正規直交系として、
を選び、この関数が供える偶奇性
を利用して、次のような展開を得たのです。この時、展開した係数は次で与えられます。
ここで現代的な見通しの為に少し表示を変えることにしましょう。先の直交系は
とまとめて書く事が出来ますから、直交関係はとなりますね。Fourierの対応は次のように改めましょう。当時既にオイラーの関係式
は広く知られていましたが、これを使えば先程の正規直交系はとなります。直交関係はヒルベルト空間での内積を考えることで解決します。これで複素領域まで広げたヒルベルト空間
の関数についてFourierの対応を述べることが出来ます。ところでFourierは熱方程式を考えていた為に正規直交系として正弦関数を発見しましたが(Fourierの研究の後にRayleighも音に関する研究から余弦関数による展開を発見しています)、他の正規直交系は無いのでしょうか？工学の分野では有限要素法などで利用する直交系にLegendre多項式があります。関数列
からGram-Schmidtの方法を利用して直交した基底関数列を構成することが可能で、こうして得られた正規直交系がLegendre多項式です。直交関係は直接計算によってと確認できます。これを利用した場合にFourierの対応が有効な関数はです。to be continued..
12.22.2009
First of all, start from Fourier
どの時代でも、今ある場所から見渡した世界は最も優れた装いをとるに違いありません。そしてしばしば、その美しい姿に欺かれ、形式という心地良い泥濘にはまって行くのです…。ですがもし、先人が知見を得たまさにその時の感動を知ることが出来たなら、今ある知識は実存としての強度を伴い、私たちの目に映ることでしょう。数学史というのはその為の手立てだと思うのです。
1807年、仏の数学者Joseph Fourierは当時目覚しい発展を続ける解析学において、とりわけ重大な、そして容易には受け入れ難い事実を発表します。フーリエ級数の発見です(有名な著書``熱の解析的理論''の発刊は1822年、Augustin-Louis Cauchyが当時の解析学の総決算と呼ぶべき著書``解析教程''をまとめたのは1821年のことです)。ヒルベルト空間に限定するなどの発想が無い当時、Fourierの手法は当然のことながら怪しげな技術として見做す数学者が多数存在しました。実際、収束性を議論していない式の項別積分に基づく彼の着想は、理論的には脆い基盤にありましたが、そういった冒険が世界を切り開いて来たことは歴史が教える通りです。
それではFourierはどのようにしてこの着想に至ったのでしょうか？
Fourierの取り組んでいた問題は、後の著書の題となるように熱の振舞いに関するものでした。ある均質な空間に初期状態として温度の分布が与えられたとき、任意の時間が経過すると分布はどのようになっているか？特に空間の境界に対して条件を課すことから、初期値-境界値混合問題と言われます。簡単の場合に述べますと、密度がρ、比熱をc、熱伝導率をkとする長さπの鉄棒が、時刻t=0において位置xの温度をf(x)として与えられた時、時刻0<tについてu(x,t)を求めよ、但しu(0,t)=u(π,t)=0とする、というものでした。ここで密度・比熱・熱伝導率を定数とし、k=cρとなるよう定めると、次のような問題となります。
当時、常微分方程式の解法については既によく知られていた為、Fourierはまず
として変数を分離した関数X(x)とT(t)に分けて考えました。これを元の偏微分方程式に代入するとことで、次のような線形斉次な微分方程式を得ます。
両辺がそれぞれ独立した変数の関数であることから、これは定数であることが分かります。これをλとしまし。そこで関数X(x)を求めることから始めます。
X(x)の一般解から次のようなλを求めれば良いことが分かります。
自明な場合を除けばλは
となるはずですから、オイラーの公式を使い
を得ます。よってλは
となり、定数は
という関係にあります。関数X(x)が求まりました。
次に、求まったλを使って関数T(t)が
と求まります。以上から問題の個々の解は次の関係に従うことになります。
ここで問題の偏微分方程式および境界条件の線形性より、任意の解の重ね合わせで元々の関数は表現出来るはずだと考えます。
次に初期条件
を考えることで、個々の解を実現する定数Cnを定める問題へと帰着することが出来ます。最終的な問題は次の通りです。
この問題を解く為に、Fourierは初めオイラーの手法を用いてx=π/2での展開を考えます。
ところが当時の技術ではこれによる定数の決定に困難が伴いました。またx=π/2という設定は、本来の問題を十分に満足させるものでもありません。試行錯誤の中でFourierは、両辺に
をかけ、それを積分するという着想を得ます。
正弦波の特性として
という関係に注目したFourierは、この形から項別の積分を定めることが出来ると思い付いたわけです。そして次のように定数を決定しました。
to be continued..
1807年、仏の数学者Joseph Fourierは当時目覚しい発展を続ける解析学において、とりわけ重大な、そして容易には受け入れ難い事実を発表します。フーリエ級数の発見です(有名な著書``熱の解析的理論''の発刊は1822年、Augustin-Louis Cauchyが当時の解析学の総決算と呼ぶべき著書``解析教程''をまとめたのは1821年のことです)。ヒルベルト空間に限定するなどの発想が無い当時、Fourierの手法は当然のことながら怪しげな技術として見做す数学者が多数存在しました。実際、収束性を議論していない式の項別積分に基づく彼の着想は、理論的には脆い基盤にありましたが、そういった冒険が世界を切り開いて来たことは歴史が教える通りです。
それではFourierはどのようにしてこの着想に至ったのでしょうか？
Fourierの取り組んでいた問題は、後の著書の題となるように熱の振舞いに関するものでした。ある均質な空間に初期状態として温度の分布が与えられたとき、任意の時間が経過すると分布はどのようになっているか？特に空間の境界に対して条件を課すことから、初期値-境界値混合問題と言われます。簡単の場合に述べますと、密度がρ、比熱をc、熱伝導率をkとする長さπの鉄棒が、時刻t=0において位置xの温度をf(x)として与えられた時、時刻0<tについてu(x,t)を求めよ、但しu(0,t)=u(π,t)=0とする、というものでした。ここで密度・比熱・熱伝導率を定数とし、k=cρとなるよう定めると、次のような問題となります。
当時、常微分方程式の解法については既によく知られていた為、Fourierはまず
として変数を分離した関数X(x)とT(t)に分けて考えました。これを元の偏微分方程式に代入するとことで、次のような線形斉次な微分方程式を得ます。両辺がそれぞれ独立した変数の関数であることから、これは定数であることが分かります。これをλとしまし。そこで関数X(x)を求めることから始めます。
X(x)の一般解から次のようなλを求めれば良いことが分かります。
自明な場合を除けばλは
となるはずですから、オイラーの公式を使いを得ます。よってλはとなり、定数はという関係にあります。関数X(x)が求まりました。次に、求まったλを使って関数T(t)が
と求まります。以上から問題の個々の解は次の関係に従うことになります。ここで問題の偏微分方程式および境界条件の線形性より、任意の解の重ね合わせで元々の関数は表現出来るはずだと考えます。
次に初期条件
を考えることで、個々の解を実現する定数Cnを定める問題へと帰着することが出来ます。最終的な問題は次の通りです。この問題を解く為に、Fourierは初めオイラーの手法を用いてx=π/2での展開を考えます。
ところが当時の技術ではこれによる定数の決定に困難が伴いました。またx=π/2という設定は、本来の問題を十分に満足させるものでもありません。試行錯誤の中でFourierは、両辺に
をかけ、それを積分するという着想を得ます。正弦波の特性として
という関係に注目したFourierは、この形から項別の積分を定めることが出来ると思い付いたわけです。そして次のように定数を決定しました。to be continued..
5.12.2009
Deux ou trois choses que je sais le calcul
「計算」という言葉について考えてみる
ranhaさんが計算とは"何か"を思索をされていて、その答えは恐らくまだ誰も分からないのだけど、計算機科学に携わる者だけでなく、およそ計算機に関わる誰もが心の中では、その"何か"を思っていることだと思う。だから私も個人的な"何か"を述べよう。
"何か"って既にあるのかしら、まだ無いのかしら？という点は考える余地があると思う。既にあるのなら、私達の思索という行為は遺跡の発掘のように、文字通り「既に」あって私達の思索という領域を支配している仕掛けを見つけ出す作業に他ならない。それは個人を超えて普遍的な仕掛けだろう。だがもしまだ無いのなら、私達の思索の領域は不可逆な経験を経る事で、橋を渡るようにして別の思索の領域に到達することになる。その経験を知識や概念と呼ぶのであれば、個人の思索は死によって頂点(或いは最大不動点)に達するのだろう。いずれにしろ物理法則へと、私達の思索は漸近する。いやしかし物理法則は、現象へと漸近させていくのが科学者の使命ではないか、、この話はよそう。その"何か"が既にあるか、或いはまだ無いか、ともかく時間を超越して存在を認めよう。
"何か"を語るとはどういう事か？と、自覚的に考えてみよう。その"何か"を理解する状況とはどのように可能なのか。三つ挙げてみる。
一つ目は、あるsyntaxを使って構成したモデルが"何か"だと述べる状況だ。これに従えば、計算機上のプログラムはTuring完全な言語であれば書くことが可能であり、そして書かれたプログラムだけが計算なのである。つまりは、その言語の中に留まる限りにおいて牧歌的な楽園が約束される。一体なにを心配する必要があろう、"その言語"で思うがままに計算をするが良い。だがやがてサピア・ウォーフ仮説の生き証人となるであろう。たとえバイナリこそが真実だと言ったところで、事態は変わらないのである。
二つ目は、syntaxと独立して"何か"が存在し、しかるべき形式でsyntaxへと埋め込まれる。従って、プログラムはその言語の構造との対応として現われる。だから私達は、ある"何か"が必ずまた別の姿形をして存在(対応)すると信じるのである。カリー・ハワード同型対応はその真理の一端である。であれば、大きな圏Cで同型対応τによる商圏C/τを考えることが"何か"への道かもしれない。
三つ目は、計算は存在などしない。私達は存在しないものについて、沈黙しなければならない。一方で存在するものはただ存在し、それを指して"何か"だと述べるのだ。だから私達は何の断りもなく、対象を認め、対象への算術を認め、再帰した算術を認め、任意のNについての再帰を認め、しかし無限を認めない。
「標準的自然数の定義」占い
こういったメタりっくな語り口を考えるなら、ここで挙げられている本が足掛りになるはずだ。でも幾らヘヴィにメタっても、私達が自由に使いたい"何か"との隔りは決して小さなものではないだろう。だって論理で見た代数はあまりに不恰好だから、、
"何か"によって私達はどう考えるのか？この答えは、あまりに私的過ぎる。論理的計算は証明プロセスを指すのであり、それはけっきょく記号操作だ(としか私は思わない)。また関数的計算も、形式がλ式であれ何であれ、やはり記号操作になる(としか私は思わない)。それらの言語"だけ"で考えている限り、それ以上の手立てを持ち合せてはいない。ところが計算する対象が見えると、舞台は関係と集合の世界に移る(だから小さな圏に限って議論すれば良いのだと云われたら、私は頷くかもしれない)。だが集合の海から関係の網を手繰り寄せることにも限界を感じるとき、チクタクと時を刻むオートマトンの世界が見えてくる。そこはもう工場のラインだ。算術回路の稼働率を上げるためにフローを組み変える日々、ふとラインの上に目をやると、流れてきたのは懐しきλ記号である、、
数学的には純粋な関係である関数も、計算として私達が意識するときは操作になる。歴史を紐解けば、超関数はおろか初等関数も長きに渡り厚いベールに包まれた存在であり、それらの扱いは一つの技術だった。関数というカラクリを分解し、論理という形で純化するに至る発端はFourierにあるだろう。Fourier級数の発見は「真理を読んだ」と語る程の衝撃を持っていた。やがて収束の神秘を紐解く過程で位相の概念が生まれ、微分操作を含んだより大きなクラスの作用素が構成されて行った。佐藤幹夫はアブストラクト・ナンセンスで記述した超関数を指して「実際にも計算できるよ」と言った、それが代数解析学となった。関数空間の理論は、黒魔術だった技術を計算機で構成可能な対象へと翻訳した。ここには確かに、概念が私達の思索の領域を広げた歴史を見てとることが出来る。私達の"何か"を、或いは計算機の"何か"を、黒魔術から構成的な対象へと翻訳する概念の発見を、一体誰が否定できようか？
逆数学と二階算術
ある数学的な活動を許す設定を探ることは逆数学として試みられている。いまある数学は二階算術によって十分に可能なのだそうだ(分類はもっと細かいけど)。
ちなみに、この話にオチは無いのだけど、、
ranhaさんが計算とは"何か"を思索をされていて、その答えは恐らくまだ誰も分からないのだけど、計算機科学に携わる者だけでなく、およそ計算機に関わる誰もが心の中では、その"何か"を思っていることだと思う。だから私も個人的な"何か"を述べよう。
"何か"って既にあるのかしら、まだ無いのかしら？という点は考える余地があると思う。既にあるのなら、私達の思索という行為は遺跡の発掘のように、文字通り「既に」あって私達の思索という領域を支配している仕掛けを見つけ出す作業に他ならない。それは個人を超えて普遍的な仕掛けだろう。だがもしまだ無いのなら、私達の思索の領域は不可逆な経験を経る事で、橋を渡るようにして別の思索の領域に到達することになる。その経験を知識や概念と呼ぶのであれば、個人の思索は死によって頂点(或いは最大不動点)に達するのだろう。いずれにしろ物理法則へと、私達の思索は漸近する。いやしかし物理法則は、現象へと漸近させていくのが科学者の使命ではないか、、この話はよそう。その"何か"が既にあるか、或いはまだ無いか、ともかく時間を超越して存在を認めよう。
"何か"を語るとはどういう事か？と、自覚的に考えてみよう。その"何か"を理解する状況とはどのように可能なのか。三つ挙げてみる。
一つ目は、あるsyntaxを使って構成したモデルが"何か"だと述べる状況だ。これに従えば、計算機上のプログラムはTuring完全な言語であれば書くことが可能であり、そして書かれたプログラムだけが計算なのである。つまりは、その言語の中に留まる限りにおいて牧歌的な楽園が約束される。一体なにを心配する必要があろう、"その言語"で思うがままに計算をするが良い。だがやがてサピア・ウォーフ仮説の生き証人となるであろう。たとえバイナリこそが真実だと言ったところで、事態は変わらないのである。
二つ目は、syntaxと独立して"何か"が存在し、しかるべき形式でsyntaxへと埋め込まれる。従って、プログラムはその言語の構造との対応として現われる。だから私達は、ある"何か"が必ずまた別の姿形をして存在(対応)すると信じるのである。カリー・ハワード同型対応はその真理の一端である。であれば、大きな圏Cで同型対応τによる商圏C/τを考えることが"何か"への道かもしれない。
三つ目は、計算は存在などしない。私達は存在しないものについて、沈黙しなければならない。一方で存在するものはただ存在し、それを指して"何か"だと述べるのだ。だから私達は何の断りもなく、対象を認め、対象への算術を認め、再帰した算術を認め、任意のNについての再帰を認め、しかし無限を認めない。
「標準的自然数の定義」占い
こういったメタりっくな語り口を考えるなら、ここで挙げられている本が足掛りになるはずだ。でも幾らヘヴィにメタっても、私達が自由に使いたい"何か"との隔りは決して小さなものではないだろう。だって論理で見た代数はあまりに不恰好だから、、
# the Group Axioms in FO
∀x,y. ∃z. ∀w. S(x,y,w)⇔w=z
∀x,y,z. ∃u,v. ∀w. S(x,y,u)∧S(u,z,w)∧S(y,z,v)→S(x,v,w)
∀x. S(x,e,x)
∀x. ∃y. S(x,y,e)
"何か"によって私達はどう考えるのか？この答えは、あまりに私的過ぎる。論理的計算は証明プロセスを指すのであり、それはけっきょく記号操作だ(としか私は思わない)。また関数的計算も、形式がλ式であれ何であれ、やはり記号操作になる(としか私は思わない)。それらの言語"だけ"で考えている限り、それ以上の手立てを持ち合せてはいない。ところが計算する対象が見えると、舞台は関係と集合の世界に移る(だから小さな圏に限って議論すれば良いのだと云われたら、私は頷くかもしれない)。だが集合の海から関係の網を手繰り寄せることにも限界を感じるとき、チクタクと時を刻むオートマトンの世界が見えてくる。そこはもう工場のラインだ。算術回路の稼働率を上げるためにフローを組み変える日々、ふとラインの上に目をやると、流れてきたのは懐しきλ記号である、、
数学的には純粋な関係である関数も、計算として私達が意識するときは操作になる。歴史を紐解けば、超関数はおろか初等関数も長きに渡り厚いベールに包まれた存在であり、それらの扱いは一つの技術だった。関数というカラクリを分解し、論理という形で純化するに至る発端はFourierにあるだろう。Fourier級数の発見は「真理を読んだ」と語る程の衝撃を持っていた。やがて収束の神秘を紐解く過程で位相の概念が生まれ、微分操作を含んだより大きなクラスの作用素が構成されて行った。佐藤幹夫はアブストラクト・ナンセンスで記述した超関数を指して「実際にも計算できるよ」と言った、それが代数解析学となった。関数空間の理論は、黒魔術だった技術を計算機で構成可能な対象へと翻訳した。ここには確かに、概念が私達の思索の領域を広げた歴史を見てとることが出来る。私達の"何か"を、或いは計算機の"何か"を、黒魔術から構成的な対象へと翻訳する概念の発見を、一体誰が否定できようか？
逆数学と二階算術
ある数学的な活動を許す設定を探ることは逆数学として試みられている。いまある数学は二階算術によって十分に可能なのだそうだ(分類はもっと細かいけど)。
ちなみに、この話にオチは無いのだけど、、
3.24.2009
I'M BACK..
休暇帰省のつもりが、連日ギリギリなスケジュールで疲れた。月曜は有給休暇とってたので安心して自堕落な一日を送るが、地元の風景を見た後の東京は、なんとも心が穏かでなく、電源を抜かれたアナログ回路のように出力が減衰していく感じだった、、
P大さ論会
行ってきた。三人以上で談合するのが無理な席にまわされ、昨今の談合非難は外食産業にまで影響しているのか！と戦々恐々としたが、あの人数で入るスペースが無かっただけだった(いっそ倍の人数があれば卓を占拠出来たのに)。
Nagiseさんが「昔はポリゴンを1つづつ云々」という話をしていて、そういえばラスタスキャンして描画するのに情報の持ち方や無駄描画を減らす若気の至り的アルゴリズム書いてたな等と思い出すも、つい最近も計算結果のキャッシュなどで割と似たような事をしていて進歩が無い、或いは俺って実はまだまだ若い。
ikegamiさんに「モデル理論に興味を持つとは反社会的な活動家なのではないか」と詰問され、自分は元々論理学など専門じゃありませんと自白し、続いて出されたカツ丼に背を押され、D加群のようなアプローチをモデル理論でやりたかったんですと涙ながらに供述した。
zickさんが「これをガ○ダムの回路に接続すれば出力性能が30%は向上する」と(マラソンで)酸素欠乏気味に旧式の携帯回路を出して来た。LISPが動いていたので、あの極貧メモリでGCを実現するとは、さすが○ニーの白い奴！と驚くも実機では未完成らしい。
h_iwkさんは象なのか魚なのか分からない彫刻の向こうに居て顔が分からず、しかし公務員であらせられること、プログラマをやっているわけじゃないことを知り、この怪しげな集りに参加するという奇抜な行動力はもしや革命家を検挙するための潜入捜査か？と恐怖したものの、情報政策について考えておられるそうで安心した。そもそも俺は革命家じゃないから公安を恐れる心配は無い。
alohakunさんはパートナーについて、その具合の良さだとかエコであるとかコイツなしでは駄目だとか、そんなノロケてるんだかデバッガの話なんだか分からないような事を話しておられたのでグリーンカレーを喰わせたら辛いと言っていた。喫茶店に移動後も「ワシのメモリ空間は無限大じゃあ」と豪語してデカいパフェをさらりと食べたのは驚きだった。
ranhaさんは何度も「ピーキャッスル」と連呼していたように思ったが、後から検索するときにPCASLだとちっともHITしなかったので「ピーキャストル」と言っていたのかもしれない。それはともかくフルスクラッチが大好きそうだったので、きっと高級言語か何かの専用プロセッサを作ってくれるはずだ。冀わくば、それがPCASTL専用マシンではありませんように。
二次会では第五世代話から言語と環境についてパネルディスカッションが行われたわけだが、"マイナー言語を流行らせるためにそのN"が応用ありきという、大型計算機の世界で何度も繰り返された結論に至ったのが何だかなのだが、MacOSX/iPhoneのObjective-CはNeXTSTEPの頃のアカデミックな運動の絡みでGCCに入っていた点が優位だったんじゃないかなと帰りに思った。つまり最終的な応用の前にやるべき事が沢山あって、それを地道にクリアしておかないと出オチするというか、、要素技術はある程度枯らして主題から降ろさないと、、
Prologの理論面の話が出たような出なかったような気がするけど、CommonLispよりは理論家(の割合)が多い気がする*要出典*、というのはそれが論理を扱っているからだろうとは思う。Prologの場合、新しい拡張だとかが実装される時というのは、同時にそれを説明する理論も一緒も提案されて、それが既存の公理系で扱えるのか、扱えないならどう違うのかが説明されるから。あの場で言った真偽の順序と計算の順序を合わせたbilatticeを述語のモデルに採用し、これのproductに対する代数演算がPrologプログラムの意味論として簡単で整合性がある云々は、NAFの扱い方の"一つ"だが他にもあるわけで。あとモジュールシステムの拡張でも同じようなモデルが使えて、この時は極小モデルがいつまで安定かみたいな保証を行ったと思う。
それとFortranでOOなコードを書くと遅いと言ったのは、今もそうなのか自信が無いです。単純に投入されて来た人的リソースの問題かもしれない。ただOOな作りだとプリロード命令をどこで入れると効果的かとか厄介だと思う。どれもこれもインラインという話ではないのだし、大域書換えな最適化が必要になるハズ、だと思う。それでこの下のレイヤというか命令セットの部分をどれだけ使い倒すかという話がメインの世界で、言語ってその為のディレクティブみたいなものだから、Fortressは高級だからというより焦点が合っていない感じがするのでした。数学そのままに書けるとかより、人が面倒見なくても良い塩梅になるディレクティブが欲しいとかがHPCらしい。それが出来たら次は数学っぽく書きたくはなるだろうけども。
ところで不覚にもコレを完全に忘れていた、誰かPrologで同人誌にしませんか？
P大さ論会
行ってきた。三人以上で談合するのが無理な席にまわされ、昨今の談合非難は外食産業にまで影響しているのか！と戦々恐々としたが、あの人数で入るスペースが無かっただけだった(いっそ倍の人数があれば卓を占拠出来たのに)。
Nagiseさんが「昔はポリゴンを1つづつ云々」という話をしていて、そういえばラスタスキャンして描画するのに情報の持ち方や無駄描画を減らす若気の至り的アルゴリズム書いてたな等と思い出すも、つい最近も計算結果のキャッシュなどで割と似たような事をしていて進歩が無い、或いは俺って実はまだまだ若い。
ikegamiさんに「モデル理論に興味を持つとは反社会的な活動家なのではないか」と詰問され、自分は元々論理学など専門じゃありませんと自白し、続いて出されたカツ丼に背を押され、D加群のようなアプローチをモデル理論でやりたかったんですと涙ながらに供述した。
zickさんが「これをガ○ダムの回路に接続すれば出力性能が30%は向上する」と(マラソンで)酸素欠乏気味に旧式の携帯回路を出して来た。LISPが動いていたので、あの極貧メモリでGCを実現するとは、さすが○ニーの白い奴！と驚くも実機では未完成らしい。
h_iwkさんは象なのか魚なのか分からない彫刻の向こうに居て顔が分からず、しかし公務員であらせられること、プログラマをやっているわけじゃないことを知り、この怪しげな集りに参加するという奇抜な行動力はもしや革命家を検挙するための潜入捜査か？と恐怖したものの、情報政策について考えておられるそうで安心した。そもそも俺は革命家じゃないから公安を恐れる心配は無い。
alohakunさんはパートナーについて、その具合の良さだとかエコであるとかコイツなしでは駄目だとか、そんなノロケてるんだかデバッガの話なんだか分からないような事を話しておられたのでグリーンカレーを喰わせたら辛いと言っていた。喫茶店に移動後も「ワシのメモリ空間は無限大じゃあ」と豪語してデカいパフェをさらりと食べたのは驚きだった。
ranhaさんは何度も「ピーキャッスル」と連呼していたように思ったが、後から検索するときにPCASLだとちっともHITしなかったので「ピーキャストル」と言っていたのかもしれない。それはともかくフルスクラッチが大好きそうだったので、きっと高級言語か何かの専用プロセッサを作ってくれるはずだ。冀わくば、それがPCASTL専用マシンではありませんように。
二次会では第五世代話から言語と環境についてパネルディスカッションが行われたわけだが、"マイナー言語を流行らせるためにそのN"が応用ありきという、大型計算機の世界で何度も繰り返された結論に至ったのが何だかなのだが、MacOSX/iPhoneのObjective-CはNeXTSTEPの頃のアカデミックな運動の絡みでGCCに入っていた点が優位だったんじゃないかなと帰りに思った。つまり最終的な応用の前にやるべき事が沢山あって、それを地道にクリアしておかないと出オチするというか、、要素技術はある程度枯らして主題から降ろさないと、、
Prologの理論面の話が出たような出なかったような気がするけど、CommonLispよりは理論家(の割合)が多い気がする*要出典*、というのはそれが論理を扱っているからだろうとは思う。Prologの場合、新しい拡張だとかが実装される時というのは、同時にそれを説明する理論も一緒も提案されて、それが既存の公理系で扱えるのか、扱えないならどう違うのかが説明されるから。あの場で言った真偽の順序と計算の順序を合わせたbilatticeを述語のモデルに採用し、これのproductに対する代数演算がPrologプログラムの意味論として簡単で整合性がある云々は、NAFの扱い方の"一つ"だが他にもあるわけで。あとモジュールシステムの拡張でも同じようなモデルが使えて、この時は極小モデルがいつまで安定かみたいな保証を行ったと思う。
それとFortranでOOなコードを書くと遅いと言ったのは、今もそうなのか自信が無いです。単純に投入されて来た人的リソースの問題かもしれない。ただOOな作りだとプリロード命令をどこで入れると効果的かとか厄介だと思う。どれもこれもインラインという話ではないのだし、大域書換えな最適化が必要になるハズ、だと思う。それでこの下のレイヤというか命令セットの部分をどれだけ使い倒すかという話がメインの世界で、言語ってその為のディレクティブみたいなものだから、Fortressは高級だからというより焦点が合っていない感じがするのでした。数学そのままに書けるとかより、人が面倒見なくても良い塩梅になるディレクティブが欲しいとかがHPCらしい。それが出来たら次は数学っぽく書きたくはなるだろうけども。
ところで不覚にもコレを完全に忘れていた、誰かPrologで同人誌にしませんか？
登録:
投稿 (Atom)