2008年12月

メール確認したら昨日の時点で返事来てたー．けど，続きの作業は東京に戻らないと無理だなぁ．ま，来年に持ち越そう．

途中下車可能な切符なので二宮で降りてすぐ近くの吾妻山公園に行ってみた．名前に山が入っているだけあって急な階段を長く登らされたけれど頂上には菜の花が咲いてたり富士山と相模湾が良く見えたりと登る価値はあった．家族連れとかカメラ持ったやつとかそれなりにおったし．

130Bから縮まない．相変わらず数字をディクリメントする部分が長すぎる．入力に特化してしまえばもう少し縮まる気もするけれど…　負けだよなぁ．

それはさておきそろそろ帰る支度をするか．

GarminのGPS用の地図を管理するMapSourceのバージョン上げたらC++ runtime errorとか叫んで起動しなくなった．色々と試しても問題解決できないのでしゃーないバージョン下げるかと思ったら，今度はGarminのサイトで古いバイナリが見つからない．で，しょうがないので MapSource old version とかで検索かけたら同じようなことで悩んだどっかの掲示板に http://www.gpsinformation.org/perry/msource/ で入手可能と書き込みがあった．なんで Garmin は最新版のバイナリしか置かないのだろうねぇ？　エラーで落ちまくる最新バイナリよりとりあえず動く古いやつのほうが利用価値が高いのに．

もやしもん７巻限定版についてたオリゼーのブロックフィギュアを組み立てた．

よく知らんけどナノブロックとやらで普通のブロックよりも小さいらしい．普通って何だろう？　どうせならあと1/4位になってくれれば良いのに．

出来上がるとこんなもんらしい．ちなみに頭の中は空洞．さてどこにおこうかな、と．

とはいえクリスマス＋年末年始では連絡来ないだろうなぁ．問答無用でコミットしてしまおうか？

フォトマスターという意味の無い検定を試しに受けたら合格した（１級）．試験前日が論文の締切日とかいうあほな状況だったので一夜漬けすらしてないのに…．

１．カメラを持つ姿勢が悪い

２．環境がゆれている（地面が揺れている，風が強い）

３．接触している隣の他人が揺らしている

えーと，左右にいくらでもスペースあったろうに，同じところから撮りたいのは分かるけど密着して徐々に押してくるのはどうかと思うよ．

先に行ったのがカレッタ汐留．よく知らないけどBLUE OCEANというタイトルで「総合プロデュースは今年3回目となる、雅楽師で作曲家の東儀秀樹氏。」とのこと．確かに波っぽく立体的なイルミネーションになっている．が，そんなことより人が多すぎる…

TAMRON SP AF28-75mmF/2.8 XR Di LD Aspherical [IF] MACRO

ちなみに真ん中辺りにある塔には鐘が付いていて，その鐘を鳴らして記念撮影するため行列が出来ていた．並んでいたほとんどはカップルで，時々子連れの家族がいるくらい．一度だけ男一人っていうつわものもいた．

SONY 135mm F2.8 [T4.5] STF

次に丸の内．いくつかの通りに街路樹のイルミネーションがあったけど無視．皇居外苑の和田倉噴水公園にあるアンビエント・キャンドルパークへ．本当にろうそくなのかは分からんけど灯篭っぽくて良い感じだった．

TAMRON SP AF28-75mmF/2.8 XR Di LD Aspherical [IF] MACRO

一つ一つには平和とかに関するイラストやメッセージが描かれている．有名人と小学生(?)が作ったらしい．

SONY 135mm F2.8 [T4.5] STF

最後に東京タワーが見えたのでパシャ．クリスマスモードなのだろうか？

SONY 135mm F2.8 [T4.5] STF

これまでの設定だとあるサブカテゴリに属する過去の記事だけを見る方法がなかったので、過去の記事を自分で参照するのに不便だった．ということで，ページスイッチを付けてくれるNP_ShowBlogsを導入した．これでサブカテゴリの過去の記事も楽に見られる．

現在の撮影枚数は11300枚位．このペースならシャッターユニットが壊れるまで５年位か．どうせ壊れるなら５年保証の期間内にして欲しいなぁ．これって自然故障だよね？

そしていつのまにやらレンズも増えていて…　使えるのは11-16/2.8, 28-75/2.8, 50/1.8, 90/2.8, 135/2.8(4.5), 400/5.6で，使わないのは 17-85/4-5.6, 70-300/4-5.6 とかいう状況．なんとなく論文一本書くとレンズが一個増えているような．そろそろ沼にはまってきている気がするのでまだ息が出来るうちちこれ以上沈まぬよう注意しよう．

とはいえ絶対に欲しいレンズってのが見当たらないからしばらくは現状維持でしょう．むしろ来年あたりにエントリークラスのフルサイズのマトモなのが出たらそれに飛びつきそう．

冷蔵庫に甘柿が入れっぱなしになってるけどそのうち干し柿になるよね．きっと．

見た目萎れてきたけど傷みが見られないのでこのまま入れ続けておこう．

Given a non-negative integer S, find non-negative integers I and J such that S = I*(I+1)/2 + J and J <= I.

さてどうやるのが一番楽なのか？ 定数コストでやるにはSに対するIの推定値を出してからその値の前後で条件を満たすものを探せばよいのだろうけど…　美しくないなぁ．そしてなんとなく多倍長の割り算を思い出す．

ゆうちょでしばらく（４ヶ月）記帳してなかったらお取引履歴とかいう案内が郵送されてきた．たぶん，特定の行数分の未記帳データが揃ったときに発行されると思われるのだけど…．通帳側には合計しか表示されなくなるのでやめて欲しいなぁ．とくに記帳しようとしたタイミングとご案内の閾値を超えたタイミングが同じだと非常に残念な気持ちになる．

何でだろう？　なんか3.0系列にアップデートしたときから色々とおかしな挙動をしてくれてはいるのだけど…．そろそろプロファイルを一度クリアしたほうが良いのかもしれない．

マルチスレッドのときにスレッドごとに集計するにはどうすんだ？　それ以前に，C++だとインライン展開されるかどうかでプロファイルの精度が…？　一回ちゃんと復習しといたほうがよさげだな．

先週面倒なひとつに切りがついたので，前から欲しかったα-EFのマウントアダプタを作ってみた．日曜に大部分の加工を終えてたのをちょいと調整して今日完成．ただし，αのフランジバックはEFより長いとはいえ0.5mmしか差がないので，今回作った厚さ7mmのアダプタでは当然のごとく無限遠が出ない（STF135mmで3m弱程度までしか焦点が合わない）．でも着けられる本体のない状態よりはまし（着けられる本体がないのにレンズ買った馬鹿がいる）．

以下，作成メモ．構造はジャンクのマウント部分をつなぎ合わせるだけのもの．

マウント外された100-300とα7000とアクリル板の図：

マウントの金具にあわせてアクリル板にねじ穴を開けて中央をくりぬく．下の写真で見えている面がEF側にくっつく．裏はα側の金具が少し出っ張っているのにあわせて円盤の内側の肉厚が1.5～2mm程度になるように掘り下げておく．

後は組み立てる．タップがなかったのでねじを切らずに無理やり捩じ込む．下の写真はEF側を表にした状態．α側のレンズ取り付け位置のマークは，写真に見えているEF側のマークから少し右に回ったあたりになる（写真では１０時半の方向あたり）．

あとは，α7000から取ったロック用の金具をαマウント側にはめ込んで，アダプタの内側のほうから出し入れできるようにアクリル板を内側からちょっと削っておく．あと，絞りを開放にするためにてきとうな棒を付けておく（下の写真のマウント内右側）．何気にこの絞り開放のための仕掛けが一番面倒なきがする．

これにてアダプタ完成．金額は3000円くらい．作成時間（色々しながら片手間に）8時間くらい．

んで，試しに取った写真がこれ．信号と街灯だけど焦点合わないからぼけ～．でも綺麗にぼけ～てるので満足．

うーん，プラスチックのEFマウントにαのマウントを直付けしたほうが薄く出来るかも知れんなぁ．また今度試すか．

面倒だからと先送りにしていた事務的なものを全部処理．書類書くやら振込みやら電話やら…とやっていたら暗くなってた．

とりあえず年末までの振込みで賃貸契約の更新料が2/3になるキャンペーンしてたので数万円浮いたのはラッキー．浮いた金は何か買う．

どう考えてもミニルーター手持ちで垂直に何かを加工するのは無理．やっぱトリマー買うしかないかなぁ．つーかトリマーならアルミの加工も出来る気がしてきた．ちょいと調べるか．

昨日の飲み会でリキュールの話が出て気になったのでwikipediaした．とりあえずEU的には100g/Lの（残留）糖度の酒らしい．ドイツ語のwikipediaも同じことが書いてあるので正しいと信じる．日本国内の規定はめちゃくちゃ．

http://ja.wikipedia.org/wiki/%E3%83%AA%E3%82%AD%E3%83%A5%E3%83%BC%E3%83%AB

http://de.wikipedia.org/wiki/Lik%C3%B6r

で，トカイのワインなら５プットニョシュくらいでこの規定クリアできた気がするので調べてみたらクリアしてた．ドイツのワインだと残留糖度でなく発酵前の葡萄エキスの密度というか濃度というかの単位で計るので微妙だけど，TBAとかはきっとほとんどがリキュールの規定をクリアできるのだろう．

http://en.wikipedia.org/wiki/Sweetness_of_wine

http://en.wikipedia.org/wiki/Oechsle_scale

ということで，変な例外を除いて世の中のリキュールはほぼすべて砂糖とかを添加しているに違いない．

今年一番大きな満月らしいので望遠レンズで撮ってみる．1.4xを付けるとEOS Utilityからのピント調整が出来ないのでピント合わせは根性で．大気のせいなのか1.4xのせいなのかピントが合っていないせいなのか少々眠い．

EF400mm F5.6L USM + EF1.4xII + trimming-1200x1200

さすがに満月ともなると結構明るい．

TOKINA AT-X 116 PRO DX 11-16mm F2.8

116買ったので応募しておいたらでっかいバッグが届いた．抽選とか書いてあるけど応募者が少なくて事実上全員にプレゼントされているんじゃないかと邪推してみる．

ターミナルにフォーカスがあると思ってパスワードを打ち込んでリターン．次の瞬間，ターミナルの右にあったSkypeのチャット画面にパスワード出現．…いつの間にフォーカス移ってた？　いちおうメッセージ削除しておいたけど削除の伝播って変なタイムラグがあるからなぁ．ま，ばれて困るパスワードでもないし気にしないでおこう．相手は海の向こうだし．

OpenMPのプログラムが遅いのは全スレッドで大量にメモリのアロケーションを行うせいかもしれない．一斉にmapを大きくしだすからなぁ．MPIならメモリ空間が分かれているからアロケーションが速いのかも．とりあえずプロファイルとってみるか．

博打しなければ何も儲からないから博打したほうが儲かる．何かおかしいだろうか？

次の輪講用にMapReduceの例であるword countをMapReduceを使わないでMPIとOpenMPで実装しているのだが…．なぜかOpenMPの実装がMPIでの実装に比べてかなり遅い．所詮同じループし貸していないのに．

どうやら中間データをマージするローカルのループ部分で遅くなっているらしいけど，アセンブラ見ても同じようなコードなので何が遅いのやら．

写真とって下さいと一眼レフを渡されたのだが，視度調整が+側に振られていたようでファインダーのぞいてもピントの合致が分からない．とりあえずＡＦのを信じて適当に撮ったらピントあってたので良かったけど…．人に撮影を頼むなら画面見ながらピントあわせできるコンパクトデジカメの方が無難な気がする．

それにしてもUSから応答ないなぁ．

MPIで可変サイズのデータを通信するために boost::serialization を使おうとして，受信部に下のようなコードを書いた．繰り返しサイズ不定なデータを受信するので，バッファはvector<char>にしてサイズを楽に変えられるようにしている．そして，受信したデータの復元のためにバッファをistringstreamに包んでbinary_iarchiveに投げている．細かいことを気にしないと正しく動くように見える．コンパイルも通るし．

std::vector<char> buf;
for (int stage = 1; stage < procs; stage <<= 1) {
  // snip
  unsigned int s = 0;
  MPI_Recv(&s, 1, MPI_INT, target, TAG1, MPI_COMM_WORLD, MPI_STATUS_IGNORE);
  if(s > buf.size()) buf.resize(s);
  MPI_Recv(&(*buf.begin()), s, MPI_BYTE, target, TAG2, MPI_COMM_WORLD, MPI_STATUS_IGNORE);
  std::istringstream  is(&(*buf.begin()), std::ios_base::in | std::ios_base::binary);
  boost::archive::binary_iarchive bai(is);
  // snip
}

が，これを動かすとbinary_iarchiveのコンストラクタでbad_allocを食らって落ちる．なぜ？

しばらく頭も回らず原因が分からなかったけどよく考えるとistringstreamのeofが判定できないんじゃないかと気づく．そのせいでbinary_iarchiveがめちゃくちゃな量を読みに行くかなんかしてメモリ不足で落ちているのではないかと．

ということで，下のように書き換えたら動いた．でもstring作る分だけ無駄だよなぁ．どうすりゃいいんだろう？

  std::string str(&(*buf.begin()), s);
  std::istringstream  is(str, std::ios_base::in | std::ios_base::binary);
  boost::archive::binary_iarchive bai(is);

今から寝ると午前のセミナーに起きられない気がするのでライトアップされている銀杏を撮ってきた．

TOKINA AT-X 116 PRO DX 11-16mm F2.8

真夜中のくそ寒い時にも関わらずカメラと三脚持った人間が他にも数人．お疲れ様です．

とりあえず，スレッドサポートはMPI-2で初期化関数がMPI_Init_threadとなる．んで，こいつの第三引数に使いたいスレッドサポートレベルを投げる．その値は，MPI_THREAD_SINGLE（スレッドなし），MPI_THREAD_FUNNELED（メインのスレッドだけMPI使う），MPI_THREAD_SERIALIZED（同時には一つのスレッドだけがMPIを使用），MPI_THREAD_MULTIPLE（どうとでも使え）のいずれか．ということで，MPI_THREAD_MULTIPLEを投げておけば安全．でも実際にはサポートされていない場合もあるのが残念．

MPICHの1.2.7p1だと手元でコンパイルした限りではMPI_THREAD_FUNNELEDしかサポートしてないらしい（ch_p4, ch_shmem）．よって，メインスレッド以外でMPI通信しつつ，メインスレッドが別スレッドを寝て待つとかすると挙動不審になる．ときどきメインスレッドが起きるせいか，待っていると取り合えず動いてくれるように見えるときもある．ま，基本MPICH1でスレッド使うなと．

MPICH2のほうだと，ch3:shmとch3:ssmがMPI_THREAD_SERIALIZEDを，ch3:sockとch3:nemesisがMPI_THREAD_MULTIPLEをサポートしているらしい（少なくともconfigureで指定できる）．ch3:sockに関してはそれなりにスレッドでMPIをぐちゃぐちゃに使う下のプログラムでもちゃんと動いた．ch3:shmだと別スレッドがrecvで待っているときにbarrierとか叫んだときに動かなくなったりする．

ということで，MPICH2使えと．

#include <mpi.h>
#include <iostream>
#include <iomanip>
#include <unistd.h>
#include <pthread.h>
 
enum {
  TAG_1,
  TAG_4,
};
 
pthread_t thread;
int rank;
int procs;
 
void* thread_func(void* arg)
{
  std::cout << "[" << rank << ",t] entering thread_func" << std::endl;
  int d = 0;
  int target = (rank+procs-1) % procs;
  MPI_Status st;
  std::cout << "[" << rank << ",t] receiving form " << target << std::endl;
  MPI_Recv(&d, sizeof(int), MPI_BYTE, target, TAG_1, MPI_COMM_WORLD, &st);
  std::cout << "[" << rank << ",t] received form " << target << std::endl;
  d = d + 1;
  std::cout << "[" << rank << ",t] BARRIOR!!! " << std::endl;
  MPI_Barrier(MPI_COMM_WORLD);
  std::cout << "[" << rank << ",t] sending to " << target << std::endl;
  MPI_Send(&d, sizeof(int), MPI_BYTE, target, TAG_4, MPI_COMM_WORLD);
  std::cout << "[" << rank << ",t] sent to " << target << std::endl;
 
  std::cout << "[" << rank << ",t] exitting thread_func" << std::endl;
  return NULL;
}
 
void* main_func(void* arg)
{
  std::cout << "[" << rank << ",m] entering main_func" << std::endl;
  int d = rank;
  int target = (rank+1) % procs;
  MPI_Status st;
  std::cout << "[" << rank << ",m] sending to " << target << std::endl;
  MPI_Send(&d, sizeof(int), MPI_BYTE, target, TAG_1, MPI_COMM_WORLD);
  std::cout << "[" << rank << ",m] sent to " << target << std::endl;
  std::cout << "[" << rank << ",m] receiving form " << target << std::endl;
  MPI_Recv(&d, sizeof(int), MPI_BYTE, target, TAG_4, MPI_COMM_WORLD, &st);
  std::cout << "[" << rank << ",m] received form " << target << std::endl;
  void *ret;
  std::cout << "[" << rank << ",m] joining" << std::endl;
  pthread_join(thread, &ret);
  std::cout << "[" << rank << ",m] joined" << std::endl;
  std::cout << "[" << rank << ",m] exiting main_func" << std::endl;
  return NULL;
}
 
const char *thread_support_str(int p)
{
  switch(p){
  case MPI_THREAD_SINGLE:     return "MPI_THREAD_SINGLE";
  case MPI_THREAD_FUNNELED:   return "MPI_THREAD_FUNNELED"; 
  case MPI_THREAD_SERIALIZED: return "MPI_THREAD_SERIALIZED";
  case MPI_THREAD_MULTIPLE:   return "MPI_THREAD_MULTIPLE";
  default: return "What?";
  }
}
 
int main(int argc, char *argv[])
{
  int prob;
  MPI_Init_thread(&argc, &argv, MPI_THREAD_MULTIPLE, &prob);
  MPI_Comm_rank(MPI_COMM_WORLD, &rank);
  MPI_Comm_size(MPI_COMM_WORLD, &procs);
  if(rank==0) {
    std::cout << "# " << procs << " procs" << std::endl;
    std::cout << "# thread support = " << thread_support_str(prob)  << std::endl;
  }
  pthread_create(&thread, NULL, thread_func, NULL);
  main_func(NULL);
  MPI_Finalize();
  return 0;
}

gccのsvnバージョンをコンパイルしてインストールしてからOOoが落ちるようになったので，何が原因なのかとちょいと調べた．結果，shared libraryを探させるために ld.so.conf (の読むファイル) に /usr/local/lib64 を追加したのが原因らしい．これなくすとOOoがちゃんと起動する．

おそらく新しいほうのライブラリをロードしてこけてるんだろうけど，どのライブラリが原因なのか探るのが面倒．とりあえずOOo使うときだけエントリはずして ldconfig と叫んでおこう．

今回は優勝できずにもう一回コースなのか．なるほど，シード云々はこのためだったのか．んで後どんだけあるんだ？