| STUDIO KAMADA | Japanese to English by @nifty |
| 2005年4月の日記 | 2005-06-22(Wed) 11:02 |
|---|
楕円曲線法による素因数分解プログラムGMP-ECM 6.0.1がリリースされました。本体の更新はバグフィックスですが、INSTALLファイルにMinGWを使ってWindows環境でmakeする手順が追加されています。
RetroPC.NETがリニューアル。でもトップからFellowのページへ辿る方法がわかりませんです。X68000 LIBRARYとか。http://retropc.net/fellow.htmlのGoogleのキャッシュはここ。
4月3日追記 Fellowのページへ辿る方法は検討中とのことであります。
カトリック教会のことは詳しくないけれど、激務に耐え死の間際まで法王であり続けるという生き方そのもので人々の心を動かせるというのは凄いことだと思う。
SotaさんによるWindows用FTPクライアントFFFTP Version 1.92aが公開されました。
マウスオーバー辞書に対応したのは面白い。ただし、肝心の辞書が単語の意味をなるべく少ない文字数で表現しようとしたものらしく、いまいち役に立たない感じもする。自分の好きな辞書に差し替えることはできないだろうか。ウェブブラウザ上で単語の意味がポップアップする仕掛けの実装としてはPOP辞書が見栄えも良くてお勧め。
品川駅（高輪口）前の品川プリンスホテル内に4月8日にオープンする水族館。都内最大級で、長さ20メートルのトンネル大水槽があって、ドワーフソーフィッシュ（ノコギリエイ）さんをはじめとする300種20,000点の海水魚が展示されて、平日と休前日は22時まで営業するらしい。
リンク集（翻訳・辞書）がMacintoshで文字化けするとの報告をいただいています。手元にMacintoshがないので症状を確認できないのですが、詳しい報告をいただければ改善できるかも知れません。情報をお持ちの方はご連絡ください。
Bruce Dodsonさんが3466+1の66桁の素因数をECM（楕円曲線法）で発見し、ECMで発見された素因数の世界記録が一気に7桁も更新されました。
報告をくださった方にご協力いただき、リンク集（翻訳・辞書）の自動選択フォームがMacIEで文字化けしないように調整しました。手元で確認できないので細かいことはわかりませんが、一般的にUTF-8のページがMacIEに限って文字化けしてしまう理由はMacIEの設定で対処できるものが2つ、ページの側で対処すべきものが2つ、合わせて4つあるようです。すべてが必要というわけではないかも知れませんが、まとめると以下のようになります。
(1) MacIEの設定画面の「言語/フォント」で「ユニバーサル文字（UTF-8）」を選択する。この設定でUTF-8でないページが読めなくなってしまうので必要なときだけ切り替えなければならないようです。
(2) MacIEの設定画面の「言語/フォント」の「ユニバーサル文字（UTF-8）」で使用するフォントとして「Osaka」などの日本語に対応しているものを選択する。これはデフォルトで選択されていないかも知れません。
(3) ページの側でMETAのcontentとhttp-equivの順序を変更する。理由はわかりませんが、MacIEはhttp-equiv→contentの順序で書かないとcharsetを認識しないようです。
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
(4) ページの側でTEXTAREAにfont-familyを指定する。これがないとTEXTAREAに入力した文字だけ化けてしまうことがあるようです。
参考
立花さんも確認していただきありがとうございました。工事中のほうだけ化けたのはリンク集の方だけ(3)(4)の変更を加えた後だったからかも知れません。現在は工事中のほうも変更してあります。
Chris Monicoさんによる数体ふるい法を用いた素因数分解プログラムGGNFS-0.76.0がリリースされました。
64行×64列×1ビットの行列の乗算ルーチンを何種類か書いてMLに投げてみるテスト。Pentium 4はOpteronよりもパイプラインが長いので、分岐方向の予測が困難な条件では分岐命令のペナルティが極端に大きくなってしまうことを改めて実感。
日本時間の19時29分頃、スマトラ島沖でM6.8の地震。また、20時34分頃、福岡県で震度4の地震。12月26日のM9.0（研究者によってはM9.3〜M9.4と言われることもある）や3月29日のM8.7があまりにも大きかったのでM6.8が小さく見えてしまいますが、決して小さな地震ではないはずです。数え切れないほどの地震が頻発しているインドネシアでは現地に住む人も救援活動のために向かった人も大変だろうと思います。
7時22分頃、茨城南部と千葉北東部で震度5強の地震。津波の心配はなし。震源は千葉県北東部（北緯35.7度、東経140.7度）、震源の深さは60km、規模はM6.1（気象庁）。
交通機関に影響が出ているので注意。
Chris Monicoさんによる数体ふるい法を用いた素因数分解プログラムGGNFS-0.76.1がリリースされました。
15時35分頃、神奈川東部で震度3の地震。津波の心配はなし。震源は千葉県北東部、震源の深さは80km、規模はM4.4。
先日のmult64x64に続いてmultTも改造してみるテスト。multTは要素1ビットでnx64の行列A,Bから64x64の行列C=tABを求める関数です。GGNFSのblanczos64.cに含まれていて使用頻度が高いらしいので差し替えたらmatsolveが少し速くなるかも。
matrix size type zero one random
(microsecond/call)
64x64 old (GGNFS-0.76.0) 39.840 40.000 38.440
64x64 new (generic) 2.970 6.870 17.810
64x64 new (mmx) 2.970 6.870 17.810
1024x64 old (GGNFS-0.76.0) 112.500 112.500 90.600
1024x64 new (generic) 76.500 75.000 46.900
1024x64 new (mmx) 71.900 71.900 40.600
16384x64 old (GGNFS-0.76.0) 1672.000 1656.000 1406.000
16384x64 new (generic) 1125.000 1125.000 688.000
16384x64 new (mmx) 1062.000 1047.000 562.000
262144x64 old (GGNFS-0.76.0) 134530.000 133910.000 180160.000
262144x64 new (generic) 17820.000 17970.000 11250.000
262144x64 new (mmx) 17190.000 17190.000 9380.000
Chris Monicoさんによる数体ふるい法を用いた素因数分解プログラムGGNFS-0.76.2がリリースされました。
Microsoftの今月の更新は「重要」が3個、「緊急」が4個（Exchange Serverのものを含めると5個）。「緊急」のうち1個はWordの脆弱性なので自動更新やWindows Updateでは修正されません。WordなどのOffice関係の更新はWindows UpdateからOfficeのアップデートへ進んで行います。他に「Microsoft Windows インストーラ 3.1」と「Windows 悪意のあるソフトウェアの削除ツール - 2005 年 4 月」が出ています。削除ツールについては3月9日の日記を参照してください。
緊急
重要
絵でみるセキュリティ情報
その他
Chris Monicoさんによる数体ふるい法を用いた素因数分解プログラムGGNFS-0.76.4がリリースされました。
きょうはmultnx64。もともと速かったので期待していたほどの効果は得られなかった。
matrix size type zero one random
(milliseconds/call)
1024x64 old (GGNFS-0.76.0) 0.0969 0.0953 0.0906
1024x64 new (generic) 0.0234 0.0234 0.0156
1024x64 new (mmx (8 parts)) 0.0109 0.0109 0.0078
1024x64 new (mmx (6 parts)) 0.0140 0.0141 0.0141
16384x64 old (GGNFS-0.76.0) 0.438 0.438 0.359
16384x64 new (generic) 0.328 0.328 0.219
16384x64 new (mmx (8 parts)) 0.156 0.156 0.125
16384x64 new (mmx (6 parts)) 0.109 0.109 0.125
262144x64 old (GGNFS-0.76.0) 6.56 6.72 4.84
262144x64 new (generic) 5.78 5.94 3.91
262144x64 new (mmx (8 parts)) 2.81 2.82 2.35
262144x64 new (mmx (6 parts)) 2.19 2.19 2.34
4194304x64 old (GGNFS-0.76.0) 104.7 106.3 79.8
4194304x64 new (generic) 93.8 95.4 62.6
4194304x64 new (mmx (8 parts)) 46.9 46.9 40.6
4194304x64 new (mmx (6 parts)) 35.9 37.5 40.6
きのうのmultnx64の実験の8分割MMX版のソースコード。C=A×Bを排他的論理和で計算する。Aはn行64列、Bは64行64列の行列で、要素はすべて1ビット。x86の機械語はいまだに端のほうをちょこっとかじった程度だけれど、generic版をコンパイルしたコードよりも手で書いたほうが明らかに速く動いたときは少し嬉しい。これがドラスティックに速くなるともっと嬉しいのだけれど（1000行程度の小さい行列のときGGNFSのものよりも10倍速くなったのは機械語のコードを手で書いたからではなくてアルゴリズム上のトリックを使ったから）。しばらくしてから見返したらあまりのへっぽこ具合に眩暈がしたりして。
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#define DEFAULT_MODE 0
#define DEFAULT_ROWS 8192
#define DEFAULT_COUNT 1000
#ifdef __GNUC__
#define ALIGNED16 __attribute__ ((aligned (16)))
#else
#define ALIGNED16
#endif
#if defined(__MINGW32__) || defined(__CYGWIN__)
#define ASM_UL "_"
#else
#define ASM_UL ""
#endif
#define NON_TEMPORAL_MOVE
#ifdef NON_TEMPORAL_MOVE
#define movntq "movntq"
#else
#define movntq "movq"
#endif
typedef long s32;
typedef unsigned long u32;
typedef unsigned long long u64;
u64 multnx64_w[2048] ALIGNED16;
void multnx64(u64 *c, u64 *a, u64 *b, s32 n) {
asm volatile("\
xorl %%eax, %%eax \n\
xorl %%ecx, %%ecx \n\
1: \n\
movq (%0,%%ecx,2), %%mm0 \n\
.irpc b, 123456 \n\
movq 8*\\b(%0,%%ecx,2), %%mm\\b \n\
.endr \n\
pxor %%mm7, %%mm7 \n\
movq %%mm7, (%1,%%eax,8) \n\
.set n, 0 \n\
.irpc b, \
0102010301020104010201030102010501020103010201040102010301020106\
010201030102010401020103010201050102010301020104010201030102010 \n\
.set n, n^(1<<\\b) \n\
pxor %%mm\\b, %%mm7 \n\
movq %%mm7, 8*n(%1,%%eax,8) \n\
.endr \n\
.set n, n^(1<<7) \n\
pxor 8*7(%0,%%ecx,2), %%mm7 \n\
movq %%mm7, 8*n(%1,%%eax,8) \n\
.irpc b, \
0102010301020104010201030102010501020103010201040102010301020106\
010201030102010401020103010201050102010301020104010201030102010 \n\
.set n, n^(1<<\\b) \n\
pxor %%mm\\b, %%mm7 \n\
movq %%mm7, 8*n(%1,%%eax,8) \n\
.endr \n\
addl $256, %%eax \n\
addb $32, %%cl \n\
jnc 1b \n\
# emms" : : "r"(b), "r"(multnx64_w) : "%eax", "%ecx");
asm volatile("\
movl %0, %%esi \n\
movl %1, %%edi \n\
movl %2, %%ecx \n\
leal (%%esi,%%ecx,8), %%esi \n\
leal (%%edi,%%ecx,8), %%edi \n\
negl %%ecx \n\
1: \n\
movl (%%esi,%%ecx,8), %%ebx \n\
movzbl %%bl, %%eax \n\
movzbl %%bh, %%edx \n\
movq "ASM_UL"multnx64_w(,%%eax,8), %%mm0 \n\
shrl $16, %%ebx \n\
pxor "ASM_UL"multnx64_w+8*256*1(,%%edx,8), %%mm0 \n\
movzbl %%bl, %%eax \n\
movl 4(%%esi,%%ecx,8), %%edx \n\
shrl $8, %%ebx \n\
pxor "ASM_UL"multnx64_w+8*256*2(,%%eax,8), %%mm0 \n\
movzbl %%dl, %%eax \n\
pxor "ASM_UL"multnx64_w+8*256*3(,%%ebx,8), %%mm0 \n\
movzbl %%dh, %%ebx \n\
shrl $16, %%edx \n\
pxor "ASM_UL"multnx64_w+8*256*4(,%%eax,8), %%mm0 \n\
movzbl %%dl, %%eax \n\
pxor "ASM_UL"multnx64_w+8*256*5(,%%ebx,8), %%mm0 \n\
shrl $8, %%edx \n\
pxor "ASM_UL"multnx64_w+8*256*6(,%%eax,8), %%mm0 \n\
pxor "ASM_UL"multnx64_w+8*256*7(,%%edx,8), %%mm0 \n\
"movntq" %%mm0, (%%edi,%%ecx,8) \n\
addl $1, %%ecx \n\
jnz 1b \n\
emms" : : "m"(a), "m"(c), "m"(n) :
"%eax", "%ebx", "%ecx", "%edx", "%esi", "%edi");
}
int crc16(void *base, size_t nmemb, size_t size) {
static int *table = NULL;
int i, j, k;
if (table == NULL) {
table = (int *)malloc(sizeof(int) * 256);
for (i = 0; i < 256; i++) {
j = i;
for (k = 0; k < 8; k++) {
j = (j & 1) == 0 ? j >> 1 : (j >> 1) ^ 0xa001;
}
table[i] = j;
}
}
i = 0;
for (j = 0, k = size * nmemb; j < k; j++) {
i = (i >> 8) ^ table[(i ^ *((char *)base + j)) & 255];
}
return i;
}
int main(int argc, char *argv[]) {
int mode = DEFAULT_MODE;
int rows = DEFAULT_ROWS;
int count = DEFAULT_COUNT;
switch (argc) {
case 4:
sscanf(argv[3], "%d", &count);
case 3:
sscanf(argv[2], "%d", &rows);
case 2:
sscanf(argv[1], "%d", &mode);
break;
default:
printf("%s mode rows count\n mode: 0=zero, 1=one, 2=random\n", argv[0]);
return 1;
}
char *temp_a = (char *)malloc(sizeof(u64) * rows + 15);
char *temp_b = (char *)malloc(sizeof(u64) * 64 + 15);
char *temp_c = (char *)malloc(sizeof(u64) * rows + 15);
u64 *a = (u64 *)(((long)temp_a + 15) & -16);
u64 *b = (u64 *)(((long)temp_b + 15) & -16);
u64 *c = (u64 *)(((long)temp_c + 15) & -16);
int i;
switch (mode) {
case 0:
for (i = 0; i < rows; i++) {
a[i] = 0;
}
for (i = 0; i < 64; i++) {
b[i] = 0;
}
break;
case 1:
for (i = 0; i < rows; i++) {
a[i] = 0xffffffffffffffffULL;
}
for (i = 0; i < 64; i++) {
b[i] = 0xffffffffffffffffULL;
}
break;
default:
for (i = 0; i < rows; i++) {
a[i] = rand() & 0xffff;
a[i] = (a[i] << 16) | (rand() & 0xffff);
a[i] = (a[i] << 16) | (rand() & 0xffff);
a[i] = (a[i] << 16) | (rand() & 0xffff);
}
for (i = 0; i < 64; i++) {
b[i] = rand() & 0xffff;
b[i] = (b[i] << 16) | (rand() & 0xffff);
b[i] = (b[i] << 16) | (rand() & 0xffff);
b[i] = (b[i] << 16) | (rand() & 0xffff);
}
}
clock_t tm0, tm1;
{
clock_t t = clock();
while ((tm0 = clock()) == t);
}
for (i = 0; i < count; i++) {
multnx64(c, a, b, rows);
}
tm1 = clock();
printf("%s %d %d %d ", argv[0], mode, rows, count);
printf("%10.3f microsec crc=0x%04x\n",
((double)(tm1 - tm0)) / CLOCKS_PER_SEC / count * 1000000,
crc16(c, rows, sizeof(u64)));
free(temp_c);
free(temp_b);
free(temp_a);
return 0;
}
CC = gcc -Wall -O3 -fomit-frame-pointer -march=pentium4 #CC = gcc -Wall -O3 -fomit-frame-pointer -march=pentium3 all: test_multnx64_mmx_8 test_multnx64_mmx_8: test_multnx64_mmx_8.c $(CC) -o test_multnx64_mmx_8 test_multnx64_mmx_8.c test: ./test_multnx64_mmx_8 0 1024 10000 ./test_multnx64_mmx_8 1 1024 10000 ./test_multnx64_mmx_8 2 1024 10000 ./test_multnx64_mmx_8 0 16384 1000 ./test_multnx64_mmx_8 1 16384 1000 ./test_multnx64_mmx_8 2 16384 1000 ./test_multnx64_mmx_8 0 262144 100 ./test_multnx64_mmx_8 1 262144 100 ./test_multnx64_mmx_8 2 262144 100 ./test_multnx64_mmx_8 0 4194304 10 ./test_multnx64_mmx_8 1 4194304 10 ./test_multnx64_mmx_8 2 4194304 10 version: gcc --version as --version ld --version
Chris Monicoさんによる数体ふるい法を用いた素因数分解プログラムGGNFS-0.76.5がリリースされました。
オキゴンドウ（false killer whale）とバンドウイルカ（bottlenose dolphin）の交配種として19年前に偶然生まれたホルフィン（wholphin）のケカイマル（Kekaimalu）が女の子を出産したそうだ。父親はバンドウイルカなのでこの子はバンドウイルカの血にオキゴンドウの血が1/4混ざっていることになる。ケカイマルの子としては3番目。オキゴンドウは2頭いてまだどちらが父親か確定していない。名前はまだない。色は母親と同じくオキゴンドウの黒とバンドウイルカの薄いグレーが混ざった感じ。ハワイのオアフ島にあるシー・ライフ・パーク・ハワイ（Sea Life Park Hawaii）で12月23日に生まれてまだ4ヶ月足らずだけれど、大きさは既にバンドウイルカの1歳児並みだとか。それでもケカイマルの半分というのだからもっと大きくなるに違いない。
警察官が戸別訪問して防犯や事故防止のための指導をしたり住民から要望を聞くことは必要だと思う。しかし、警察官が戸別訪問で各戸の具体的な防犯体制をアンケート調査するなんてどう考えてもおかしい。そんな警察官は偽物で、うっかり無防備な箇所がわかるような情報を提供したら後で空き巣に入られるに違いない。気を付けよう。
買収価格は34億ドル（3670億円）。2002年に和解するまで訴訟合戦を繰り広げていた2社も結局こうなるのか。
昨年の暮れ、小惑星2004 MN4が2029年4月13日の金曜日に地球に衝突する確率が1/300というニュースが一般紙にも掲載されて話題になりました。直後に発生したスマトラ島沖の地震がなければもっと話題になっていたかも知れません。この日記でも衝突の確率が刻々と変化する様子を追い、確率が一時1/37まで上昇したことやトリノ・スケールの4が初めて使われたことなどを書きました。このとき、NASAのサイトなどに掲載されていたトリノ・スケールの表の4のところには次のような簡潔な説明が添えられていました。
A close encounter, with 1% or greater chance of a collision capable of causing regional devastation.
（広域災害をもたらす衝突の確率が1％以上の接近遭遇です）
2004 MN4で初めてトリノ・スケールという言葉を知った人にはこの説明は刺激が強すぎて、必要以上に恐怖を感じてしまったかも知れません。この日記では当初から数日以内に衝突の可能性がなくなるかも知れないということを書いていましたが、トリノ・スケールの説明文にも同様の文言が追加され、必要以上に心配しなくてよいことがわかりやすくなりました（一般の人にもわかりやすいように説明文が改められただけで、評価方法が変わったわけではありません）。例えば上記のトリノ・スケール4の説明文は次のように変更されました。
A close encounter, meriting attention by astronomers. Current calculations give a 1% or greater chance of collision capable of regional devastation. Most likely, new telescopic observations will lead to re-assignment to Level 0. Attention by public and by public officials is merited if the encounter is less than a decade away.
（天文学者が注目すべき接近遭遇です。現在の予測では広域災害をもたらす衝突の確率が1％以上です。おそらく今後の望遠鏡による観測によってレベル0に変更されるでしょう。接近まで10年以内の場合は一般の人々と官公庁も注目すべきです）
2004 MN4の衝突の可能性が指摘された2029年まで20年以上ありますから、新しい説明文であれば一般の人々はとりあえず心配しなくてよいことがはっきりします。なお、2004 MN4が2029年に地球に衝突する可能性は既に否定されており、現在は2034年と2035年の接近がトリノ・スケール1に見積もられています。トリノ・スケール0の小惑星が70個余り、トリノ・スケール1の小惑星が2004 MN4を含めて3個ありますが、トリノ・スケール2以上の小惑星は現在はありません。
第265代ローマ法王にドイツ出身のヨゼフ・ラッツィンガー（Joseph Ratzinger）枢機卿（法王庁教理省長官）が選出されました。法王名はベネディクト16世（Pope Benedict XVI）。新法王は78歳で、過去300年で最も高齢で選出された法王なのだそうです。
6時11分頃、3月20日に震度6弱を記録した福岡沖玄海地震の余震と見られる地震があり、福岡で震度5強が記録されました。
Chris Monicoさんによる数体ふるい法を用いた素因数分解プログラムGGNFS-0.76.7がリリースされました。blanczos64.cのMultB64とMultB_T64にバグを見つけたのでパッチを送って直してもらいました。MLのほうで高速化も試みていますが、今回の更新は行列の掛け算を間違えないようにする最小限度の修正のみです。
RetroPC.NETさんから。Production I.Gの押井守コラムにX68000の話題が。
5月15日に予定されていたスペースシャトル・ディスカバリーの打ち上げが1週間延期されて5月22日になりました。2月にスペースシャトル・コロンビアの事故からちょうど2年経ち、早期の打ち上げ再開が期待されていますが、安全性の確認が最優先です。
mult64x64、multT、multnx64、MultB64、MultB_T64の高速化が一通り完成したので、テストプログラムをまとめ中であります。L2キャッシュを考慮したら手元のPentium 4でMultB64とMultB_T64がほぼ倍速で動くようになったのだけれど、AthlonやOpteronでは逆効果みたい。
各所から。トレンドマイクロが午前7時半頃公開したウイルスパターンファイル2.594.00を適用したコンピュータにおいて処理速度が著しく低下する症状が発生したとのこと。11時頃に公開された2.596.00で修正されたものの、運悪くその間に更新を行った報道機関やJRなどで業務の一部に影響が及ぶ事態になったらしい。どんな製品も過信は禁物。
追記 土曜日でも対応しているパソコンメーカーのサポート窓口に苦情が殺到してしまったのだとか。
matsolveを改造したGGNFS-0.76.7-k2で334079 x 335908の行列の処理が2.86時間。同じデータで比べてみないとわからないけれど、以前は222585 x 223789の行列に2.71時間かかっていたからだいぶ速くなったのではないかと。
追記 GGNFS-0.76.7のmatsolveで2％まで回した段階で得られたblock Lanczosの予測所要時間はおよそ4.6時間。他に負荷をかけていないので予測所要時間が大きく外れることはないと考えられるので、単純計算でmatsolve単体が37％高速化され、全体の所要時間が1.7時間短縮されたことになる。30時間のうちの1.7時間だから大したことはないが。
NHK総合テレビほかから。9時18分頃、JR福知山線尼崎駅-塚口駅間で宝塚発同志社前行き上り快速電車（207系7両編成、乗客580人、高見隆二郎運転手（経験11ヶ月、23歳））の1〜5両目が脱線して1〜2両目が左側のマンションに突っ込み大破。少なくとも50人（男性27人、女性23人）が死亡（鉄道事故としては過去40年で最悪）、325人がけが。軌道中心から6メートルの位置にある9階建てのマンションの1階部分の駐車場に1両目が突っ込み、2両目が巻きつくようにめり込んでおり、12時間経った21時20分現在も救出作業が続いている。ワンボックス型の乗用車とも衝突しているが、直前の駅とマンションの間に踏切はなく、脱線後に衝突した模様。また、この電車は手前の停車駅である伊丹駅を8メートルオーバーランしてバックし、およそ1分30秒遅れて発車していたとのこと。直前の塚口駅はおよそ1分遅れで通過。現場付近は緩い右カーブ（R300）で制限速度は時速70kmだが、実際にどのくらいの速度でカーブに進入したのかは不明（ATSは旧式で赤信号にのみ反応する）。現場近くのレールに粉砕痕（石などに乗り上げたときにできるもの）があったが事故との関連は不明とのこと。
当初、マンションに巻きつくようにしてめり込んでいるのは7両編成の1両目だけだと思ったが、後ろから数えてみると原形をとどめている車両が5両しかなかった。マンションに巻きついて見えていたのは2両目で、1両目は2両目の下にあり、6時間以上経った16時前にやっと1両目の救出作業が始まったとのこと。
民放もいくつかザッピングして見た。電車の速度が普段よりも速かったらしいというだけで他に考えられる原因を挙げることもせずに運転手の過失ばかりを責める解説者を連れてきたところは見苦しかった。事故区間で同じ快速電車の運転席から撮影された4年前の映像を見つけてきて（当時はまだマンションがなかったが）解説に使っていたところはわかりやすかった。
追記
さらに余談なのだが、民放で事故関連ニュースの合間に入ったTDSの「ディズニー・リズム・オブ・ワールド」のTVCMの冒頭に通学途中の学生や会社員が電車内で踊っているシーンがあり、楽しいはずのTVCMなのに複雑な気持ちになってしまったのは私だけだろうか。
きょうは午前中から@niftyのウェブメールが断続的に使えない状態が続いています。サポートページには18時にすべて復旧したと書いてあるのですが、21時前にまた「サーバーが停止しています」と表示されました。@niftyでは認証が必要なサービスが一斉にダウンするというトラブルが以前にも何度かありましたが、今回は特に復旧に時間が掛かりすぎているように思えます。
夜を徹した救出作業で日付が変わってから今朝までに3人救出された。しかし犠牲者の増加は止まらず11時現在で73人。事故直後には重機が接近できなかった現場に複数のクレーン車が入り、より大掛かりな作業が進んでいる模様。
Reruters.comでもトップニュースに。
追記 きのうテレビで「伊丹駅で2両目までオーバーランしていた」という複数の証言が放映されていたので変だと思ったのだけれど、やはり8メートルというのは嘘で実際は40メートルだったらしい。しかも運転手の要求で車掌が運転指令に嘘をついたという。まるで兄弟で相談して親に嘘をついたが結局ばれてしまった子供のようだ。
SNFS法で難易度10150のnear-repdigit (7·10150-61)/9を21.84時間で分解できた。
Chris Monicoさんによる数体ふるい法を用いた素因数分解プログラムGGNFS-0.76.8がリリースされました。
犠牲者の数は今朝までに91人。まだ1両目に取り残されている人がいるとのことで、さらに増える見込み。
9月にH-IIAロケット8号機で打ち上げられる予定の世界最大級の地球観測衛星ALOS（エイロス）が公開されたそうです。ALOSは3種類の高性能なセンサと、センサから得られた膨大なデータを圧縮、蓄積するサーバ（のようなもの）と、データを効率よく伝送するためのアンテナを備えています。センサは、2.5メートルという高い分解能で標高データを取得する立体視センサPRISM、可視光と近赤外の合計4種類の波長で撮影するAVNIR-2、天候や昼夜に関係なく観測できる合成開口レーダーPALSARの3種類。データレコーダの容量は96GB。DRCアンテナの伝送容量は240Mbpsとなっています。重量がおよそ4トンあり、先日打ち上げられたひまわり6号も含めて過去に日本のロケットで打ち上げられたどの衛星よりも重いです。軌道はひまわり6号のような静止軌道ではなくて高度692km周期99分の太陽同期準回帰軌道に投入されます。
犠牲者の数は106人でほぼ確定。犠牲者が100人を越えた鉄道事故は40年振りとのこと。asahi.comの記事に掲載された遺族の声「遺体のむごさを見なければ事故のひどさがわからないのに」が印象的。記者会見に出てくるJR西日本のトップの人はどれだけの遺体を目の当たりにしたのだろうか。
xx...xxyの形のnear-repdigitの素因数分解は150桁まで28系列4200個のうち残り3個。
フリーソフトウェアのプラネタリウムソフトStella Theater Lite Ver2.40が公開されました。軽くてお気に入り。
| Copyright (C) 1999-2005 Makoto Kamada All Rights Reserved. | Jump to mirror |