2010/09/08

本気

「本気」って「マジ」でも変換できるんだ (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)

2010/08/17

#permalink

創作の目的

いつもスケッチブックを持ち歩いていた知り合いの絵描きは、下描きも無しに、人体の手先や足先、あるいは背景の一部から描き出して一枚の絵を完成させることができた。それは彼女にとってはただの手すさびだったかもしれないけれど、私はペンの先から次に何が産み出されるのだろうとわくわくしながら眺めていたものだった。

言葉と文章とプログラムと : たわごと

文章を構成する、てな話になったときに、「書きたいことがあって、それを章構成に分解して、必要ならさらに節、さらにこまかく〜」なことを言ったら、「書きたいことなんてないよ」と返されたことを思い出しまして。
書きたいことがないのに、文章とか書けるものなのか、と思ったわけですが。同様に、プログラムなんかもそうだし、絵なんかもそうかと思うんですが。「表現したいもの」や「目的」、「訴えたいもの」があって、初めて文章や絵、プログラム、音楽になるんじゃないのかな、と常々思っていたので、そういうもののない方とは、たぶん議論にならないな、と思ったな、という話で。
何かを作る、ということは、何か目的があるものではないか、と思うんですよね。それが文章であれ、プログラムであれ、絵であれ、音楽であれ。

「良い作品には、明確な目的としっかりした構成がある」っていうのはたぶん真。けれども、「良い作品を作るには、まず目的を明確にして、トップダウンにブレークダウンして構成を考えなければならない。」というのは必ずしも真ではない。

知り合いの物書きは、他人から「お題」を募集して、それをネタにショートショートを書く、というのをやっていた。一時期は一日一本のペースで書いていただろうか。トータルで数百本になっていたはず。大抵は、構成も結末も考えずに書き出すのだと言う。自分で書きながら、予想外の展開となってこの先どうなるんだろうかとどきどきしたり、驚くような結末を書いてから、ああこれはこういう話だったのかと納得したりするんだそうだ。

もちろん、かの絵描きや物書きがそんなふうに(描|書)けるのは、それまで散々、きちんと構成を考えて(描|書)くという訓練を積んできて、もうそれが身体に染み付いているからだろう。その域に達してない初級者中級者に、目的を明確にして、ブレークダウンして構成に沿って書くべきだ、というのは正しい。

起承転結だのパラグラフライティングだのといった方法論は、人間同士のコミュニケーションの歴史の過程から結晶してきたエッセンスのようなもので、それに乗っかっていれば通じやすいことが実証されているわけだ。伝えたいことが明確で、他人とのコミュニケーションをゴールとするなら、実証されたやり方に乗っかるに越したことはない。

けれども、創作行為にはもうひとつ、重要な役割がある。自分とのコミュニケーションだ。作品という具体的なアウトプット＝自分のココロの一面の投影を外部に作ることによって、「自分が本当は何を言いたかったのか」を知る、という役割である。作ったあとで振り返ってはじめて目的がわかる、というパターンだ。

「何か目的があるから作品をつくるのだ」というのは間違ってはいないけれど、出発点となる目的が作者に最初から見えているとは限らない。そもそも、「これから作る作品のテーマは××です」と言葉にして全部済ませられるなら、わざわざ苦労して作品の形にする必要はないではないか。小説なり、音楽なり、絵画なり、そのメディアでしか表現できない何か、コトバで簡潔に言い表しようの無い何かがあるからこそ、そのメディアを選んで作品にするのだ。

(作り手が、スローガンのように明確なメッセージを自覚していてなお作る作品、というのも無くはない。それは普通、「宣伝」と呼ばれる。)

出来上がった作品を第三者が分析する時には、テーマを確実に掴むためにワンセンテンスにまとめる、といったテクニックがあるのだけれど、それは「言葉になり得なかったもの」を捕まえるためのグリップにすぎない。作者の頭の中に最初からテーマとなるセンテンスがあったわけではないのだ。

目的を強調しすぎる弊害はいくつかある。「これを表現したいんだ」とあまりに強く思い込んでいると妙な力みが入り、創作の過程で「降ってくる」新しいアイディアを掴み損なうかもしれない。「これを表現したいんだ」という想い自体が、自分でも直視したくない別の動機を隠すための思い込みかもしれない。

けれども一番の弊害は、そうやって作っていると、作品は常に想定内に収まり、自分の予想を越えて化けるということが無い、ということだろう。それはそれで、作り手にも受け手にも安心感があり、そういう安心感の需要というのもある。でも、それだけをやっていて飽きないでいることは、とても難しい。

そもそも、目的を明確に決めずにつくりはじめることなんて出来るんだろうか、と疑問に思うかもしれない。そんな人は、「目的」と「題材」の違いを認識すると良いだろう。スティーヴン・キングは超常現象や怪奇現象を題材とする小説ばかり書いているけれど、彼の作品のメインテーマはほとんど常に、人は人の心の中の制御不可能な部分とどうやって折り合いをつけてゆくのか、という問いを中心としている。たぶん、そういうテーマを書こう、と構えて書いてるわけじゃなくて、インタビューやエッセイから察する限りでは、単に怖い話が大好きなだけだと思う。でも怖い話を書くと、そういうテーマが忍び込んできてしまう。クーンツのホラーとキングのホラーで読後感が全く異なるのは、そのせいだ。

ポイントは、何かをつくりはじめるには「題材」があれば十分だ、ということだ。先に「目的」がある程度はっきりしていて、それに沿った「題材」を選ぶこともできるだろうけれど、「目的」が良く分からなくても、どうも気になって仕方がない「題材」に出会ってしまう時ってのがある。それは、きっと自分でも意識していない「目的」がゴーストラインの向こうから囁いているんだ。だからとりあえず、手探りでいいからその題材を料理してみよう。そして、霧の隙間から本当の目的の姿が垣間見えるのを見逃さないように、アンテナをぴんと立てておこう。

あ、ちなみにこのエントリの話は、小説や絵画だけじゃなく、プログラミングにも結構当てはまる話だと思うよ。

Tags: ものつくり, 表現, Programming

Comments (0)

More entries ...

Island Life

About

最近のエントリ

最近のコメント

最近のリリース

書いたり訳したりした本

2010/09/08

本気

2010/08/22

PCアップグレードメモ

2010/08/21

偽ポインタ

2010/08/20

浮動小数点数遊び

2010/08/17

創作の目的