Emacsでも表示しているテキストの各行の左側に行番号を表示させることができたはず…と思って調べた。
こちら(*1)にあるように、.emacsに以下を追加して、M-x linum-modeとするだけ。
(require 'linum)
Wikiの説明をパクって、以下のようなフォーマットを追加してみました。
(setq linum-format (lambda (line)
(propertize
(format
(let ((w (length (number-to-string (count-lines (point-min) (point-max))))))
(concat " %0" (number-to-string w) "d ")) line) 'face 'linum)))
空白桁が0で埋まって表示されます。
*1 http://www.emacswiki.org/emacs/LineNumbersLinux環境でワンセグチューナが使いたいなーという欲求を満たさんと、ログファームLOG-J100Mを入手しました。いろんな意味で話題になっていたUSBワンセグチューナで入手が困難だということでしたが、先週にヤフオクで出品されていたものを運良く想定範囲内の金額で落札することができました。
かなりの感度の悪いデバイスとの評判で、どう動作確認すべきかと懸念しておりましたが、こちら(*1)を見てUOT-100のVista用ドライバとアプリケーション(*2)をインストール。あっさりと動き、普通にTVが見れています。どうもうちは電波が良く入るみたいです。
目標は家の近所の食事処でTVを見ることなのですが、野望にだいぶ近づいてきた感じです。
*1 http://kuromaru-digital.blogspot.com/2008/02/log-j100.htmlUbuntuのGNOMEデスクトップの隠し設定が簡単にいじれるUbuntu Tweak(*1)というのを導入してみました。
インストールの仕方はこちら(*2)を参考。あいかわらずインストールしただけで、全然いじってないorz
*1 http://ubuntu-tweak.com/以前にnumpy.fromfileを使ってファイルをseekしてからデータを読むことができない、などと書いてしまいましたが、できました orz
with open('foo.data','rb') as f:
f.seek(128)
data = numpy.fromfile(file=f, count=1, dtype=dt)
やっぱり勉強不足だ orz
会場内のO'Reillyブースでこの本を眺めていて、ProcessingのAlternativeとして以前から興味はあったけどPython使えなかったので今まで手を出せなかったNodeBoxですが、先週からPython頑張っているので今ならどうにかなるのではないかと思い、インストールしてみました。
と言っても、NodeBoxはOSX専用ですので、現在開発中のNodeBox/Qtを指示通りにインストール。Ubuntuでのインストールはこちらに詳しいです。
問題なく動きますが、持参したAtom Z550な機械ではちょっと厳しいかもしれません。
当日券があると聞いてさらに悩んだ末、夜2時位に就寝、5時過ぎに起きて、新幹線に乗ってはるばる秋葉原へ行きました。お陰で、ここの所溜まっていた寝不足が更に厳しいです。会場ではRed Bull飲み放題で、4本飲んでどうにか眠気をやり過ごしました。今まで飲んだことはなかったのですが、なかなかジャンクな飲み物ですね。
講演者は予想通り凄い人ばかりで、十分に刺激になりました。特に某M社元会長様は自分の夢の実現への意欲がとても漲っていました。自分は既にいい加減いい歳にもかかわらず惰眠を貪る生活に現を抜かして過ごしておりますが、やっぱり頑張らないとと思いました。
予想通り若い人ばかりでしたが、まぁ開き直るしかありません。明日も頑張ります。
RD-Z1で録画したデータの整理をしていたら「HDDの状態が複雑になりました」メッセージが orz
ちまちまとアナログ番組に使用しているから出るべくして出たと思うけど…この忙しいときに orz
f2pyを使ってPythonで使えるモジュールをFortran90で書いていたのですが、例えば、
subroutine foo(a,n) integer,intent(in),dimension(n) :: a integer,intent(in) :: nみたいなサブルーチンからf2pyでモジュールbarを作成して、
import bar a = numpy.array([1,2,3,4]) bar.foo(a,a.size)みたいに呼び出す所を間違えて"bar.foo(a)"としても、サブルーチン側にはちゃんと配列の大きさが渡っているのに気が付いて不思議に思っていました。
こちら(*1)を見てモジュールbarの__doc__を確認すると、
This module 'bar' is auto-generated with f2py (version:2_5972). Functions: foo(a,n=len(a))という風なインターフェースが作られていることが判ったのです。
ちょっと安心。
*1 Writing fast Fortran routines for Python基本的に引き籠り系のねこさんですが、最近は年に１回位は何かしらイベントを覗きに行って、元気な人から刺激を貰うように心掛けていまして、今年は頑張って(主に金銭面で。それと月曜の午前中にプレゼンがあるけど、まだ準備できてない…とか orz)みようかとこちらのイベントに行くか行かないかギリギリまで悩んだ末にポチッた所…クレジットカードの承認が何故か通らなくて、そのまま時間切れ orz
週末どうしようかなー orz
Core Duo 2GHzなPCにはSpazを入れてtwitterしていたのですが、Atom Z550なNote PCにはかなり重すぎです。で、どうしようかと思っていたのですが、試しにGwitter(寝ぼけてました orz)Gwibberを使ってみることにしました。
ちょっと使ってみた所では起動も軽くていい感じです。不安定みたいな事も書かれていますがどうでしょう？
こちら(*1)を見ながらMercurialのcgiインターフェースを用意したのですが、アクセスするURLにcgiファイル名が見えるのが微妙に気になっていました。
たまたまこちら(*2)をお見かけしたので試してみましたが、どうもうまく行きません。やけくそになりして、cgiファイルに追記する内容のうち、
os.environ['SCRIPT_NAME'] = os.getenv('SCRIPT_URL')[:-len(os.getenv('PATH_INFO' , ''))]にしたところうまく行きました(あたりまえ？)。
↓
os.environ['SCRIPT_NAME'] = 'cgiファイルのあるURL直書き'
前エントリでndarray使いながらPsyco使うと微妙…なんて書きましたが、良く良く見ると、ちゃんと処理速度上がってる！
…あれって思って、一番最初に書いた全然工夫してないコードにPsyco付けたらめちゃめちゃ処理速度高い！ → さすがにそれは言い過ぎ(勘違い…システムサイズを間違えてた orz)でした。
もうこれでいいです。 → やっぱりf2pyで書いた方がそれなりには速いです。でも、今評価しているコードではPsycoだけでf2pyのコードと比べて0.7倍程度の処理速度でしたので、元がndarrayを使ったPythonコードだと思うと驚くほどに速いです。
Scipy.weaveやらF2Pyを使って計算の高速化を試みていましたが、モジュールによるJITコンパイラ実装であるPsyco(*1)を試してみました。
こちら(*2)にあります様に、psycoのimportとfull()メソッドの呼び出しだけで使える様です。ご利益の方ですが、importしているモジュール内のメソッドには反映されないので、ndarrayをコンテナに使っているプログラムでは効果は薄いですね。それでも30%以上は速くなりました。
*1 http://psyco.sourceforge.net/こちら(*1)で複数リポジトリへの対応の仕方を見つけたのでやってみた。
hgweb.cgiではなくてhgwebdir.cgiを使う、リポジトリの設定はhgweb.configに書く、などの他はこちら(*2, *3)と大体一緒。リポジトリを増やすときは、
大分イメージが掴めてきた。
*1 http://www.proton.jp/main/programming/mercurial.htmlScipy.weaveも良いけどFortranで計算した方が速かったりしないかな？という疑問を解決すべく、f2pyも使ってみました。
やっぱりそれなりに落とし穴がありまして、f90で書くときは変数宣言時の精度指定にkind(0d0)みたいな書き方をするとこけます(参考 *1) orz
あとintent(out)とか指定して、
[f77]Python側でfoo(x,y)と呼び出すと「引数が多すぎるで」と怒られます(参照 *2)。
subroutine foo(x,y)
real,intent(in) :: x
real,intent(out) :: y
y = 2d0 * x
end
[python]みたいに値を受け取らなければいけないようです。ちゃんとここいら(*3)を読んでからやるべきだったかも知れません。
y = foo(x)
肝心の計算速度ですが…ちょっと速くなりましたが、正直どっちでもいい感じです。
*1 http://cens.ioc.ee/projects/f2py2e/FAQ.htmlと言う訳(？)で、Mercurialを導入してみることにした。以前から興味はあったのだけど、一人でコード書いていてVersion Controlを使いたいと思うことが少なかったこともあって、マジメに使おうとは思っていなかった。
さくらを使っているので、情報がちょっと古いけどこちら(*1)とこちら(*2)とこちら(*3)を参考にインストール。
動作確認まではした…けど正直使い方がまだよく分かってない orz
*1 http://d.hatena.ne.jp/umezo/20080320/1206015911朝起きて評価し直してみたら、やっぱりweave使った方が速かった。システムサイズを大きくすると、オブジェクトやコンテナのコピーを避けて計算させるのはやっぱり難しい。
コードをブランチさせるかな、どうしよう。
ndarrayコンテナを添字付きアクセスするときはa[i,j,k]の様に書きます。a[i][j][k]でも動きますが、オーバヘッドが掛かります。とは言っても、添字付きアクセス自体が重すぎですので、なるべくは添字付きアクセスはしない方が良いです。
あと部分配列を取り出すのはa[i1:i2,j1:j2,k1:k2]の様に書きます。この場合、a[i1:i2][j1:j2][k1:k2]はまったくの間違いです。うろ覚えで書いていて、いろんな意味で時間を失いました orz
Scipy.weaveなど試してみたりしましたが、結局どういうふうに着地したか…と言いますと、実はインラインコードは採用しませんでした。何故ならば、ndarrayコンテナをうまく捏ねくり回して計算した方が速くて綺麗だったからです。インタプリタだと思って侮っていました。Python+ndarrayほんと良くできてます。
とにかくまずこのあたり(*1)を勉強した方が良さそうです。これら(*2)を勉強するのはもう少し後にすることにします。
*1 http://www.scipy.org/Tentative_NumPy_Tutorial
