今日は，もうすぐcs-pccluster2となる予定のPCの部材を購入して運び入れる作業をして疲れ果てる。さすがにセダンの車体にＡＴＸのPC Case8台は無茶であった。それでもトランクにまで詰め込んで無理矢理運んでやった。ざまあみろ(誰に言っている)。
メーカー名は伏せるが，さすが5800円の廉価ケースだけあって軽い軽い。内部の金属板の薄いこと薄いこと。ベコベコ，ではなく，ペコペコ，なのである。マザーボードを取り付けるための板も取り外しが出来ず，側板を除いて，全ての板がリベットで強引に固定されてしまっている。これは工作がしづらいなあ，と嘆息。
とはいえ，次年度はPCをばらしてNICを取り付けるなどという乱暴な実験はやらない（させない）ので，これでもいいのである。電源も350Wとまあまあの容量だし，本体ファンも付いており，ケース前部にはUSBポートも出ている。P4マシンに仕立てることを考えれば，ペコペコケースは冷却には向いていると言える。「計算はケースで実行するんじゃない。CPUとGbEで勝負だ！」ってなもんである。
ぼちぼち価格.comと睨めっこするのも飽きたので，CPU以下の部材一式の相見積もりを取らねば。CPUはMHz単価で最適化して決めることにしようっと。
そーいや，SciCADE05のWebサイト用サーバが届いたって報告が小生御大から来ていたなあ。Xeon DualのDellのPowerEdgeだそーで，やっぱりお金持ち(違うという声が聞こえてきそうだが無視する)は豪儀である。もっとも，高いメーカマシンはユーザが勝手に手を入れられないという欠点があって，致命的な故障が起きるとどうしようもない。前の職場で今は亡きCompaqのNetwareサーバを大枚はたいて導入したが，ものの数年でおかしくなっちゃったモンな。今なら安いRAID突っ込んで組み立てたマシンの方がよっぽど使い勝手がよい（自分で全てをやるなら，の話）。
マジメな話，白崎さんがどっかで発言していたけど，サーバにあるファイルのバックアップだけなら，RAIDだけでなく，ネット経由でもミラーすべきであろう。具体的にはrsyncにsshかませて自動ミラーをしておけば，「そこそこsecure」にはなる訳である。ロクにメンテ費用も出せないのに，一発買い取りの高いハードに頼るってのは・・・ねぇ。
現実逃避てがら，つらつらと多倍長計算環境について考えてみる。前の応用数理の年会でT大学のH先生が講演者に「多倍長の初等関数の精度は大丈夫か？」と噛みついていたのと聞いて，やっぱ，まだまだその基盤は危ういよなあと思いを新たにしたのだった。
で，cygwinに入っているmath.hを見ると，既に
extern double gamma _PARAMS((double));
extern double gamma_r _PARAMS((double, int *));
extern double lgamma _PARAMS((double));
extern double lgamma_r _PARAMS((double, int *));
extern double erf _PARAMS((double));
extern double erfc _PARAMS((double));
extern double y0 _PARAMS((double));
extern double y1 _PARAMS((double));
extern double yn _PARAMS((int, double));
extern double j0 _PARAMS((double));
extern double j1 _PARAMS((double));
extern double jn _PARAMS((int, double));
なんて関数が使えるようになっている。gccは3.2。確か，ANSI C90（だっけか？）で取り入れられたんだっけ。更に
#define M_E 2.7182818284590452354
#define M_LOG2E 1.4426950408889634074
#define M_LOG10E 0.43429448190325182765
#define M_LN2 0.69314718055994530942
#define M_LN10 2.30258509299404568402
#define M_PI 3.14159265358979323846
#define M_TWOPI (M_PI * 2.0)
#define M_PI_2 1.57079632679489661923
#define M_PI_4 0.78539816339744830962
#define M_3PI_4 2.3561944901923448370E0
#define M_SQRTPI 1.77245385090551602792981
#define M_1_PI 0.31830988618379067154
#define M_2_PI 0.63661977236758134308
#define M_2_SQRTPI 1.12837916709551257390
#define M_SQRT2 1.41421356237309504880
#define M_SQRT1_2 0.70710678118654752440
#define M_LN2LO 1.9082149292705877000E-10
#define M_LN2HI 6.9314718036912381649E-1
#define M_SQRT3 1.73205080756887719000
#define M_IVLN10 0.43429448190325182765
/* 1 / log(10) */
#define M_LOG2_E 0.693147180559945309417
#define M_INVLN2 1.4426950408889633870E0
/* 1 / log(2) */
なんて定数も必須だよな。精度が可変になると，Machine epsilonも違ってくるし，NANの範囲も変わってくる。その辺り，きっちり出来ている多倍長ライブラリってそんなにないよな。一応，MPFRはその辺りを少しは意識して作ってあるので，BNCpack/MPIBNCpackはそちらを採用したのだが，まだ足りない。
もっと現実的なことでは，多倍長の初等（に限らないけど）関数はやたらに遅い。遅いのは無限級数に頼っているせいで，多分，MPPACKでも採用しているように，精度毎に最良近似多項式を導出して使った方がよっぽどマシなのではないか，と思える。わしの大師匠の経験によれば，sin/cos, expあたりは，Maclaurinでもかなり収束が早いので，多倍長ではあまり差が付かないのでは？という意見であったが，桁が増えるとやっぱり最良近似の方がマシになるよーな気がする・・・のだが？
と，math.hにはこんな所もあった。
#ifdef __FAST_MATH__
#include <machine/fastmath.h>
#endif
へぇー，と数値計算トリビア。探すとちゃんとmachine/fastmath.hってのがあって，
#define sin(x) fast_sin(x)
#define cos(x) fast_cos(x)
#define tan(x) fast_tan(x)
#define asin(x) fast_asin(x)
なんてのが並んでいる。ここでは特定の(_sysvnecv70_target)マシンだけの設定のようだが，これ，そのまんま多倍長で使えそうじゃん。通常のsinは無限級数に基づくルーチンにしておいて，速い関数が欲しければfast_sinを使う，とかね。ちょっと勉強になりました。
ということで，寝ます（久々のフレーズ）。