No Such Blog or Diary

昨日ＦＧしたにもかかわらず眠気に負けて読んでなかったのを本日読了．今回はＶと同様に過去の話で燃え燃え～．いろいろと伏線回収されてるし．棺の織手とか一巻に名前だけ出たやつだし．とりあえず一番驚いたのは小夜啼鳥であったことはいうまでもない．

二つの和を求めるプログラムがある．

#include<iostream>
using namespace std;
int main(int argc, char *argv[]){
	double d = 1e300;
	double sum = 0;
	for(int i = 0; i < 10000000; i++){ sum+=d; }
	cout << sum << endl;
}

#include<iostream>
using namespace std;
int main(int argc, char *argv[]){
	double d = 1e308;
	double sum = 0;
	for(int i = 0; i < 10000000; i++){ sum+=d; }
	cout << sum << endl;
}

上は 1e300 を 100000000 回足した和を求める．下は 1e308 を 100000000 回足した和を求める．これらのプログラムを実行した場合，普通は速度の違いなどないように思えるが...　実際に動かすと上が 0.148s で下が 0m3.692s と劇的に違う．これは double が 1.7e308 程度までしか値を保持できず，これ以上ではオーバーフローして Inf になってしまうことによる．で，Inf に値を足し続けるので遅くなると．何で Inf で遅くなるのかしらんけど．

最近椅子がギシギシ言っているのでどこがうるさいのだろうとよく見てみたら...　　傾いてる orz　何かジョイントの溶接部が割れてきたようなないような状況で4年半使ってきた椅子も引退か？　コントのように椅子が壊れて滑り落ちるまでは使うことにしよう．

数直線上に一定周期で一定幅を持つ区間が並んでいると．そんなのを二つ持ってきたときに何処かに重なる部分がありますかという問題を解きたい．当初あほな私は for 文を繰り返し幅の lcm 文にいたるまでぶん回していたのだが...　よく考えたら gcd の分だけできるだけ近づけて考えれば一発でいいじゃんと．いやぁ，あほだった．

ある期間内に存在する指定した曜日と日にちをもつ日の数を数えたり，グラフ上を巡回するアリ全部に対して情報伝達可能かどうかをしらべたり．そんな問題を解いたわけだが...　コーディングが遅くなっているような...　最近この手のプログラムかいとらんかったからなぁ．いや，むしろ日付問題が苦手なだけだだろうか？　まあ，そんなことはどうでもよいのでさっさといやらしい入力を作るか．

友人がリプレイファイルの解析をやっていたのでデータファイルの解析をやってみた．結論としてはブロックに切ってスクランブルしてマスクでXORして，LZで圧縮かけて（アドレス13bit, 長さ4bit, 絶対アドレス（開始オフセット１）），全部をがしゃんとくっつけて最後にファイル名とアドレスと展開後のサイズの情報をまとめてLZかけてスクランブルしてくっつけてあると．んで，先頭には識別文字4つとファイル情報のエントリ数，アドレス，展開後のサイズがスクランブルされて格納されていると．

いやぁ，結構手間がかかってるもんだなぁと関心しつつ，ここまでやらなきゃだめなのかと思ったり．あと，ＬＺのパラメータが何でこの数字になっているのかよくわからない．バイト境界になるようにアドレスと長さのビットを割り振って，さらにフラグを８つまとめて置いておくほうが展開が速いと思うのだが...　そこまで速度はいらないのかな．むしろビットストリームのほうがぱっと見で元データがわからないからいいのかも．

どうでもいいけど，何でこの永夜抄のアーカイブに妖々夢のPhantasm出現時に表示される画像データが入っているのだろう？