まあ、騙すよりは騙される側でいるほうが罪がなくていいのだけどね。
はて、なぜオレはそう考えるのだろう。か??
ある国では、客と店員が協力して、買い物のさいに使う硬貨の個数の和がもっとも少なくなるように 買い物する。たとえば US で 24セントのものを買いたいときは、客は 24セント (硬貨6個) ちょっきりは 払わずに、わざと 25セント (硬貨1個) を払い、店員が 1セントのおつりを返すのだ。こうすることにより 「客の出した硬貨の数」 と 「おつりに含まれる硬貨の数」 の和が最小になる。 与えられた価格分布において、この和の期待値を最小化するような硬貨の金額を設計せよ。ちなみにこの場合はさらに最小化する変数が 1個増える。 これも定式化は簡単なんだけどね。探索空間がデカい。
ところでこの教授は Scientific American にパズルの記事を 書いているので有名らしいのだが、日経サイエンスにも掲載されてるのかな??
内輪うけはアナタを巣喰ってくれますか??
encoding と呼んでいて混乱する。
たとえば "x-sjis" は charset名ではあるが codec 名ではない。
変数名でも混乱しそうなので、もうこれからは "encoding" という名前は
使わないことに決定。"charset" と "codec" で使い分けよう。
その他の成果:
google://てまえポン/ (1軒)
なんなんだこいつらは。拾いに行くやついるのかな?
いまでもあの方々は「鍵持ち」をやらされているのだろうか。
寝ちゃおうかな。
キラカー (お気楽'er)
なんてやさしい TA だ!!
ところで、けさ起きたら左目のマブタがはれぼったくやや痛かった。 見てみると、モノモラーができたらしい。まだこれがソレであるという 100% の 確信はないが、なんとなくそんな感じだ。
しかし、モノモライ…。記憶に残っているかぎりでは新山はモノモライに なったのはこれが初めてであるので (もしかすると子供のころには一度なったことあるかも しんないが)、なんとなくウレシイような気。もする。
まあこれは初めてウオノメができたって喜んでるようなもんで。
午後は Heuristic Problem Solving の宿題をやってすごす。 この授業はなかなかユニークで、ようするに先生が毎週数学パズルを学生に出し、 学生はそれをプログラミングして解く、ということをくりかえすのだ。すげー楽しそうでしょ。 今回のパズルは最初のやつで、「硬貨の設計 (Mint)」である。これは簡単にいえば、以下のような問題だ:
ある国が 5種類の硬貨を市場に流通させるとする。 政府は流通させる (生産する) 硬貨の数をなるべく少なくすませたいが、 これは各硬貨の金額をいくらに設定するかによって変わってくる。 たとえば US では 1, 5, 10, 25セントの 4つの硬貨を使っており (1ドル硬貨は無視する)、 EU では 1,2,5,10,20,50 セントの硬貨を使っている。 物価の分布が与えられたとき、最適な硬貨の金額をデザインするプログラムを書け。
まず、最初に「ユニット問題」を解かねばならない。各硬貨が特定の金額のとき、 ある値段の品物に対して最適な (もっとも使う硬貨の少ない) 払い方を見つけるのは、 じつはそんなに単純でない。最初、「でかい方のコインから使ってきゃいいんじゃないの?」と考えたが、 これは間違っていた。たとえば「1セント硬貨、30セント硬貨、50セント硬貨」という 変態な組み合わせの硬貨しかない世界で、60セントの品物を買うことを考えると、 50セント硬貨を使うのは間違いなのだ。なぜならそうすると残る 10セントはぜんぶ 1セント硬貨で 支払わねばならないから、11枚必要になってしまう。けれど 30セント硬貨を使えば 2枚ですむ。 基本的にこれは動的計画法に還元できるため、実際にはそんなにむずかしくない。
さてこのように「ユニット問題」は簡単に解けるのだが、問題はすべての考えうる金額の 組み合わせの中での最適解を探さねばならない、ということである (5種類の硬貨にそれぞれ 1〜99セントまでの異なる金額を割り当てるので、… いくつだ? 99C5 = 7000万通り、計算してみたらたいしたことなかった) 。 最終的にはこれは探索問題に帰着できるのであるが、問題は探索空間が デカすぎて何らかのヒューリスティックを使わないと最適 (に近い) 解を見つけられない、 ということだ。だから唯一の最適解を見つけるのが目標ではなく、いかに 最適解に近づけるか? が重要になる。そして各学生はこれで競争するわけだ。 まあ、今回の宿題だと Brute force でもできそうな気配なのであるが…。
てくるで、今更ながら iTunes Music Store を使ってみたが、 すげー。これ、バケモノ的に便利。こんなんではうっかり月に 何十ドルも使ってしまう人がいても不思議ではない。しかし… どうもあんまり音がよくないような気がする。ビットレートも 128k だ。 基本的にこういうのはヘッドホンとかいいスピーカで聞いちゃいけないのかもしんない。
ぜんぜんカンケイないが思い出したこと。きのう、うちのビルの 1階に某G社のチラシが貼ってあった。 例のロゴのせいで目立つ。そして「われわれ G社が大学にくるよ! そしてキミをさがしているよ!」と書いてある。 いつもこんなところにポスターを貼ったりしないのになんでこいつらだけ特別扱いなんだろ。 MSが同じことやったら大ブーイングだと思うけど、なんでみんな G には目をつぶっているわけ? やつらはべつに正義の味方なんかじゃないぞ。
いや、ほんとに。シュナダフウムウ。
なんですってqェーー−-
google://シュナダフウムウ/ (1軒)
East village に「蕎麦屋」 (NE) という有名な蕎麦屋 (一般名詞) があるが、 このあいだ久しぶりにそこへ行ったのだが、いちおう味はいいのだけど、 ソバ湯が薄くて不満だった。まあ、普通は日本の蕎麦屋でもあのくらいなんであるが…。
蕎麦によっては、もっと、トローっとした感じの蕎麦湯になる。 NY の「蕎麦屋」は、生意気にもいちおう手打ちで、いつもヒスパニック系の あんちゃんが蕎麦を打っている。しかし蕎麦粉は安曇野産だという。 ふん。新山は蕎麦に関しては圧倒的に「新潟派」である。 しかも津南町じゃないとだめだ! (長野の蕎麦と新潟の蕎麦は感触がやや違う、これホント) で、オレはいったい何の話をしているかというと、ひさびさに「苗場そば」を 入手してソバ湯を飲んでいる (うまいソバ湯はそれ自体に味があるので、 何も入れずにそのまま飲めるのである)。でもなんかやっぱちょっと 日本と違うぞ。くさみがある。水のせいだろうか。
google://師弟バンク/ (1軒)
おお! いま発見したが 「検索結果: 1件」というよりも「1軒」を使ったほうが なんかいいぞ!
資料はこっちら: http://www.unixuser.org/~euske/doc/python/tutorial0917.html
(23:56 長いので unixuser に移動: あとでリンクはること)
タプルは意図的に避けた。最初からすべての機能を紹介しないほうがいい。なんかまだあるかな〜 (15:46)
さいきんさー、あっちこっちのポートで web サーバ上げてんだよね。 うちだと 8080 はもう使用中だから使えないとして、 いま 7777 と 8000 と 8888 でも上がっている (といっても bind は 127.0.0.1 だが)。 ブックマークに "localhost:8000" とかいうのが山ほど入っているのはなんかヘンだ。
ところで IDLE をいじっていたら「indent-region」の逆は「dedent-region」っていうの? 「ででんとリージョン」ってなんかカッコいいじゃん。
あんなに長く (2時間) 続くなんてよ〜。しかもオレは興味がないのになんか興味あるような フリをしなければならず、ああいう場は大変しんどいのである。 おまけに寝不足なうえに朝メシを食わずに出席したので、もう最後のほうに なると頭がクラクラして正常な思考ができなくなっていた。
昼メシを買いにいったら Univ. Pl. に法輪効の連中が沢山いて、 なんかみんな地ベタに座って、天に向かって祈りをささげている。 こいつらを根だやしにしたい中国政府の気持ちがわかるような気がした。
どうでもいいが、今日は授業があるので nylug-meeting に出れない。 なんか面白そーなトピックなのに〜〜
その 5. お客様の書いた文章より長い文章で返答せよ。
熱心さがお客様に伝わる。
ああそう。これには笑った。ほかの項目もかなりアホなのだが、こいつはとくにひどい。
日本式上げ底文化がここにもある。 「冗長なメールは (相手にその分だけ読む時間を取らせるから) 失礼だ」 と思って、いつもなるべく語数を減らすようにしているオレは一体どうなる? (けど重要なポイントは落とさないようにしたいので神経つかうのに)
ふつう、日本人は上げ底の包みなんて気にせず捨てるから、 こういうことを言う人はきっと相手の言うことをそもそもちゃんと 聞いるかどうかあやしいし、自分の言うことも適当にカサをふやしているのだろう。 まるでオレが学部のときにやった課題レポート水増し作戦みたいなことを 仕事でやっているわけだね?
まあ、日本語の敬語体系そのものが上げ底文化の一種といえばいえるかもしんないが。
しかし、CD-ROM があるのでぜんぜん必要ない紙の物体であった。 (必要なところだけ印刷すりゃいいわけだし、いまさら重い本をウンウン言ってコピー機するやつはいない) もったいないのう。おまけにそれを 5000円近くかけて送ったオレの人生はさらに無駄。
Solarwolf だった。バレバレぞ。
LispNYC のイベントに行ってきたのである。 でも、こんなに遅くなるとは思っていなかった。トークのあとに 1av のバーで飲んでいたのだが、当然、 「今 Lisp で何やってるの?」という話になりまさあね。それで「いやー昔 Scheme 使ってたんだけど、 いまは Python のほうが気にいっててね」といったら…
「なにィイ? Python だァア!?」
一斉に攻撃開始。ほぼ、向かうところ敵なし。の、逆。みんな 「なぜあんな言語を使うんだ! Lisp のほうがあきらかに圧倒的にすべての面において優れている!」 という。孤立無煙。いやー、さんざんイジめられましたよ。以下、 新山が受けた罵倒を ここに記しておく (忘れないうちに):
しかし、彼らの多くは本当は Lisp を使いたいのに、毎日の仕事では嫌々 Java や C++ を使わねばならない境遇に置かれているのだった。みんな、ストレスたまってんだろなー。 ここからも Lisp がマイノリティであることをひしひしと感じる。しかし彼らは「Python, Java を ふくむすべての言語はどんどん Lisp 的な機能をとり入れてきており、 いずれすべての言語は Lisp に回帰する」と信じているらしいが、まるで共産主義みたいだな、 と言っておいた (中国人と話すと、「いつか世界が共産主義のよさをわかるときがくる」と 思っている人がいて驚く、全員ではないが)。実際、彼らは「人間はみんな (マクロを設計できるほど) 賢い」と 仮定してそうなので、じつにサヨクと共通項が多そうだ、というのは以前ここにも書いたけど。 相手に好き勝手言われていると、こっちもなんの気がねもなくキツいことが言えるからやりやすい。
でも彼らはそれなりにちゃんとしたことも言っている。 たとえば、新山は Lisp (Scheme) でどんな構文でも同じように見えてしまうのがイヤで、 Python だと違うものは見た目が違って見えるからいいんだ、と言ったのだが、 彼らは「でもそれはライブラリ呼び出しには当てはまらない、Python だって 全然違うライブラリ呼び出しの見た目は同じじゃないか」という。 たしかにそうだ。それでもオレは文字列操作や数値計算などのプリミティブな操作は 違って見えたほうが好ましい、と考えるが、べつに Lisp 的なやりかたを全否定しているわけじゃない。 用途によると思う。しかしライブラリの問題はどんな言語でも起こりうるだろう、 というと、彼らは「いや Lisp はそうじゃない、Lisp はほかの言語よりもずっと 抽象化がしやすいから、自分が『何を解くか (what to solve)』に専念できる、 なぜお前は Python のような『どう解くか (how to solve)』しか書けない言語を使うのか」といわれた。 そうかなあ? いや、むしろオレは抽象的な解法なんていつもあるとはかぎらないと思う。 時にはより即物的な匂いのする解法を、より直感的な文法で書きたい。 Python を使う理由のほとんどはコレだ。オレが解く多くの問題は抽象度がそんなに高くないからかもしれない。 まあ、たしかに超巨大プロジェクトでは Allegro CL がいいかもしれないということは認めるよ。速いしね…。 そして彼らはとにかくマクロの使用をやたらと強調する。マクロが使えない言語は 言語として認めないのではないかとすら思った。
さいしょ、彼らがなぜそんなにマクロにこだわるのか わからなかったが、彼らのいう「プログラム」のほとんどが業務用のバカでっかいソフトで、 ただひたすら仕様を実装するのが仕事、ということがわかると、まあそれはうなづけるのかもしれない。 Java のような言語でマクロが使えないと、いざどっかのモジュールが仕様変更したときに (単純な関数の変更では) 対応できないというのだ。マクロのおかげで Lisp はどんな変更にも 柔軟に対処できる、と彼らは主張するが、それをいうなら OO だって目的は同じところ (=変化に柔軟に対応できる) を 目指しているはずである (ちなみに新山は「OO もマクロもダメなときはダメだ」と考える)。 でも連中あくまでマクロこそが本命だと考えてるらしく、「プログラミング言語は OOと高機能マクロの 両方を備えるべきだ、どっちも完璧なのは CommonLisp だけだ」という。 Paul Graham もマクロが本命で OO は嫌いらしいからな (ちなみにマクロはデバッグが地獄じゃん、 といったら、彼らは「Lisp のマクロは C なんかのそれよりもカシコイので、そんな問題は出ないんだ」といっていた。 眉唾)。
ちなみにきょうのトークは Scheme だったが、ここの人々はあきらかに 「CommonLisp が一番エライ」と思っているようだった。 「なにより CL には美しい標準がある!」と彼らはいう。 彼らにいわせれば「Scheme なんか仕様書が小さいだけで、あれだけじゃ何にも書けやしない、 結局ライブラリを全部書かなきゃいけなくて、他人が別の環境で書いたコードは全然共有できない」というのだ。 最近は SRFI があるからいいんじゃん? というと「あんな付け焼刃な規格は全然ダメだ、 SLIB のほうがまだよくできている」と言われた。そんなに CL の規格って整っていたっけなあ? Lisp は名前空間が 2個ある (関数と変数で別々) のはどうなの、あれは混乱するんだけど、と尋くと、 彼らは「あれが分かれてるおかげで関数名と変数名の衝突を心配せずにすむだろ」という。 そーんなこと、めったにあるもんじゃないじゃん? と思ったのだが、彼らはなんでも見境なく 短いマクロにしてしまいそうだからそのへんが問題になるのかもな。
いやー、そういうわけで 4時間ちかく喋っていたのだが、最後は後腐れなく握手して 「次のミーティングも絶対来いよ!」といいつつ別れた。喋りすぎて声が枯れてた。でも楽しかった。 日本でこんな濃い議論ができる集まりはあるだろうか?
トーク自体は Java と Scheme をいかに組み合わせるか? という話で、これはなかなか面白かったのだが もう書くヒマがない。それにしても Java で書かれた Lisp/Scheme 実装の多いこと多いこと。 冗談ぬきで数十もあるらしいよ。さて寝なきゃ。宿題まだやってねーよ! todo: jatha, jscheme, kawa, linj, stella,
バナナのヘタが 3つともとれてしまった。
うちでは Bonita のバナナを房で買ってあるのだが、 いま 1本食そうとして房からもぎ取ろうとしたら、ヘタに一緒についてた 別のやつ (ユニット) のヘタの根っこの部分 (本体とヘタとの付け根のところ) が 黒ずんで弱っていたらしく、そこがポきっと折れて中身がむきだしの状態になってしまった (まだ完全に分離はしていない、一部の皮でつながっている)。取ろうとした バナナ自体は無事である。「ふげー」と思って、そんじゃあ中身が見えちゃった ヤツから先に食うべえと (傷んじゃうからね)、その弱くなったやつを もぎ取ろうとしたら (そいつの皮はまだヘタにくっついてるので、ヘタごと 分離したほうが早かろうと思ったのだ)、その衝撃で 別の2本のやつがボこットトレタ。 「ふんぎょえー!」と思ったが、もうあとの祭りである。 一夜にして (より正確には、一瞬にして) 都合 3本のバナナを 食わねばならないハメに追いこまれたのだが… しょうがないので 2本はここで食って、1本は大学に持っていくことにスルホン酸。 ったくよう。バナナのヘタは強くしろ!! 証明終わり。
最近のバージョンアップで、このゲエムにはそれなりに奧行きがでてきたと思う。 ひとつは隕石の追加で、こいつは弾よりもノロくて進路を妨害するので 最初かなりジャマだったのだが、じつは敵 (?) の撃つ弾は「隕石に当たると消える」ので、 隕石の進路が読めればこいつをタマよけとして使うことができる (ただし隕石自体に触れるとボカーンとなりますが)。そしてパワーアップアイテムの追加。 こいつは取らずに放っておくと次の面に「持ち越せる」ので、上手く使うと時間ぎれのところを 防ぐことができる。ただしあまり長い時間たつとそのうち勝手に消えてなくなるので注意。 使いどきが問題だ。先のほうへ進むとタマの数が半端じゃなくなるので (画面上に常時 20〜30個は出るようになる)、取りたくてもそこまでたどりつけずに死ぬ。
なによりも意地悪な変更は 30面以降に出てくる「隠れ爆弾」の追加である。 こいつは最初エサ (四角いやつ) のように見えているのだが、 一度その上を取ると「シャキーん」というような音とともに 爆弾に変わるのだ。新山は黄色や赤のエサを取るのに同じところを何度も行ったりきたりすることが 多いのだが、この隠れ爆弾のせいですっかりその戦略は変わってしまった。いまやひき返したとたん ボガーンとなる。激コワいね! これにひっかからないように効率よくエサを取るには、 なるべく「一筆描き」に近い経路をとる必要がある。しかし弾が多いとこれは簡単にはいかない。 かくして「1面もクリアできずに 3機やられてゲームオーバー」が頻発することになるのだった。 いや、すげえゲームだよ。Windows 版も Mac 版もあるのでぜひやるべし。
なんでおんなじ健康保健カードが 2コくるの??
いまとり出して隅から隅まで調べたが寸分たがわず一緒である。番号もとうぜん一緒。 これはいったいなんなんだ?? バックアップ用なのか。
どうでもいいことであるが、今あるところであるものを見たら、ひどかった (身内に見られたらヤバイのできちんと書かないでおく)。 このホラブルなインターフェイスはなに?
ボゴシティ! ブルシットネス!!
CHARS_KANSUJI = {
u'0':0, u'1':1, u'2':2, u'3':3, u'4':4,
u'5':5, u'6':6, u'7':7, u'8':8, u'9':9,
u'０':0, u'１':1, u'２':2, u'３':3, u'４':4,
u'５':5, u'６':6, u'７':7, u'８':8, u'９':9,
u'〇':0, u'零':0, u'一':1, u'二':2, u'三':3,
u'四':4, u'五':5, u'六':6, u'七':7, u'八':8,
u'九':9, u'十':10, u'百':100, u'千':1000,
u'万':10000, u'億':100000000, u'兆':1000000000000L,
u'京':10000000000000000L,
u'壱':1, u'弌':1, u'弍':2,
}
CHARS_IGNORE = u'，、,'
def parse_chnum(s):
(n1, n2, n3) = (0, 0, 0)
for (i,c) in enumerate(unicode(s)):
if c in CHARS_IGNORE: continue
try:
digit = CHARS_KANSUJI[c]
except KeyError:
break
if digit < 10:
# n1: "〇", ..., "九"
n1 = n1*10 + digit
elif 10 <= digit and digit < 10000:
# n2: "十", "百", "千"
if n1 == 0:
n1 = 1
n2 += n1 * digit
n1 = 0
elif 10000 <= digit:
# n3: "億", "兆", "京"
n3 += (n2+n1) * digit
(n1, n2) = (0, 0)
else:
i += 1
return (i, n3+n2+n1)
新山は if のあとに break や continue を書くときは、 インデントせずにそのまま右につなげて書く。この例ではうまくいっていないが、 こうすると break や continue がピョコンと右にはみ出て、 そこからループの終端までひとっとびであることが見た目にわかりやすいのだ。 つねに制御構造が視覚的にわかりやすいコードを書こうとしているのだけど、 それはいつも可能なことなのかはわからない。
Python の宣伝文句をもうひとつ思いついた。「目にやさしい言語」というものだ。 あきらかに Perl や Ruby は目にやさしくない。
ちなみに新山が Ruby を嫌いな根本的理由というのは、目にやさしくないことよりも、 「節操がない」からである。Perl と Python の間にはあきらかに思想的な差異が存在し、 これらの言語をスイッチするときには (大げさな言い方をすれば) 考え方を変えなければならない。 それはデータ構造の設計とかそういうたぐいの考え方ではなくて、ある意味、 Perl と Python ではプログラミングに別種の「覚悟」とでもいったものが必要になる。 しかし、Ruby はこの 2つと比べると とくに明確な設計理念といったものはなく (しいて言えば「オブジェクト至高を徹底させる」 ということくらいだが、これはメリットにもデメリットにもなるし、実用性とは 直交する概念なので無視する)、はっきりいえば、何の思想もないように見える。 「思想」という言葉がおおげさに聞こえるとしたら、「覚悟」と言いかえてもいい。 したがって、なぜ Ruby を使うのか? という理由は、「ここがこれと比べてこう書けるから」的なこまかい機能的な差異の 列挙に終わる。実際おそらくほとんどの人は Ruby を Better Perl としてしか 使っていないだろう。そういう人は言語の機能だけに興味があって、その根底にある 考え方はどうでもいいと思うのかもしれない (あるいは、そもそも技術の中に思想が 存在しているということに気づいていないかだ)。が、オレはどうも作者の考え方が 端的に現れている道具のほうが好きらしい。qmail を使っているのも そういう傾向を反映しているといえる。逆に、つねに中庸でありたいと思う人にとっては Ruby のような思想のない言語のほうがいいのかもしれないが、Ruby は 中庸というよりはむしろ無節操に見える。そもそも、言語に中庸なんてものはありえないのだ。 “技術者は技術力を持ってその思想を証明しなければならない”。 プログラミング言語では、技術 = 機能と読みかえることができるだろうか。 言語がそういった思想から完全に独立できると思っているやつがいたら、 そいつはかなりアホだ。自然言語もまた同じ (もっともこのことは、新山は最近まで わかっていなかったのだけれど)。
しかしそう考えると、Ruby が日本で流行ったのはその無色さも関連しているのかもしれない。 なぜなら日本では個人が自分で自分の思想を考えだすことは法律で禁止されているので (他人から借りてくるのは許される)、つねに無思想的な「誰からも嫌われない」ものが 好まれるのである。そういったものが人気を博そうとすると、だいたい「いいとこどり」「多機能化」に終始するね。 しかし機能をいくら足しても決して近づけない場所というのがあり…あるいはこう考えることもできる。 思想は機能をつけ足すことによって表現できるのではなく、 機能を削ることによって表現されるものなのではないか? なにを足しなにを足さないかというところにかなりのウェイトがあるような気もするが、わかんない。 言語にかぎらず、日本製品に「よくできている」ものは多いが、 それもこうした傾向のあらわれなのか? 「よくできている」からといって「よい」とはかぎらない。 「よくできただけ」のものでなく、真に「よいもの」を作るためには、 なにか技術や機能とは別のものが必要なように思えるが、いずれにせよその判断にはかなりの 主観を含むことはまちがいない。それが思想ということなのだろうか? じつにアイマイだ。 とにかく、今のたいていの日本人は (新山をふくめて) そういった主観的・個人的な方向に 踏み込むのを怖れるので、いつまでたっても「いいもの」は作れそうにない。昔はどうだったか知らない。 技術大国の日本かもしれないが、ある意味「技術だけ大国」の日本だ。 まあ、これからもずっとそうなんだろうなあ。そして心中国家。
おとといあたりから、また WTC 跡地で 2本の光の線が空に向かってのびている。 しかし最近はこのところ曇ってるので、光はあんまり高くまで到達しない。 ま、どうでもいいけれども。
>>> parse_chnum('千六百四十万二千四百四十壱円也')
(13, 16402441)
>>> parse_chnum('五、六七〇、〇〇〇、〇〇〇年')
(13, 5670000000L)
>>> parse_chnum('二億四千万の瞳')
(5, 240000000)
うまいのものは早く喰え、と。