enbug diary

_ 三桁毎にスペースを挿入する正規表現の続き

結局「他で余計な処理を加えず」「一つだけで」という条件だと、 znzさんのアイデア が最適なんですけど、 バグがあるんですよ、これだと。

>>> re.sub('(\\d{1,3})(?=(\\d{3})+(\\.\\d*)?$)(\\d{3}(\\.\\d*)|)', '\\1 \\4', '1.12345')
'1.12 345'

じゃあ、これを解決できるかというと、 私にはさっぱり良い考えが浮かびません。 変な所にスペースが入る方法なら私も考えたんですけど、 それはちょっと。

というわけで、結局駄目っぽいということで。

ちなみに、正規表現でしこたま頭を悩ませた後で申し訳ないのですが、 Pythonだと適当に書いた方が五倍は速いです。 使ったスクリプトは以下の通り。

import re

rexp_fp = re.compile('(\\d{1,3})(?=(\\d{3})+\\.)')
rexp_d = re.compile('(\\d{1,3})(?=(\\d{3})+$)')

def convert(s):
  if '.' in s:
    return rexp_fp.sub('\\1 ', s)
  else:
    return rexp_d.sub('\\1 ', s)

def test():
  assert convert('1234567890.12345') == '1 234 567 890.12345'
  assert convert('1234567890') == '1 234 567 890'
  assert convert('1.12345') == '1.12345'


if __name__=='__main__':
  from timeit import Timer
  import re
  t = Timer("test()", "from __main__ import test")
  print t.timeit(10000)

def convert(s):
  a = s.split('.')
  t = a[0]
  b = []
  while len(t) > 3:
    b.append(t[-3:])
    t = t[:-3]
  b.append(t)
  b.reverse()
  t = ' '.join(b)
  if len(a) == 1:
    return t
  else:
    a[0] = t
    return '.'.join(a)

def test():
  assert convert('1234567890.12345') == '1 234 567 890.12345'
  assert convert('1234567890') == '1 234 567 890'
  assert convert('1.12345') == '1.12345'


if __name__=='__main__':
  from timeit import Timer
  import re
  t = Timer("test()", "from __main__ import test")
  print t.timeit(10000)

_ ダカール

企業秘密やら何やらでだんまりを決め込んでましたが、 一ヶ月ほどダカールに滞在してきました。 私にとってはアフリカ大陸初体験だったのですが、 元植民地だけあって、セネガルはフランスの影響がものすごい。 一言で言ってしまうと、金のないフランスというところでしょうか...

ダカールの中心地に居ると、 非アフリカ人、すなわち白人やアジア人、要するに、 現地人が金を持っていると思い込んでいる人種には極めて居心地が悪いです。 金を貰おうと待ち構えている連中がわんさといて、 全くこの手合には閉口してしまいます。 一人や二人ならともかく、四六時中「私の友達」攻撃を受け続けると、 精神的に参ってしまいます。

それを別にすると、街は思ったより汚くない。 デリーなんかと比べると、まあ同程度ですかね。 運転マナーは若干マシ。

大体は黒人で、アラブ系もかなり多い。 白人も割と見かけるけど、 フランス人がやっぱり多い。 アジア人は、中国人が集まっている、いわゆるチャイナタウンを除外すると、 まるで見かけることがない。 休みに出掛けたゴレ島では日本人の集団に遭遇してしまったけれど... 多分ダカールには JICA の人ぐらいしか、日本人はいないんじゃないだろうか。

天気は猛烈に良くって、 二月や三月だというのに、 毎日晴天、気温は日中28度前後でした。 帰ってきたらパリは-2度とかで恐れ慄いてしまいましたよ。 ただし、最後の一週間ぐらいは harmattan のせいで一日中どんよりしてました。

物価はさすがに安い。 輸入物は同じだけれど、 そうでなければ大体四分の一ぐらいか。 毎日外食しても平気で、 私の給料でさえセネガルだと金持の部類に入ってしまう。

ちなみに写真は毎日窓にやって来た鷹です。 なかなかキュートです。 雄か雌かは不明。 毎朝日が登ると凄まじい音量で鳴いてくれるので、 当初は目覚し時計が要らないと喜んでましたが、 やがて撃退方法をラーニングしてしまったので、 用をなさなくなりました。 窓を叩くだけでは駄目で、 顔を見せて叩かないと逃げてくれません。 ちょっと面倒だけど慣れると簡単です。

ああ、後、セネガルには魚欲しさに日本政府が人と金を送り込んでいるだけあって、 海の幸に恵まれています。 The fishes of Senegal にいろいろ載ってますけど、 その辺のレストランで頻繁に供されるのは現地語でThiofと呼ばれている奴で、 ホワイト・グルーパーとかいう名前らしいです。 これじゃやっぱり何のこっちゃか分からないのですが、 要するにハタの一種です。 良いレストランで食べるとめちゃくちゃ美味しいです。

他にもいろいろあった気がしますが、 かなり忘れてしまいました。 そのうちまた気が向いたら行くかもしれません。

_ An Open Source Tax Credit

オープンソースに寄与した人は税制上の優遇措置（控除）が受けられるようにしようという話。 前にも似たようなのを見た気もしますが。

ヨーロッパだと開発者の多くは学生（＝無収入）なので、 どの程度の意味があるかは謎ですけど、 あったらいいですねえ。 この記事はUS向けですが、 フランスとか日本でもこういう動きがあっていいと思います。

_ スクリプト言語はコンパイラ言語より遅いのか？！

とある学生と話していて感じたこと。 彼はC、C++、Java等の経験しか今までありませんでした。 最近Pythonをかじり始めましたが、 彼は「Pythonはスクリプト言語だから遅い」と主張しました。 私は猛然と否を唱えました。

そもそもどっかの誰かが主張していることを自分で確認しないで信じている時点でアレなんですけど、 あまりに見方が単純過ぎるというのが私の観点。

私の主張を要約すると、

• コンパイラは所詮線形にしか高速化しない（ベクトル化してくれるとか、そういうのは置いといて）。
• いくら言語の平均的実効速度が高速でも、アルゴリズムが間抜けだと、スクリプト言語で賢く書いた方が速い（これは簡単に証明できる）。
• 概してコンパイラ言語（特にC）は機能が貧弱なので、まともなプログラムの規模になると、非常に開発効率が悪い。
• 開発効率は実行効率に間接的に影響を及ぼす。プログラムを改善するスピードが異なるならば、当然開発効率の優れた言語の方が速いプログラムを生み出しやすい。
• 現実問題、この世界の移り変わりは非常に速いのだから、開発時間がそもそも短い。
• よって、開発効率の良いスクリプト言語の方がコンパイラ言語より実行速度においても優れている可能性は決して無視できない。

理論的に速いからといって、現実にも速いとは限らないんですよね。 書きにくい言語できれいなプログラムは簡単にはできないですから。

まあ、それは別にしても、Pythonには pypy なんて試みもありますし、 将来本当にスクリプト言語の方が決定的に速いという状況が生まれる可能性も否定できないと考えています。

追記： shiroさんのコメント について。 おっしゃることは全くその通りです。 議論した相手が相手だったので、 言葉の定義は適当です。 ここでは一般的に「そういう言語だと捉えられているもの」ぐらいに考えていただいた方が良いです。 もう少し厳密にするならば、動的言語、静的言語といった呼称の方が似合っているかもしれません。

境界の曖昧さは私は以前から認識しています（というか、境界の明確な言葉の定義の方が稀じゃないかな）。 実際Cで書いたからといって、 全てコンパイル時に決定されるわけではありませんし。 単純なプログラムでさえ今日では動的リンクなど、インタープリタ的動作が介在しますし、 結局多くのインタープリタはCで書かれています。 JavaやPythonのようにJITをサポートしている言語もあれば、 CommonLispやHaskellのように両対応している言語も存在します。 結局はどこまで動的にやるのかという問題でしょう。

psycoやpypyのように、とりあえずインタープリットしていって、 （やる価値のありそうなところを）実行時情報に基づいて複数バージョンをコンパイルしていくというアプローチは面白いと感じています。 ただ、GCCなんかは最近プロファイルによる最適化や関数を跨いだ最適化なんかをサポートしているので、 コンパイルに膨大な時間を費しても文句を言われない言語の方がより強力な最適化を施しやすく、 そう簡単には勝てないだろうなと思います。

まあ、いずれにしても「開発効率こそが重要である（場面も多々ある）」という私の主張には影響しないんですけどね。

_ UNILOG reaches Major Milestone in Open Source ERP5 Implementation in Infoterra´s TerraSAR-X Commercial Service Segment

どうもこの手のニュースはギークに受けが悪くて、 なかなか取り上げてもらえなくてエラい苦労しました。

まあ、それで思ったんですけど、無料で宣伝してもらうのは難しいとか感じるけど、そもそもそういうことが可能になったのって、随分最近の話なんですよね。 ウェブのおかげで特にジャーナリストの御世話にならなくても、自分ところから不特定多数に発信できるってすごいよなあ、と。 でも誰でも見られるっていうのは、誰もが見てくれるとは等価ではないので、 やはり購読者の多いメディアを握っているところはあいかわらず強くて、ウェブがあるからと言って、そういうビジネスが廃れることは無いのも面白いですね。

_ Intel Mac Mini

非常に魅力に感じたものの、値段を考えると少々気が引けてしまったので（とか言うと、昔の値段を覚えているのか！とか突っ込まれそうだけど）、 とりあえず上手い方便を考案して、会社に買わせてしまいました。 それでこれは本当にいいじゃんと感じたので、 改めて自分用に自腹で買ってみることにしました。 目的はGRUBを移植したいってだけなんですが...

しょぼいブートローダがあいかわらず乱造されている現状を見るに、どうも放っておけない気分になってしまうのです。 純粋に新しいものに好奇心がむらむらってのも大きいですけどね。 フランスのアップルさんは発注処理がかなり遅いらしいので、まあ気長に届くのを待つことにします。 それからどれぐらいのスピードで移植できるかは乞う御期待ってことで。 EFIは未経験だし、MacのEFI実装はかなり癖がありそうなので（El Toritoはサポートしないとか）、当面は手探りになるでしょう。 gnu-efiのドキュメントによると、PE32+周りは嫌らしいようなので、ブートストラップをどうやるか真剣に考えなきゃいかんな。