日記　2005年09月

危うく日記を忘れそうになる。

サイトのHTMLにはある程度満足しているが、CSSには少々不満がある。HTMLに関しても細かい部分に不満があるが大方CSSの設定で解決できる。現在デフォルトで用意されているCSS適用パターンは全体、NN4以外、IE5.xのみ、IE6.ｘのみの4種類となっているが、JavaScriptを使ってさらにダイナミックにCSSを適用する術をこのサイト持っていない。余裕があるときに4種類のCSSに加え、JavaScriptで動的にCSSを適用する部分を追加。さらにHTMLの一部を変更したい。変更の必要があるファイル数を確認したところ156個。全力でやれば1時間で終わる。

CSSが手抜きだからその類の本でも買おうかなぁ…

エイベックスが「のまネコ」Flash収録を中止へ　商標登録も中止依頼[www.itmedia.co.jp]

PCのデータドライブの容量を削るべくいらないファイルをさらに一掃。最終的に700MBのCD-RW2枚に収まるように削減した。というのは、今日伺かまでもが破損し流石にやばいので全データのバックアップを計画したからだ。手っ取り早くWindowsを再インストールすればいいのだが、今のWin2000は少々覚悟が要る。2MBのファイルさえ落とすのに時間を要するこの環境で、果たして50MBのアップデードファイルを落とすことができるのかという問題(前の再インストールでは丸一日費やしてダウンロードした)。仮に再インストールするとすればそのタイミングはSleipnir2.00正式版が公開されたときだろう。メインブラウザ(現在はSleipnir1.6.6使用)を入れ替えるときが最適。

このサイトのサイズを久々にチェックしたところ、20,667,854バイト(19.7MB)であった。個人がページを作る際はテキストメインなら50MBあればまず底を尽くことはない。

JavaScript+CSS+DOM+XMLを用いたAjaxなる技術を読み漁っていたが、私はこれまで外部ファイルをJavaScriptで読み込む手段をIE独自機能のBehaviorとDataBindしか知らなかった。が、XMLHttpRequestでほぼ全てのブラウザで外部ファイルを操作できることがようだ(もちろんアクセス範囲はIEの機能同様に同一サーバー内に限られる)。データを受信するスクリプトを手に入れたので、これを用いて色々と試したい。特に最近は外部ファイルの扱いに興味がある。最近JavaScript関連の本を買ってなかったが、さらに上級者向けの本を買いたくなった。

ところで他人のスクリプトと自分のスクリプトを比べていると自分のほうが劣っているように感じるのだが、それは自分で組んだスクリプトは一目で理解できるのに対し、他人が組んだものは変数名も書き方も異なるので"何か難しいもの"と感じるせいなのだろうか。

Firefoxで外部ファイルをロードできたときの感動(何

夜中窓を全開にして寝るという行為の副作用を発見。レム睡眠中夢の中まで虫の音が聞こえてくる。そのおかげで連続して眠れたとしても2時間がやっと。それでも冷房をつけるよりはマシ。

＞こばやし　ひとみさん
メールありがとうございます。きれいにまとめられていて返信のしようがなかったのでこれにて。

RSS生成をもっと実用的なものにすべく改良を検討中。妙にだるいのでこれにて終了。

自己紹介に好きな時間帯を追記したが、私は深夜から早朝にかけてが好き。まぁ、これは昼間私の周囲の工場がうるさいというのもあるが、この4畳半の室内はあまりに暑い。電子機器の廃熱がやばい。その熱量は、室外ではすぐに枯れてしまう亜熱帯性植物を生存させ、瀕死のサボテンを生き返らせるほどのもの。私の部屋に持ってきた植物で枯れてしまったのは比較的低温を好む植物だけだった。とにかく暑い。基本的に冷房は27〜28度に設定していてそれ以下は私の腐った良心が許可しない。しかし、いくら暑くても昼間に窓を開けると重機がうなっており、静かな環境を好む私には耐えがたい。だから日が沈み、放射冷却で気温が下がり、工場の活動が停止したときが一番好きだ。昨晩も窓全開で寝たが、室温は25度まで下がり快適。昼間寝て夜起きたい(昼夜逆転派)。

この日記を更新した17時20分ごろ、サイトが一時閲覧不能となっていましたが、原因はこちらのアプリケーションの破損。エラーが出まくるもんでOSを再起動したところ...

OS破損

現在は起動しているが次が起動できない可能性もある。即急にプログラムフォルダから必要なデータだけをデータドライブに移動、CドライブをクリーンアップしOSを再インストールする必要がある。また、最初に書いたようにいくつかのアプリケーションも破損しているようだ。

コンピュータ科学の本にC言語で書かれたハノイの塔の実行プログラムがあったので、JavaScriptに移植。
ハノイの塔とは、例えば3本の棒があり、左端の棒に下から大きい順で円盤が重ねられている。この円盤をそっくり右端の棒に移動させればいいのだが、これには決まりがある。

1. 円盤は1枚ずつしか動かせない
2. 小さい円盤の上に大きい円盤を重ねることはできない
3. 途中で真中の棒を利用しても良い

以上の約束を守って円盤を移動させる。JavaScriptプログラムは以下の通り。

<script type="text/javascript">
<!--
document.writeln("<pre>");
cnt=1;
r_c = function(n,x,y,z){
        if(n>0){
                r_c(n-1,x,z,y);
                cnt++;
                document.writeln("円盤",n,"を",x,"から",y,"に移動(",cnt,")");
                r_c(n-1,z,y,x);
        }
}
while(true){
        Saucer = prompt("円盤の個数を入力","5");
        if(isNaN(Saucer)||1>eval(Saucer)){
                alert("error");
                continue;
        }else{
                S = eval(Saucer);
                conf = confirm("予想計算ステップは"+Math.pow(2,S)+"ですがよろしいですか？");
                if(!conf)continue;
                else break;
        }
}
r_c(S,"X","Z","Y");
document.writeln("移動回数:",cnt);
//-->
</script>

このソースコードを空のHTMLファイルにコピーペーストしてブラウザで開けば、あとは指示に従って数字を入力するだけで自動実行される。円盤は小さい順に1,2,3...、棒は右からX,Y,Z。

マトリックスを全編観直した。テスト期間中に。

スーパー正男を更新したついでに、無意味なランキングを非表示にしいきなりサウンドが鳴り出さないように設定し直した。突然音楽が鳴るように指定するのは訪問者にとって迷惑。訪問者のためにサイトは存在するのだから、サイト構築の際にはまずこれを優先させる。

47氏が解説する『Winnyの技術』の発売決定！[slashdot.jp]
違法共有は私の腐った良心が許さないかもしれませんが、その技術には非常に興味がある。結果的にファイル共有目的となってしまったが、作者自身が開発を始めたきっかけは技術的興味であるに違いない。実際47氏の(閉鎖された)サイトには物理系統のシミュレーションのプログラムが置いてあった記憶がある。内容のレベルによるが読んでみたい。

台風17号、是非ともテストは延期となってほしい。ところで台風には"カトリーナ"のような名前がつけられているが、アジアで発生する台風の名前はアジアの国々が出し合った名前を順番に用いる。"なじみある名前"と言ってるわりに、日本名は「ヤギ」とか「カジキ」とかだったり…。台風ヤギよりはカトリーナのほうが明らかになじみあるように感じるんですが。まぁ、日本の場合誤って"さくら"とかつけた日にゃ、さくらたんハァハァとかになりかねないのでまだマシか。
Try Google-"台風名"

ある程度予測はついていたが、連休中何も勉強せず、平時と同じ準備を持って学校へ。案の定テスト。結果については校内テストなんてどうでもいいと考えているので、赤点ギリギリの30点ぐらいに収まるように勉強。尤も、初日の今日の時点で1教科赤点が確定したが。

Opera無償版の広告バナーが廃止に[slashdot.jp]
うれしいことはうれしいが、10周年記念にライセンスキーを大量にかき集めたあの努力は…。(ちなみに私は今後もOperaを使う予定はナイ)

今日はとくに更新履歴には何も書いてないが、いくつかの記事でリンクしていたリンク先のデータを転載リソース集に格納。他にはローカルで既存のプログラムの高速化に挑戦してみたり。(テスト中だろ

素数判定HSP版。実は私がHSPをいじったのは今日が初めて。HSPの場合、最初から付属しているサンプルの量が多いのでメインのループ計算以外は全てサンプル集のコピーです。どうでもいいけど、HSPてrepeat〜loopを実行すると自動的に内部変数cntでループ計算を始めるのがむかつく(何

素数判定のC言語版も作っていたが、C言語では配列のサイズを動的に変更できない。計算前に素数の数を概算しその長さだけ効率よく配列を組もうと考えていたが、大きな誤算。調べると、どうやらC++では配列サイズを動的に変更できるようだ。手元にコンパイラがあるのですぐにでも作ろうかと思ったが、設定が面倒だったのでまた今度にすることにした。

JScript(IEのみ対応)にwindow.createPopup()というものがある。これはデスクトップ上ならどの位置でもポップアップを表示させられるもの。以前JavaScriptで伺かを走らせていた面白いページがあったが、そのページでは通常のDOMでキャラクターを表示させていたため表示区域は画面内に限定されていた。が、この機能を用いれば実物のmateria同様デスクトップの最前面にキャラを立たせることができる。window.createPopup()という機能自体使ったことがないので、是非とも試したい。ま、最大の問題はスクリプトじゃなくて立たせるキャラクターの画像がないってことなんだが(死

体重を測ったところ予想以上に痩せていた。口内炎で夜食にラーメン食えなくなっただけでこんなに痩せるなんて。肥満指数を計ったところ、【17.2】[痩せすぎています！]との結果が。(たかが1,2kgの差だから元々"痩せ過ぎ"であることには変わりないのだが)

データ用領域として使っているEドライブがまた煩雑になってきたので整理整頓。2万個あったファイルを半分の1万個に削減。厳密には重複してるフォルダを片っ端から消して、展開してある圧縮ファイルを片っ端から消して、使わないだろうと思うフォルダを片っ端からCAB圧縮しただけ。なお、11000個あるファイルのうち9000個は私の歴代のウェブサイトだったりする(マテ

巨大数演算の配列を使ったプログラムについて、7桁の配列で行うと言ったが、5桁のほうがJavaScriptの精度限界である15桁と相性が良い。これをもとに加算関数を作り、1万桁のランダムな巨大数を足し算させてみた。結果、現在のVer.0.3alpha6に惨敗！alpha6は1万桁の足し算を一瞬で行えるのが、新しく作ったものは100ミリ秒程度の時間を要した。新しいアルゴリズムがちゃんと動作したのは収穫だが、現存のバージョンを超えなければ意味がない。

100万以下の素数の数は私の持っていた数学書によると78499個だが、私のプログラムがはじき出した値は78498個だった。私のプログラムより参考書が正しいと考え、フェルマーの小定理で999983以降の奇数をチェックしたが全てハズレ。だとすればプログラムがどこかで素数を1つ見落としているのか、と思ったが、Wikipediaで調べるとなんと私の結果のほうが正しかった。実は参考書のほうのミスはこれで二度目。

配列で効率よく乗算を行う問題を解決。配列を加算に合わせるのではなく乗算にあわせる方式で解決できそうだ。配列は15桁から7桁にダウンさせるが、加算時に2配列を同時計算することで一気に14桁を計算する。7桁の場合そのまま乗算してもオーバーフローしないので余計な処理が減る。

新ドメイン「.cat」承認、「.xxx」は決定先送り[slashdot.jp]
見た瞬間「ねこみみ属性ドメイン」を想像。投稿にも同じ書き込みはあるけどねー。それはどうでもいいとして、.xxxドメインをなんで承認しないのだろう。アダルトサイトを全部.xxxドメインにやってしまえばフィルタリングも楽になるだろうに。

行動不能で一日中寝ていたので、他に何もありません。回復したらしたで期末テストに殺される予定。

(買ったゲームを)ストーリーだけクリアしたので今後はゆっくり進める。よって、PCに触れる時間が増えるのできっと更新も元に戻る。ちなみに今はテスト期間中(やってることが間違ってる)

口内炎は回復に向かっていると書いたが、舌を噛んだりしてしまったせいで悪化中。しゃべると痛い。食べると痛い。常に痛い。集中力を大幅に欠く。

Windows 2000用のUpdate Rollup 1
やっと不都合が修正された。ただし、ここでキターとインストールしてまた不都合が起きると怖いので、しばらく様子を見て安全ならインストール。MSも随分信用できなくなったもんだ。

久々に数学パズル系の本をめくっていたら懐かしの覆面算が出てきた。2問とも各アルファベットには0〜9の数字が入る。一度使った数字は使えない。

昨日気づいたのだが、今日はテスト発表だった(マテ)。とりあえず本格的な更新は延期。ネタ浮かばないし。

ゲーム買った。というわけで更新には期待しないでくれ(やり込む気)

トップページのカウンターは200前半とかなり落ち着いている。サイト全体のアクセスもそれなりに落ち着いてきたのかなと思ったが、そうではない様子。このサーバーのページ毎のアクセス解析を応用し、特定のHTMLを全てのページに埋め込んでみた。埋め込んだページはこのサイトのどのページを開いても読み込まれるため、埋め込んだページのアクセス解析結果がサイト全体の結果に反映される。結果、1日のペービジュー回数が1400程度と判明。予想では800〜900かと思ってが、予想より大幅に多かった。

サイトトップページがWWWCのMETAタグ更新チェックに対応。これでますます1回の更新で手を加える個所が増えました(笑)現在1回の更新で手を加える必要のあるファイルを列挙してみる。

• トップページ
• 更新履歴
• 更新ページ
• 更新ページの上階層のINDEXページ全て
• 配信してるRSS
• 更新日データを格納している外部JSファイル

1回の更新に正直時間掛かり過ぎる。このサーバーはCGI等が一切使えないので全部手動で設定変更している。更新のデータはこのサイトの全てのページに外部スクリプトから供給され、ネタバナーもこれらの更新データを読み込んで動作する。1ファイルの追加で最低6ページの修正、トップページに至っては6箇所の修正がいるので、恐らく私以外の人間で更新できるヤツはいない。ちなみにこの日記を書くだけでもかなりの修正が必要だったり。

CODHTMLの新バージョンの構想を練っていた。少なくとも、暗号化系統のプログラムを研究したときに作られたパスワード暗号化アルゴリズムを搭載させ、パスワードを入力しないと見れない機能はつける。あとパス制限がないヤツで、現在使われている複合化防止プロテクトを強化する。JavaScriptを少しかじった初心者なら、あの程度の暗号は解かれてしまう危険性がある。これを防ぐにはdocument.writeの文字を強力に暗号化する。こうすると、解読に必要な手間が一気に増して解読が困難になるであろう。基本的にJavaScriptでHTMLを暗号化するスクリプトの場合、document.writeをいかに隠すかが問題となる。XORHTMLはあからさまにこれが表示されているため、HTMLの暗号化が強力でも簡単に破られる。そもそも、デコーダを搭載した暗号システムにおいて、暗号自体は普通相手にされない。いかにしてデコーダを守り抜くかが勝敗を決めるのだ。現在DOMで解読されるのを防御する方法を考え中。リアルタイムにbodyが変更されてないか見張って、変更されたら元に戻すなどの案が浮かんでいる。

巨大数演算の新しい乗算アルゴリズムを考えついた。10桁×10桁を精度を損ねずに計算する方法であるが、内部的には2回の計算を行っていたため計算効率は変わらなかった。また、同じ手法で一気に308桁まで計算できる破天荒な方法も考えたが、これも内部的には浮動小数点計算を連続で行い、精度が保たれている部分だけを抜き出して連結させる方式。現存の7桁×8桁には及ばない。

割り算も考え中。概算結果だけで商を決めるのは流石にやばいので、JavaScript自身の浮動小数点計算の概算結果から商を総当りで調べる方式にすることにした、この方法なら、商が9の場合0〜10までの10回の検証作業だったのを、最初に概算して商を9を求め、9から検証を開始すればは2回のステップで済む。今まで平均5回の検証が必要だったステップを半分以下に減らすことができる。割り算が2倍になれば円周率と平方根が急加速できそうだ。

次元の話を書いているときに、はてなダイアリーの質問の中の「1秒は何メートルか」という問題について考えていた。解答は2種類考えられ、現在人類の持ちうる時間と距離の等式"1秒=光が299792458メートル進む時間"を使うか、それとも時間軸と空間軸がそもそも違うので"答えなし"とするの2種類。ただ、前者に関しては、「1秒=299792458メートル」ではなく、「1秒=光が299792458メートル進む時間」であって距離と時間の等式ではない。そもそも空間軸と時間軸の単位系そのものが違うので、深夜まで考えた挙句私は"解なし"と結論づけた。まぁ・・・といってもこれは半分眠れなくなるから結論を出したのであって、本当のところまだ考え中。

2連休。台風通過後の夕方の空ほどいいものはない。

巨大数演算alpha7の開発をやってたが、少しでも書き換えるとスピ−ドダウンが起きる。明確な高速化ステップが見つかるまで迂闊に手が出せない。明確なスピードアップが可能なのはもう除算だけと考えている。(新しい計算方法が見つかれば話は別だが)

というか、この巨大数演算企画。元は円周率を計算する際に生のJavaScriptでは15桁以上の演算が出来ないことから始まった。除算が実装された時点で円周率を100桁単位で計算できるようになり、この時点で一応目的は果たされたがその後も暴走を続け、円周率を実装したVer.0.1 beta1からすでに10回のバージョンアップが行われ計算速度は当時のころと比べ劇的に高速化された。Ver.0.3からは円周率デモがなかったが、Ver.0.3の実力を測るために円周率デモを後付けしておいた。動作させたところ、Ver.0.2時代の2倍程度のスピードであった。乗算はもっと速いが、マチンの公式の中核が除算である以上劇的なスピードアップはできなかったようだ。いい加減この企画を終わりにすべきか。

遊び：2¹⁰⁰⁰⁰⁰(だんだんエスカレート)

毒吐きネットマナー復活してた。

夜になって本格的に風が強くなってきた。2連休も夢じゃない！

1日かかって配列による乗算関数を作りました。早速5000桁×5000桁のスピードバトル。
Ver.0.3alpha5　VS　Ver.0.4beta1
結果…

Ver.0.3alpha5　9.156秒
Ver.0.4beta1　51.906秒

惨敗orz

しかも計算が間違ってる。バグ検証と言うよりはこの時点でアルゴリズム見直しです。でも新バージョンのインターフェイスはとても気に入っています。仕方なしにAlpha6にその新型インターフェイスを装備させてみる。

2ヶ月ぶりにねおクエ攻略更新。今まで中途半端だった不正チェッカーをまともにプログラミングし直した。プログラムを組む際の低レベル見本としては、つちのこ氏のタコ様ウインナー(レベル39MAX)のSTを使用。新しく作り直したバージョンは"タコ様"のステータスとかなり符合した。

現代用語の基礎知識2006(はてなより)

• オリキ
• 推しメン
• ヲタ芸
• DD
• お菓子系
• 全ステ
• 大パ
• 「たん」
• カトキ立ち
• ラッキースケベ
• 萌え属性
• ツンデレ
• 萌え擬人化
• 無表情キャラ
• 脳内彼女
• 大きなお友達

more...

台風の接近で明日は休校。明日は巨大数演算に取り組む予定。

今日学校で配列を使った乗算のアイデアが浮かんだ。加算するときはJavaScriptの精度限界桁数である15桁が最速なのだが、奇数の15は乗算には向かない。乗算するときはA×Bが15桁以下にならなければ精度が失われてしまう。今まではAを8桁区切り、Bを7桁区切りにして掛け算してきたが、配列を使った場合はかなり厄介になる。そこで、配列に収める数値を14桁に絞る。この場合7桁となりかなり相性がよくなる。現在の巨大数演算の乗算関数は配列をヒントにして作ったものであるため、配列とは相性がいい。関数を配列用に改造すればすぐに完成する…はず…。巨大な数を計算する上で最も重要なのが乗算なので、これができれば全体の半分は完成したも同然。

以下、14桁区切りの配列同士を高速に足し算する関数。onArray(x)は文字列・数値を配列に変換する関数。配列を使うと文字列に比べゼロを付加する処理が少なくて済む(というかイラナイ)。これにより文字列の場合より速く計算を行える。実際どれほどの実力かは乗算が完成しないとなんともいえないが…

big_add = function(A,B){
        
        if(typeof A == "string" || typeof A == "number")var add_At = onArray(A);
        else add_At = A;
        if(typeof B == "string" || typeof B == "number")var add_Bt = onArray(B);
        else add_Bt = B;
        
        if(add_At.length<add_Bt.length){
                add_A = add_Bt;
                add_B = add_At;
        }else{
                add_A = add_At;
                add_B = add_Bt;
        }
        delete add_At;
        delete add_Bt;
        
        var add_C = new Array();
        var add_up = 0;
        
        for(add_i=1;add_i<=add_A.length;add_i++){
                var add_Ax = add_A[add_A.length-add_i];
                if(add_i>add_B.length){
                        add_Bx = 0;
                        if(add_up==0){
                                add_C.unshift(add_A.slice(0,add_A.length-add_i));
                                return add_C;
                        }
                }else{
                        var add_Bx = add_B[add_B.length-add_i];
                }
                var add_AB = add_Ax+add_Bx+add_up;
                if(String(add_AB).length==15){
                        add_AB-=Math.pow(10,14);
                        add_up=1;
                }else{
                        add_up=0;
                }
                add_C.unshift(add_AB);
        }
        delete add_AB;
        if(add_up==1)add_C.unshift(add_up);
        return add_C;
}

私はこれがベストだと思っているが、もっと速くなる可能性も捨てきれない。というか、これとは全く違う計算方法で加算ができるかどうか考え中…。

最近GBAやってなかったが、久々に昔やってたゲーム掘り出してプレイ中。このストーリーやるのは12回目か…

愚作の箱にネタ追加。真面目なプログラムも思いついたがやる気がなかった。やる気があるときに作ろう。

台風14号
毎度毎度進路が東にそれることから、きっと今回も気象庁の予想より東にそれると考えている。四国辺りに突っ込めば水不足も一挙解消だが…それ以前に935hPaじゃ被害のほうが大きいか…
そういえば、台風の階級には「強い」「非常に強い」しかない。「弱い」といってしまうと弱いんだから問題ねーだろと山や海に出かけて死ぬといった事故が過去あったからだ。

日記に書いたことを記事に。量子暗号を擬似的に再現(実際に光子と飛ばしているわけではなく、光子の性質をシミュレートした)。プログラムにおける"量子的"な点はたった一つ、送られてきたデータの認識が確率的アルゴリズムで実装されているというだけ。受信者とハッカーはデータを確率的にしか得ることができない――何があるか分からない。たったそれだけ。しかしそれこそが不確定性原理。

不確定性原理を使ったものといえば量子コンピュータが浮かぶ。一応量子暗号と同じ理屈なのだが、量子暗号とは桁違いに複雑。3次元の球面上の複素数座標同士を論理演算するというワッケワカラン代物。現段階の理解度ではシミュレートは不能。

心身共に疲労しております。疲れてるときに勉強なんてできやしない。だから起こさないで先生(マテ

http://japan.cnet.com/news/sec/story/0,2000050480,20086898,00.htm
量子暗号の量子というのは、光の粒クラスの超ミクロな世界を指す。この世界では不確定性原理というものがあって、速度と位置を同時に測れない。この世界では物体は静止できない。さて、暗号通信にはまず暗号化に必要な鍵を送信する。量子暗号では送信者は2種類の偏光を持った光を受信者に送信する。受信者は光を受け取ってその偏光を検出する。検出方法は2種類あって、正しい方法で検出すると100％偏光を知ることができるのだが、間違った方法で受信すると不確定性原理によって送られてきた光の偏光は50％しか解析できない。結果的に共有されるデータは100％ではない。続いて受信者は送信者に鍵の受信方法を普通に教える。受信方法を聞いた送信者は、そのうち合っている部分の番号を教えて鍵の共有は完了する。共有される鍵は送ったデータの50％になる。

これが量子暗号の原理だ。このどこが安全なのかといえば、仮に盗聴者がいた場合、盗聴者自身も100％情報を解析できない。さらに送られてくるのは光子なのでそれ以上分割できない。盗聴者が受信した時点で送受信はストップしてしまい、送信者から情報が来なくなるので盗聴してる奴がいると判明する。また、盗聴者が受信者に情報を再送信したとしても、100％正しい情報を伝えられないため、結果的に送信者と受信者が共有できる鍵の数に揺らぎが生じる。この時点で盗聴者がいることが分かる。あとで送信者と受信者のやり取りを盗聴したところで、交わされているのは送信方法だけなので推測は不可能となる。

何れ誕生するであろう量子コンピュータによって、現在使われている巨大な2素数の積を暗号鍵にする方式は無効になるだろう。量子コンピュータは1秒間に現在のスパコンの数千倍の計算能力を持っているわけではない。量子コンピュータのアルゴリズムが―通常のコンピュータでは時間がかかるアルゴリズム(フーリエ解析・データ検索)より圧倒的に少ないステップで計算を行えることによって―数万ビットのRSA暗号をいとも簡単に解いてしまうのだ。ただし完璧な乱数であれば量子コンピュータのアルゴリズムを以ってしても体当たり攻撃しかない。技術力が進歩すれば、物理学の大原則によって守られているこの暗号システムは、数学的に安全性が確立されていない現在の暗号システムより絶対に安全である。

ミックスマスター・モンスターデータベース(未完成)
動物系実装。検索に要した時間の計測方法を変更。検索用関数が呼び出された瞬間から、関数の最後の処理が終わるまでの時間にした。今までは、関数がロードされてから表示関数がロードされるまでの時間を計測してたので、コストに検索フォームを読み込む時間を含めていた。

23:00

遂に認定(わら
もうキッズgooサーチを防ぐこともできない。

眠れない。(最低なスタート) 4:30

技術的興味でJavaScriptによるデータベースがやりたかったので、どうせならと思いミックスマスター・モンスターデータベース(未完成)を作った。データベースをいじるのに最低限必要なプログラムを内蔵し、バラバラのデータ同士をネットワーク構造的に結びつける。自動化されたプロセスだからこそ複雑なリンクを張り巡らすことができる。データの受け渡しはCGIと同じくlocation.search以下の文字列を取得してデータとして読み込む。CGIの挙動をJavaScriptで真似した、みたいな。

現時点でこのシステムが安定しているかどうかは不明。少なくとも"まとも"なデータをぶち込めばちゃんとした結果を返す。あくまで技術的興味なので、実用としてのデータベースを完成させるには今後データベースを大量に追加・更新する必要がある。実用目的での利用にはまだしばし時間がかかりそうだ。(仕様上、完成すれば1行のタグの追加でどこのページでも検索スクリプトを利用することができる)
一先ず現存のデータを全て収録しBETAにバージョンアップ。動的にインデックスを生成するなどのシステムを追加し正式版としたい。プログラムはミックスマスター用に一部チューンアップされているが、汎用的に作ったので他の応用も期待できる。