KazuoMoriwaka/Journal/2006-10

• 誕生日

• 30才になりますた(‥)ノ

• 読書

• Alertbox

• ヤコブ・ニールセンのalertboxが書籍化。すばらしいサイトなのでお布施として購入

• アート・オブ・プロジェクトマネジメント

• よみかけ

• かなり具体的でよい

• ローマ人の物語(27,28)

• ハードカバーの10巻相当

• 一巻まるまるインフラ！

• コマンドラインから wikipedia をひくためのしょぼいスクリプト

  1 
  2 
  3 
  4 
  5 
  6 
  7 
  8 
  9 
 10 
 11 
 12 
 13 
 14 
 15 
 16 
#!/usr/bin/env python

import os
import sys
import urllib

lang = 'ja'
if len(sys.argv) != 2:
    print "usage: %s keyword" % sys.argv[0]
    sys.exit(1)

word = sys.argv[1]
word = word.decode('eucJP')

os.execlp('w3m', 'w3m', 'http://%s.wikipedia.org/wiki/%s' %
          (lang, urllib.quote(word.encode('utf-8'))))

• 読んだ漫画

• ちまちま

• これは、噂以上にはずかしい。。

• 布団の上でのたうちまわりながら読みましたょ

• 仕切るの？春日部さん(1、2)

• アホエロ。アホすぎ。

• 家が買えるまでが遠足です。

• 校長はイタすぎ。。

codegolf

• http://codegolf.com/

• 先週末の3連休にあそんでました

• いくつかお題があって、規定の範囲でそれを実装する。短い方が高得点。

• 対象言語はPython,PHP,Perl,Ruby。

• import/require/useなどのモジュールとりこみ禁止。

• 各問題ごとに、(自分のコードのバイト数/一番短い人のコードのバイト数*10000) がポイントになる。

• 4秒以上実行時間がかかるとタイムアウトで失敗と見做される。

てなわけですが、Pythonはめっちゃ不利です。。

• 文化的に「短いコードより読みやすいコード」 という精神が強烈にあるので誰も短く書くテクニック(ああ！なんて罪深い！(笑))なんてまとめてない

• print は p より4文字長い(50から 200バイトくらいの問題では結構効く)

• import禁止なので、モジュールをimportせずに使える超基本的な操作しか使えない。。

• 普段はどこの何を使っているか一発でわかってしあわせなんですが。つらい。

• pythonの組み込み機能って、組み込み型の操作とlibcから文字列操作関連削ったくらいしかないので。。

• socket開くのも正規表現もmathも、pack/unpackもつかえない。。

とりあえず現状の順位はpython限定でで16位/53人、overallで81位/291人。

微妙なPythonむけバイト節約ノウハウ。普段のコードではマネしちゃだめです。制約条件内で 短くするというパズルとしてだけおたのしみください。。

• x==1のときだけ空文字列 '' を 返し、x!=1のとき 文字列'foobar' を返すには?

•  (x!=1)*'foobar' 

• print 'foobar' のように区切り文字があれば、区切り文字直前のスペースは省略可能

• 先頭に #coding:latin と書けばバイナリ列をソースコード中に自由に書けます。

• 下手にエスケープするより三重の  """hoge"""  引用符で囲うほうが短い場合も多い。

• リスト内包表記つかいまくれ！

• 1文に納まるなら  if xx:  のあとは同じ行にできる。

• インデントが必要でなければ複文の ; は使わなくてもまあOK

• CR+LFで改行すると損なのでUNIX式にしとけ

リストの内包表記の実行速度はC言語並み？ という記事が あったのでちょっとベンチマークとってみた。

Celeron2.7GHz メモリ1GB Debian sidな環境で実行。20回試行した平均。

• origは元のプログラム。

• xrange は for に書かれている range(num) を xrange(num) に変えたもの。

• xrange,1 は、上に加えてリストの要素 (x,y) を単なる整数の 1 に変えたもの。

• *2.3/2.4/2.5 はそれぞれPythonのバージョン 2.3.5, 2.4.4, 2.5 に対応。

• 引数は1000を与えた

• 数字は1回あたりの実行時間をあらわし、単位は秒

この結果からわかることは

• ループ内の処理が割と小さいxrange,1 では 同じバージョンでリスト内包表記とforループを比べるとリスト内包表記のほうが速いようだ。

• 100万回のループで50msecから60msec程度。

• 注: res.appendの呼び出しが遅いだけかもしれない。

• 元のコードではリスト内包表記のほうが常に遅い。

• Python処理系のバージョンがあがるに従ってどちらも高速化されている。

• このような単純な例ですら、ループ処理の形式よりループ内で実行される処理のほうが支配的。 つまり実用上は(実行時間最適化をしようとしているときですら)常にループの形式による速度の差は2番手、3番手の関心事になる。

• 例: range を xrange にするだけで230msecから470msec程度、ループ形式の違いより1桁大きい。

• 自作のベンチマークルーチンでは対象関数を20回連続で実行するため、このrangeとxrangeの大きな差はGCの処理量にあるのかもしれない。

結論: リスト内包表記にしろforにしろ気になるほどの違いはないので、その場の意図が伝わりやすい書き方を選択するべき。

補足: 現状のdebianにはpython2.5用のpsycoがないため省略したが、psyco を利用することで orig で for_comp2.3: 0.277, list_comp2.3: 0.279 となった。速度が問題になる際にはまずpsycoの利用を考えるべきだろう。

  1 
  2 
  3 
  4 
  5 
  6 
  7 
  8 
  9 
 10 
>>> 2-2
0
>>> 2--2
4
>>> 2---2
0
>>> 2----2
4
>>> 2-----2
0

MoinMoin Powered