研究室の

diary

Wiki に書いてたんだけども、
物理学会の予稿は http://ci.nii.ac.jp/vol_issue/nels/AA11439205_ja.html から見られる。
先輩や先生から見せてもらうのってもいいんですけどね。

しかし、Web から一般公開されているわけなので、下手なこと書けないわけですね。
普通の人は見ないけども。

いまだに、

diary prog

プログラミング言語の機能なんてものがもてはやされるのは理解できない。
だいたい、原理的にできることは同じなんだから新機能なんかよりも犯しやすいミスを防ぐ、読みやすいコードを書くといったような制約を課す方がよっぽどまともに思える。

そういう機能の無節操さというのは黎明期にはありだけど、一体いつまで黎明でいる気なのか。
結局、これって地道な作業を嫌ってついつい新しいことをやりたくなるっていうアレじゃないのかよ、と思う。

そういう意味で PEP 3003 -- Python Language Moratorium | Python.org ってのはマトモにみえるわけです。

紆余、曲折を経て、

diary

たぶん、これでほとんど仕上がったはず。

久しぶりに、C 言語で書いたもんだからいろいろ忘れていたりした。
例えば、

void do_something(struct spam* s, int N){
    for(int i=0; i<N; ++i)
        (s+i)->member = i;
}

みたいなのにひっかかった。なんという基本的なところだろう。

あとは assert を書きまくった。
こういのを offensive programming っていうんだっけ?
C99 は例外も使えるらしいが、assert で十分だと思ふ。

あとはメモリ使用量。
Mac Pro だと少なくとも4GB×8枚の32GB までは載せられるはずなので 、
潤沢なメモリで計算できるはず。

あとは速度面の改善とかもあって並列化もしないといけない、でもこれは簡単なはず。
メモリ使用量と速度でいくらか書き方のヴァリエィションが存在しうるので、
あとは、branch を作っておくべきかね。

こういう速度測定には、Shark が使えるので便利だわね。

あれだけ、C++ をばかにして C で書くといっていたけど、
使っているのは C99 だったりするのは許されたし*1。

でも、C++ で実現したいと思える要素なんてものは全く無い。

*1: for(int i=0; i

つかまらない。

diary

ので、復習してして考えてみる。やっぱり間違ってますね。
結局自分で考えたやつでやったやつでよかったというのは悲しい。
ので、御利益ありそうな方法をさぐる。

ちゃんと御利益はありそうですね。計算過程が若干減らせるし、
前のアルゴリズムの微妙な点を補える。
しかし、ミスが教科書レベルで泣ける。