2010/09/09

『Where Men Win Glory』

良い作品は多数の層から出来ているものだ。ひとつの層に合わせたピントを少しずらすと、全く別の様相を見せる層がフォーカスして来る。時を経て遠くから眺めてみると、近くで受けた印象とは異なる全体像が浮かび上がる。

Jon Krakauerの "Where Men Win Glory : The Odyssey of Pat Tillman" もまさにそんな名作のひとつ。どこにピントを合わせるかによって色々な読み方ができる。

短く紹介するなら、「NFLの現役選手でありながら、9/11テロ後に米軍に志願し、アフガニスタンで友軍誤射によって命を落としたPat Tillmanの軌跡」ってことになる。そこにピントを合わせれば、この作品は、無謀とも見える単独行によって命を落としたChristopher McCandlessを追った "Into The Wild" の延長にあるとも言える。実際、KrakauerはTillmanの人生を生い立ちから丹念に追うことで、「なぜ彼は、NFLの選手という誰もが素晴らしいと認める職業を捨ててまで戦地に赴いたのか」という答えをあぶりだそうとしている。 ("Into the Wild" でも、McCandlessは物質的な幸福に背を向けたのだった。 cf. 20081111-into-the-wild)。

けれどもこの作品では、その答え探しはたくさんの層のひとつだ。 Tillmanの人生の軌跡と平行して、 Krakauerはアフガニスタンで起きていたことを解説する。本書の前半は、ソビエト侵攻前夜から米国の「テロとの戦争」によるアフガン侵略までの歴史の、良いサマリにもなっている。

中盤以降も複数の層が平行して語られる。軍隊に入ったTillmanの直面した、理想と現実のギャップ。 Tillmanは「正しいことをする」ために入隊したのだが、同時入隊のほとんどはむしろ、行き場が無くて軍隊を選んだ若者達だった。「有名人」であるTillmanに目をつける上官もいた。「いい気になるな」というやつだ。一方で、Tillmanは尊敬できる軍人にも多く出会う。軍隊という組織ひとつとってもそこに複数の層がある。

中盤では、イラン戦争中の "Battle of Nasiriyah" が詳しく扱われる。 Jessica Lynchがイラク側に捕獲され、数日後に救出された戦闘だ。 Pat Tillmanも、出動はしなかったものの救出作戦の後方支援として待機していたので一応関連するのだが、ここでの焦点は別にある。この戦闘での米軍の死者はほぼ全て友軍誤射によるもので、そもそも戦闘の発端も米軍自身のミスによるものだった。 Krakauerはいくつかの章を割いて、戦場の混乱の中で友軍誤射が生じるメカニズム、そして世論をコントロールしようとするブッシュ政権の情報操作を、証言を元に浮き彫りにしてゆく。

Battle of Nasiriyahの経緯は、Tillmanが命を落とすことになるアフガニスタンのKhost Provinceでの戦闘の経緯の伏線にもなっている。ここでも、上層部の無理解と判断ミスが発端となり、敵襲を受けてパニックになる中で部隊内での連絡が分断され、 Tillmanは仲間の銃弾に倒れる。

後知恵で軍規違反やミスを指摘するのは簡単だけれど、その場にいた当事者がどうすれば良かったのか、自分がそこにいたら何が出来たか、という問いに答えるのは難しい。正直、一旦運命の歯車が悪い方に回り始めると、個人の力でそれを止めるのは不可能なように思える。戦争については、War Gamesの有名なquote、 "The only winning move is not to play." というのは真実だろう。でも始まっちゃったもんをどうしたら良いのかはわからない。

Tillmanの死後、友軍誤射の事実は隠され、ブッシュ政権はTillmanを悲劇のヒーローとして情報操作しようとするが、今度はJessica Lynchのようにうまくは行かなかった。遺族の絶え間ない追求により度重なる調査がなされ、多くの証言が情報公開法によって明らかになった。

ただ、Krakauerの筆致は、単にブッシュ政権や米軍の隠蔽体質を糾弾するというだけではない。今回はたまたま米国だっただけで、愚行はどんな組織にも起こり得る。けれども愚行を避けようと「ものわかりの良い」人間ばかり育てる社会は、不条理な挑戦を避けるからっぽの人間しか生み出せなくなる。大きなパースペクティブで見れば、閉塞を乗り越えるには Pat Tillmanのような、あるいはChristopher McCandlessのような人間が必要なのだ。この主題が、Krakauerの全ての著作に流れる基底音だ。

(Amazon.co.jpだと"Where Men Win Glory"はハードカバーのしか出てこなかったのだけれど、ペーパーバック版の方が新しい情報をもとに改訂されているので、読むならペーパーバック版がおすすめ)。

Tag: 本

Comments (0)

2010/09/08

#permalink

本気

「本気」って「マジ」でも変換できるんだ (by Anthy)。

とある役者のお話。。

とある芝居のとある役者さんが言っていたそうです。
※ちなみに彼は芝居をするために調整がきくよう、、バイト生活をしているとのこと
そのお芝居はふたり芝居だそうで・・その相方は派遣社員をしながら芝居をしているとのこと
「俺がこんなに本気でやってるのに、、本気でやってない人とは一緒に芝居はしたくない・・！」
というような内容を吐いていたそうで・・・・

件の役者さんが何を以って「本気じゃない」と思ったのか、本音のところはわからないのでこのケースについてとやかく判断することはできないけれど、 day jobはバイト程度にとどめて出来る限り夢の実現に時間を割くか、二足のわらじを履いて長期的な継続性を重視するか、っていうジレンマは困難な夢に挑戦する人にとっては一般的な問題だと思う。

芝居に限らず、天井のない技能を極めようと思ったら、人生の全てをそれにつぎ込むのが(技能を最大化するという点で)ベストであることは自明なので、他に職を持ちつつ限られた時間しか費やせない人はどうしても後ろめたさを感じてしまう。「本気じゃないんだろう」と詰め寄られるとそうだと認めざるを得ない。

ただ、「本気」の基準はひとつではない、ということは、この手の議論でしばしば忘れられがちなように感じる。

プロとしての「本気」というのは、第一には「コミットしたことを確実に成し遂げられるか」という基準で測られる。生活の全てを賭けても、事前に「やります」とコミットした成果物が出せなかったり質を満たせなかったりしたら意味がないし、逆にコミットメント通りのアウトプットを出せるなら片手間でやっても全く構わない。

「本気でない人とは仕事をしたくない」という場合の「本気」というのは、そういう基準で測られるべきだ。手段は問わない、アウトプットが満足できるかどうか、それだけ。この基準であれば、例えば何らかの事情で自分の時間の半分しかコミット出来ない人も、そのリソースで満たせるポジションさえあれば、「本気」で参加することができる。

もちろん、全員が全生活を賭けなければ成し得ない、非常に高い質を目指すプロジェクトというのはあり得るだろう。そこで片手間仕事をしていたら非難されるだろうが、それは片手間仕事だからダメなのではなく、プロジェクト参加時点で「全てのリソースを要求するよ」という条件にコミットしているはずなのにそれを満たしていないからダメなのである。全部の時間を使えないとわかっているなら、最初の時点でコミットせずに外れるべきなのだ。

この「本気」とは別に、個人的なゴールとしてどこまで技芸を極められるか、というチャレンジに対する「本気」がある。これはもう、本気で最も高いところまで行こうと思ったら他の全てを犠牲にしてやる、ということになるだろう。そうしなければ到達できない世界というのはあるし、そういう人たちでなければ入れないプロジェクトというのもある。

でも頂上だけが世界の全てではない。広大な裾野が支えているから頂上があるのだ。

元のブログの話に戻れば、「(正社員/派遣)だから本気じゃないんだろう」というのは後者の基準での本気。けれども、「本気じゃない人とはやれない」という場合は (少なくともプロとしての基準なら)前者の基準であって、件の役者さんはその二つを混同しちゃっているようにも見える。まあ他にも色々事情があってのことかもしれないのでとやかくは言えないけど、役を降りるというのは重大なコミットメント違反なのだから、それを「相手が本気じゃない」ということで正当化するには、よっぽどの事情が必要だろう。どっちにせよ、最初から相手が「他に仕事を持っているからこの範囲でしかコミットできない」という条件を知ってて自分がコミットしたのなら、相手が仕事を持っていることを理由にするのは無理がある。

★ ★ ★

ところで、このふたつの「本気」の混同だけど、不公正な雇用慣行にも関連しているように思う。

従業員というのは雇用契約によってコミットする範囲が決められてるはずで、「本気で仕事している」というのは、そのコミットした範囲で成果物を出せているかどうかという点においてのみで測られるべきだ。

後者の意味での、個人的な人生の目標を達成するために 24時間自己研鑚を積むっていう「本気」はあくまで個人的なものであって、雇用者がとやかく口を出すものではない。雇用者に出来ることは、入り口の時点で要求水準をうんと上げておく (もちろんそれに見合った待遇を提示する)ことだけである。「この仕事に入ったら道を極めていかないとついてけないよ、いいね」という条件にコミットした人間なら、ふたつの「本気」は一致する。

でもそれは、そういう種類の仕事である、っていうだけで、そうでない仕事もいくらでもある。このふたつの「本気」をわざとかどうだか混同して、「凡そ仕事とは絶えざる自己研鑚を要求するものだ、そうできないのは社会人として間違ってる」といった意見を押し付ける企業もままあるようで、恐ろしいことである。

このふたつの本気を区別できれば、例えば育児があるから半分の時間だけ出勤します、という人だって「本気」で仕事できるし、正社員/派遣/バイトの区別は単なる雇用形態の違いだけで、それを「本気」度の目安にしてしまうという愚も避けられると思うのだけれど。

Tag: Career

Comment (1)

2010/08/22

#permalink

PCアップグレードメモ

OpenGL4を試してみたかったので新しいGPUを入れることにした。だらだらと顛末をメモっとく。

ハワイのPC専門店は壊滅してしまったので(唯一の量販店であったCompUSAは撤退し、小さなパーツ店も次々と消えていった)、パーツ入手は通販によるしかない。それもハワイだと送料が高いのでつい色々まとめて注文してしまう。

今回はまずメインマシンにGTX470を入れることにして (480はまだ高いのでちょっとケチった)、そうすると電源が足りないので650Wの電源追加。 CPUがCore2 Quadなんでいまいちなんだけど、Core i7にするには MBから変えなくちゃならないので今回は見送り。

あと、かみさんのPCも、最近web見てて重いと言っていたのでついでに更新。当初はCPUすげ替え+RAM増設くらいでいいかなと思ってたんだけど、既にMBの世代が変わってて新しいCPUは軒並み載らないし、メモリも今更DDRでは買い足したところで後で使い回しもきかない。面倒なのでCPU/MB/RAM全取っ替え。Pen4 dual coreとDDR2 2Gにした。

パーツはどんどん世代が上がってくから、結局あんまり使い回しが効かないなあ。一番使い回せているのはケースだ。ATXのケースは寿命が長い (さすがにATのケースはもう使いようが無いけど)。次がHDD。

思わぬ副作用は、音が静かになったこと。Pen4は65Wのやつで前のCeleron Dより静かだし、メインマシンの電源も大きなファンのおかげか心なしか静かになったようだ。

GTX470についてはちょっとはまった。Ubuntu配布のNvidiaの最新のドライバ(195.36.24)でないとだめなんだけど、このドライバで起動すると解像度が640x480までしか上がってくれない。

以下トラブルシューティング。

nvidia 640x480 とかでぐぐると色々出てくる。 https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia とか https://wiki.ubuntu.com/X/Config/Resolution も参照。解像度のトラブルは多いらしいく、xrandrを使ってモードを強制指定する方法がポピュラーらしいが…
```
$ cvt 1680 1050
# 1680x1050 59.95 Hz (CVT 1.76MA) hsync: 65.29 kHz; pclk: 146.25 MHz
Modeline "1680x1050_60.00"  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync
$ xrandr --newmode "1680x1050_60.00"  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync
$ xrandr --addmode default "1680x1050_60.00"
```
これで新しいモードは足せるんだけど、切り替えようとすると:
```
$ xrandr --output default --mode "1680x1050_60.00"
```
エラーになる (エラーメッセージメモっとくの忘れた)。
xorg.confを編集して上記のModelineを"Monitor"セクションに追加し、 "Screen"セクションから明示的に参照してみる。
```
Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
        Modes      "1680x1050_60.00"
    EndSubSection
EndSection
```
だめだった。/var/log/Xorg.0.log を見ると、モード "1680x1050_60.00" は validでないのでremoveした、などと出てくる。
手がかりが少なすぎるのでもう少し何が起きてるか知りたい。さらにぐぐると、Deviceセクションに次の行を足したらログに色々情報が出る、ということを知る。
```
Section "Device"
    ...
    Option         "ModeDebug" "true"
EndSection
```
これで走らせてわかったこと。
- モニタのNative backend timingsが640 x 480 @ 60 Hzと認識されている。 EDIDではちゃんとDetailed Timingのところに1680x1050が出てくるんだけど、全部読んでないのかな。
- Unable to use mode "1680x1050" ... cannot compute backend DFP timings (mode is larger than native backend 640 x 480) と言われてこのモードが蹴られている
色々断片的な対策が検索でヒットするので順に試してみる。
- Option "IgnoreEDID" "1" # EDID情報を無視させる - 効果なし
- Option "ModeValidation" "NoDFPNativeResolutionCheck" # ResolutionCheckを切る - 効果なし
- Option "ExactModeTimingsDVI" "true" # Modelineで指定したタイミングを信用しろ! - これが効果あった。

昔はXの設定で良く苦労したものだったけど、最近でもこんなことはあるんだなあ。

Tag: PC

Comments (0)

2010/08/21

#permalink

偽ポインタ

GC本読書会 - ときどきの雑記帖

#shiro さんが shibuya.lisp あたりで 64bit アーキテクチャでは
#ポインター/非ポインターの誤判定が増えたという話をされたような
#覚えがあるけど詳細思い出せず。
#ポインターじゃないものをポインターに判定して回収されないゴミが
#増えるという話だったかなあ?

逆で、問題が出たのは32bitアーキテクチャ。

4GBの空間を目一杯使うようなプログラムだと、ランダムな32bit整数が有効な領域を指すポインタと誤認される確率がとても高くなるということ。

ヒープオブジェクトの先頭を指している時のみポインタと判断する、というふうにすれば大抵防げると思う(Boehm GCのオプションで切り替え可)のだけれど、 Gaucheではオブジェクトの中を指していれば有効と判断しているので。

「先頭のみ」にすると、オブジェクトの中をいじってる時に一瞬でも先頭への参照を失わないように気をつけてコードを書かないと、触ってるオブジェクトが途中で回収されてしまう可能性がある。コンパイラの最適化が絡むと結構厄介だ。例えば次のコード。オブジェクト内へのポインタを有効とする場合は安全だけれど、オブジェクト先頭へのポインタしか認識しない場合は安全ではなくなる。 (ScmStringは、const char*な文字列へのポインタを持つ構造体。 Scm_GetStringConstはそれを取り出す。)

void foo(ScmString *arg)
{
  const char *s = Scm_GetStringConst(arg);

  for (; *s; s++) {
    /* sでなんかする */
  }
}

Tags: Programming, Gauche

Comments (0)

2010/08/20

#permalink

浮動小数点数遊び

ついったーで

Gaucheで(apply + (iota 10 0.1 0))を評価すると、0.999999999..と結果が出るのだが、他の言語(Rubyとか)だと1.0と出る。なんでだ？丸め誤差を出してる精度の違い？・・・なの

という話を見かけて、これの答えは以下の通りなんだけど:

http://practical-scheme.net/chaton/gauche/a/2010/08/20#entry-4c6e3eb1-56a43

計算ではなく表示精度の問題だと思います RT: @illness072: Gaucheで(apply + (iota 10 0.1 0))を評価すると、0.999999999..と結果が出るのだが、他の言語(Rubyとか)だと1.0と出る。なんでだ？丸め誤差を出してる精度の違い？・・・なの
irb(main):001:0> 0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1
=> 1.0
irb(main):002:0> (0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1+0.1) == 1.0
=> false
@illness072 Gaucheの浮動小数点数表示は内部表現と1:1に対応しているので、同じ表記で出力された数値は正確に一致します。つまり、正確に一致しない数値を同じ表記で出力することはありません。
ああ、正確にはNaNだけ例外か。複数のビットパターンがあるけど全部+nan.0と表示するから。

ふらふらと他のツイートをみてたらこんな問題を見つけた。

http://twitter.com/s01/status/21375206236

「1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0の10個と + - × ÷ ( )を使って大きい数を作れ」という問題。10万以上から「ちょっと賢い」ラインだそうだけど1万も厳しい

本来は数学の問題なんだと思うけど、プログラマならやっぱり誤差を利用することを考えちゃうよね。

gosh> (define *s* '(1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.0))
*s*
gosh> (for-each (^(a b) (print "(- "a" "b")="(- a b))) (cdr *s*) *s*)
(- 1.2 1.1)=0.09999999999999987
(- 1.3 1.2)=0.10000000000000009
(- 1.4 1.3)=0.09999999999999987
(- 1.5 1.4)=0.10000000000000009
(- 1.6 1.5)=0.10000000000000009
(- 1.7 1.6)=0.09999999999999987
(- 1.8 1.7)=0.10000000000000009
(- 1.9 1.8)=0.09999999999999987
(- 2.0 1.9)=0.10000000000000009

ご覧の通り、10個の数値は等間隔ではなく、0.1より微妙に狭い場合と微妙に広い場合の2通りの間隔がある。微妙に広いのと微妙に狭いのの差を取ればうんと小さい数が作れるので、例えば：

gosh> (/ (* 1.6 1.5)
         (* (- (- 2.0 1.9) (- 1.2 1.1))
            (- (- 1.8 1.7) (- 1.4 1.3))))
4.867778304876402e31

(ところで数学的にやるとどこまでいけるんだろう。今のところ10万ちょっと越えくらいまでしか思いつかない。誤差を避けるために有理数で計算:

gosh> (/ (* 12/10 18/10)
         (- (- (/ 13/10 11/10) (/ 17/10 16/10))
            (- (/ 20/10 19/10) (/ 14/10 15/10))))
541728/5
gosh> (inexact 541728/5)
108345.6

)

(ああ、分子を足し算にすれば150480になるな。)

Tag: Programming

Comments (0)

More entries ...

Island Life

About

最近のエントリ

最近のコメント

最近のリリース

書いたり訳したりした本

2010/09/09

『Where Men Win Glory』

2010/09/08

本気

2010/08/22

PCアップグレードメモ

2010/08/21

偽ポインタ

2010/08/20

浮動小数点数遊び