2005/12
5時起床。大晦日だろうが何だろうが22時に寝る。
だそうなのでリンクを全て削除するか転載リソースに張り替えた。ついでにトップページの文章も全部転載しておいた(何)。
本来ウェブサイトは存在しないのが普通で、存在する期間のほうが短い。もし転載禁止にしてしまうと、それは情報がどれだけ有用であっても有限の時間内に消滅してしまうことを意味する。しかし転載自由であれば転載されつづける限り、例え作者が死のうが情報は生かされる。
攻略に書いておこう。「理論的に可能でも現実的に不可能」。
パソコン授業でまず教えるべきは著作権侵害じゃなくてこっちだろうと。
自分のところはどんだけ攻撃されてるのかなーと確認してみると、この6時間に52回の攻撃と12回のポートスキャンを受けているようだ。6時間で52回ということは24時間に約200回。Yahooの記事の220件と見事に一致した。というわけで殆どのマシンが例外なく攻撃を受けてるはずなり。ちなみに52回中6回は親のマシンへの直接攻撃になっている。私のマシンは外部に対して完全にステルスで動作してるので攻撃を受けたログはゼロだった。
除算を実装したが、遅い。100分の1秒レベルの遅れが出る。そもそも当初の計画ではlong_mul関数と同様の効果を通常計算で引き出すだけじゃなかったのか。いつのまにかあれやこれやと装備を追加するうちに、逆に遅くなってしまったようだ。これでは本末転倒。入力されたデータ形式をそのまま用いるような複雑なシステムではなく、あえてVer.0.4のlong_mul関数の効果だけに拘る。余分な追加は行わない。追加はVer.0.4ファイナルと同じ速度が出てから行おう。
ページ上部の現在位置を示すリンクが論理的じゃないから不満。そのうち書き直す。
かつて長きに渡りデフォルトだったGrayスタイルに近いスタイル。大晦日から正月はこれにしておく。
なおSimpleは出来が悪いので削除した。
"ねおクエ"のデータ送信間隔がまた長くなった。10分以上現在計測中。
送信間隔がリアルタイムに変更されているかランダムかの理由で正確に計測できない。後日改めて調べる予定。
\e
HugeIntがややこしいことになってまただらだらと1日を過ごしてしまった。さらに最近起床時間が6時〜7時になってしまっている。
とりあえずこの狭い部屋に充満した空気を入れ替えるべく窓を全開にした。起床時間もなんとか元の4時に戻す。
20日に書いていた2の関数+1関数を実装し、文字列型と配列型を両方使えるHugeIntオブジェクトを作った。今のところalpha1互換の配列型で動いているが、文字列のほうが速いところを文字列型で行わせれば演算性能はさらに向上する。除算の実装もかなり簡単になる。
\e
時間停止バグが自然回復しやがった。
元々このバグのせいでやりこみ要素が完全に絶たれプレイを完全中止。今更復活しても頭の時代はルビーサファイアだけの時の状態なわけだ。先ほど公式ページを見てきたが、初期の作品の焼き直しと例によってルビーサファイアに機能を追加したものが発売されている様子。しかしGBA本体を2つ買うわけにはいかず、例え前作の焼き直しを買ったとしても今もっているヤツとは通信不可能。周囲にやってる人間もいないし今ごろ復活しても大してやることはない…。
ちなみに放置していただけで時間が再び進みだした原因は不明。
木の実の成長を確認。時間が完全に流れ出したことを確認した。
除算を組んでたところ非常にややこしいことになった。Ver.0.4は文字列ベースでVer.0.5は配列ベースのプログラムになっている。当然Ver.0.5はVer.0.4より高速なプログラムを目指したが、現時点ではVer.0.4のほうが速くなりかねない状態。というか、Ver.0.5のシステムでVer.0.4を再構成すると間違いなくVer.0.5を越えてしまう。
Ver.0.5自体はまだalpha版だから総書き換えする猶予は残っている。配列で実装したalpha1を残しつつ、alpha2はもう一度文字列で実装させてみる。その出来を見て初期構想だったArray+String型のVer.0.5を製作する。別物として開発するには双方に利点が多すぎる。新バージョンは旧バージョンより速くするということに拘る。
\e
HugeInt Ver.0.5、現時点で加算と乗算が完成。今回入力も配列なので今までのように一方が14桁未満のとき計算効率を上げるなどの小細工はできない。しかしメインの部分は文字列より配列のほうが処理が速く、最終的な演算速度は確実に向上している。
しかし単体乗算はどうでもいい。今回配列にした最大の理由は乗算を連続して使う処理の高速化だ。よって最も注目しているのはなんといっても巨大累乗。
また再三愚痴っているが、除算は配列より文字列のほうが圧倒的に速い。コイツだけは乗算も加算も減算も従来の文字列型アルゴリズムで行う。なお、除算で使う乗算は片方が絶対に15桁未満なので配列を組まなくても計算が可能。唯一コストが出るのは計算結果を配列に直すときだけだが、それ以前の乗算時に散々型変換をやらせていたので最終的な速度は絶対に速くなるはず。
やっぱこういうことに熱中しているときが一番楽しい。
累乗を実装した。Ver.0.5の大きな改良点は、Ver.0.4ではlong_mul関数という専用の連続乗算関数を使わないと得られない速度を通常計算で得られる点にある。案の定最初の2乗計算の速度が上がり、long_mulで実装した後半の処理はVer.0.4のままになった。しかし1万乗レベルの計算では余り大きな差はでず、決定的な差は2万乗以降に現れた。型変換のコストがはっきり露呈するのは桁数が大きくなってからなので、小さい数値や前半の2乗計算では差が出にくい。しかし桁数が一気に膨張する後半の連続乗算計算はlong_mulで高速化が終了している。そういうわけで累乗の場合最終的な速度は大して上がらなかった。期待はずれ…。
気を取り直して次は除算と階乗を作ろう。
階乗が完成したのでとりあえず公開。今後はHugeInt Ver.0.5開発日記にて開発を行う。
久々にポケモン サファイアを起動させてみた。かなり前に時間停止バグに陥り全木の実999個のやり込みを断念している。対戦のほうはとことんいやらしいレベル100を6体揃えて今のところ無敗だが、正確にはウザ過ぎて誰も戦ってくれない。
で、相変わらず時間止まってるだろうなーと思い宝くじを試しにやってみると、なんとできるではないか。確か時間停止に陥りできなかったはずだが、いつのまにかできるようになっている。ここで今考えられる可能性としては次の2つが挙げられる。
真実は明日明らかになる。
\e
今日の更新予定。
追記予定・・・
追記予定とか言っておきながら書くことが見当たらないオチなんだが…。
今日の更新で2756839の計算を達成し、目指す100万乗に向けて明日からHugeInt Ver.0.5の開発を再開しようかと思う。
\e
早朝からWWWCを起動すると更新されたページが多数。皆暇なんだなぁと。自爆。
現在デフォルトのGreen.cssがここまでよくなってしまうと、残りのGray.css及びSimple.cssが悪く見える。特にSimpleはシンプルというより手抜きなので改良したい。GrayもこのGreenから見ると下手だ。
(アトのページ)ここまで凄いとこっちもそれなりの敬意というか、引継ぎに値するページを構築しないといけないと思ってしまう。
Japaneseは日本人とも読める(というか日本人と読むほうが多い)のでこの記述は極めて危険。languageやwrittenなどの単語を入れ日本人ではなく記述言語が日本語であるという文章にしなければならない。ついでに頭を下げる(Sorry)必要もない。
ページの合計サイズは大して大きくはないが、リクエストするファイル数が多すぎるので表示が重くなっている。特にDynamicCSSが重い。単体ファイルのサイズが大きくなってもいいからリクエストする回数を抑えることで表示速度を改善する。
＞とむごんじじ再びさん
それはですね、カモを流しても、wt-7とゆう名前が多い人、（俗にちゃびん軍団？っていうのかな）にカモを流されてしまう感じだったんで、それを防ぐために10分にしたそうですよ。
カモ所有者の目的はカモを連続で送信し対人で狩れるようにすること。これに対しいわゆる"流し"は連続で続くカモを一箇所でもいいから切ればよい。つまり、送信制限を行ったところでカモ送信者が不利になるだけで、唯一考えられるメリットは管理者サイドの問題であるサーバー負荷削減しかない。
規則の濫用が行われ議論が意味を成さない掲示板に書いても意味がないと判断しこっちで。
\e
今日吹雪けば学校が休みだと思ったが、晴天。残念だ。しかしこのコンディションは水曜日と同じ。あのときは晴天だから楽勝だと考え登校した結果、行方不明になりかけた。注意せねば。
クリスマスという文化にはあまり興味がないが、折角のGreenStyleをここで使わない手はない。ということでベースCSSをGreenからXmasに変更した。実際のところリンクの色しか変わっていない。
日本国憲法やら何やらを改めてじっくりと読んでみた結果、見えかけていた理解がまた地平線の向こうに消えていくのを感じた。つか、頼りにする道しるべは日本国憲法だけでいいかもしれない。本来人権というものは人権擁護法案を名乗るようなどす黒いものじゃなかったはず。もし理解の途中で何らかのミスを犯し矛盾が生じたなら、今持っている汚染された意識を取り払う方法は再度憲法から理解を始めるしかない。
頭が固くなるのを防ぐある種の遊び
リンクの色が緑より赤のほうがしっくりくるということで、このXmas_base.cssをgreen_base.cssにすることにした。これによってXmas.cssは消滅する。
CSSといえば私はまだCSS Level.2のIEが対応していない部分を扱いきれていない。メインをOperaにする気は全くないが、徐々に扱えるようにしていきたいところ。
"暇だやることねぇ"は今日こそ効力を持つ言葉に違いない。23日に書いたように頭を働かせないとだるくなる傾向があるので、HugeInt Ver.0.5の開発でもやることにする。
相互サイトのShadow road?がリニューアルしたよーなので一応書いとく。私もそうだったが、作り直すたびに装飾がどんどんCSSサイドに移っている。それだけCSSによる装飾はHTMLより強大なものであるということだろう。またその反動としてHTMLはどんどん論理マークアップに近づいている。
にしても装飾上手い。これだけのセンスを得たいのでHugeIntに飽きたら4つ目のCSSを書いてみたい。CSSを動的変更できるメリットは製作者側が頻繁にCSSをいじれるということもある。
Xmas.css今ここに完全消滅(笑)。今のスタイルをさらに改良したいところだが、これ以上画像を増やすと負荷が大きくなるので止めておく。次に作りたいものはVer.7.xのときにあったPinkStyleに近いヤツと、20:20に紹介した相互サイトに近いタイプのスタイル。飽きたら作ってデフォルト値に上書きしてしばらく楽しむ。
\e
体がだるい原因は熱中することがないからだ。間違いない。HugeIntはしばらくやる気でないし…何か面白そうな企画を考えるか…。
昨日の更新でアトのページにあった情報を8割程度抑えた。残る2割は転載リソースへのリンクで補っているが、最終的には自前の攻略に加える予定。また攻略とは直接関係ないデータや少々過激なデータを削除した。現在研究とothersの分類がややこしいので、研究を分解するかothersを併合するか、考え中。
\e
ねおクエ攻略の引継ぎを宣言。といってもこのゲーム自体は絞り尽くしており、遣り残したことと言えば未だ完成していない机上の空論、"レベル22攻略"だけ。とりあえず近々攻略に転載したデータを盛り込み再構成する予定。私は情報主義者なので誰の提供かなんてわざわざ最初から書かない。閲覧者は提供者の名前なんて欲しくないだろうに。
ちなみに閉鎖予定のアトのページの転載リソース。
"その他"をどうまとめるかが鍵だ。
降雪と路面凍結はあるものの空が晴天ということで自転車で学校へ。しかし凍結した路面をノーマルタイヤで突っ走るのはかなりデリケートな操作が要求され、2つ目の堤防を前にして息切れしてきた。普段は堤防の上を通り、今日も堤防を通ろうとしていたが、突如暴風になったため田圃道を通ることにした。すると今度は猛吹雪で登校もできなければ帰宅もできない状態に…。しばらく立ち往生していたが、数メートル先が見えない田圃道を気合で乗り越えて親戚の家に避難。その後風が止んだ瞬間を見計らい全力疾走で帰宅。なんとか生きて家にたどり着いた。自転車だからまだマシだろうが、公共交通機関を使った奴らは今日一日終わったろうな(フフフ)。
結局最後まで吹雪の先にある学校の姿を見ることはなかった。
ついでにPCを立ち上げたらハードに問題が起こったとかで5回ぐらい起動に失敗した。
今まではサイトの初期スタイルはdefault_***.cssに直接格納していたが、初期設定を他のスタイルと入れ替える作業が大変。閲覧者の個々のマシンに保持されたCookieのこともあるので下手に名前を変えるとエラいことになる。そこで、default_***.cssから@importルールで個々のスタイルを呼び出す方式にした。設定したCookieの値がdefaultのとき@importで呼び出された初期設定CSSが読み込まれる。このほうが便利。ちなみにJavaScriptの代替CSS機能はブラウザの代替CSS機能と競合するので同時に使うと複数のCSSが同時に反映されてしまい危険。利用はどちらか一方で。
importルールに対応してなかったりmedia属性に対応していない旧式ブラウザのサポートはもはやしない。
そいやOperaがdocument.allに対応してるのに気づいた。Ver.7.xまでIEとOperaの判別ができてたのになんでかなーと思ったら、Ver.8.xでdocument.allに対応しやがった。そこで、IEを判定する際は!window.operaを判定させることにした。
21日に"無色の花"という名称はこのサイトのネーミングに似ている。名前を付けた理由も多分同じだろう。
と書いたが、その日のうちにスタイルシートをグレー以外のものに変えネーミングそのものをぶっ壊してた。…まぁいいか。
その肝心のCSSに不都合があったので現在色々と修正中。
\e
配列と文字列を両方用いるVer.0.5だが、加算と減算だけで関数が16も必要なことが分かった。はっきりいってこうなると手におえない。加算・減算は文字列が最高速度だが配列14桁でもロスは7％程度に収まる。その7％を覚悟で乗算の高速化のみに専念すればトータルでは確実に配列のほうが速い。唯一文字列メインの除算には従来の文字列型の加算減算を用いることでロスをゼロにすればいい。
…ちょっと熱中し過ぎたのでしばらく中止する。でも折角ここまで作ったのだから一度完成させたい。
"無色の花"という名称はこのサイトのネーミングに似ている。名前を付けた理由も多分同じだろう。
サイト名が変更されたということで相互リンクの名称を変更完了っと。
\e
8時間ゆっくりと寝たので眠気はなし…と思ったら昼寝したせいで眠気が。
HugeIntの関数名は半分ネタだったりする。"さくら"は入力に対し文字列型HugeIntオブジェクトを生成。"あいり"は入力に対し配列型HugeIntオブジェクトを生成する。前者はVer.0.4からの引継ぎでありString[文字列]のSで、後者はArray[配列]のAだ。StringとArrayを相互変換するには一定の計算量を消費するため、後者の配列型が使われる場面は少ないだろう。sakuraにしてもtypeS関数がまともに動作するのは乗算直後(配列出力)の除算に限られる。
HugeInt.sakura = function( input )
{
var output;
if( !input )output = new HugeInt( 0 );
else if( input.isHugeInt )output = input.Copy();
else output = new HugeInt( input );
output.typeS();
return output;
}
HugeInt.airi = function( input )
{
var output;
if( !input )output = new HugeInt( 0 );
else if( input.isHugeInt )output = input.Copy();
else output = new HugeInt( input );
output.typeA();
return output;
}
話がワンパターンになってきた。まぁこればっかりやってるので仕方ないけど。
\e
検索エンジンについて分かったこと。
旧式HTMLでは全くヒットしなかったものが論理マークアップに替えると面白いほどかかりまくる。下手な小細工をするよりよっぽどマシなSEO。
もう片方は当然といっちゃ当然だが…。
配列か文字列かの判断に迫られた結果、まぁとりあえず出力は各関数好き勝手にやらせて配列も文字列もどっちもアリでいけるように改良することにした。結局除算は文字列のほうが速く、乗算は配列のほうが速い。どちらかにしぼったとしても少なくとも除算の出力は必ず文字列、乗算の出力は必ず配列になってしまう。それらを変換するのにコストがかかるなら、いっそそのまま出力させといてデータ型の変換は次の関数に任せることにする。こうすると二重変換を防ぐことができる。また加算などは配列で入力されたときは配列で処理し、文字列で入力されたときは文字列で処理させることもできる。実にとんでもない発想。
当然ながらどちらか固定で結果が欲しいこともあるので、そういう場合は双方向に変換できる関数で整形しておく。
そもそも意見が一致しないから国として分離しているんだろうが。地球上に絶対的な善悪の基準が存在すれば世界に200個も国はいらない。価値観が違うことは分かりきっているのに無理にでも自国の考え方を強制しようとするやり方が非常に気に入らない。ああそれが意見の不一致か！
ということで私の意見としては相手国が干渉してこようが無視してよいかと。相手が突然金くれと言っても渡す必要ないんだし、相手国のふざけた要求を無条件で容認するのは独立国家して最も愚かな行為だし。
各関数の主要計算アルゴリズムはVer.0.4を採用しているものの、配列と文字列のデータを両方扱えるHugeIntオブジェクト及びデバッガなどの一新を図るためVer.0.4とは別物になる。よってこれをVer.0.5とする。個々のJSファイルはメインの演算関数のみにし、デモや外部出力には専用のファイルを用いることにする。外部呼出し時にはその専用ファイルを読み込まなければ自動的にステルスモードで動作するという仕掛け。
配列で攻めれば除算が落ちる。文字列で攻めれば乗算が落ちる。最終的なデータ型変換コストが同じなら二重変換を防げる配列+文字列型が最速だと考えられる。下手なミスをしなければ10万乗級の巨大累乗計算のスピードがさらに1.5倍以上上がるはず…。
\e
朝起きると外は雪景色。そろそろ缶コーヒー(冷)を飲むのが辛くなってくる。
beta8のバグ修正に引き続き、beta9は大幅な仕様変更を行う予定。beta8で外部呼出しをやってみたが、現在の仕様だと外部呼出しに手間がかかる。JavaScriptのファイル数も19個あり、外部呼出しするには少々多すぎる。ファイル数を減らしメインプログラムのHTMLとの連動をできるだけ絶つ。
スタイルシートはどのように切り替えるのですか？
捉え方が複数あって困るが、このサイトのスタイル変更機能の実現方法を聞いていると理解します。
このサイトのスタイル変更機能はMozillaやOperaに搭載されている代替スタイル選択機能をJavaScriptで実現し、尚且つスタイル変更ができないIEでも機能するようにしたものです。WebSite作成系のスタイルシートを切り替えるにてサンプル及び解説を(今)書きましたので参考にしてください。
転載リソースにアトのページを追加。WWAは改造しないと転載させてもらえないようなので削除。というか改造したら転載じゃなくなるんだが…。あとリンク集はバナーの一つが私のOSを壊しかけてムカついたから消した(なんちゅー理由だ)。できれば完全なミラーにしたかったが…まぁ必要な情報さえ残ればそれでいい。
\e
昨日言ってたlong_mul関数を作成。累乗や巨大累乗の剰余では膨大な数の数値を一気に掛ける処理があり、桁数が上がれば上がるほどlong_mul関数の比重が増し速度が上がる。beta6で7秒半かかった250000はbeta7では5秒で計算できた。
累乗に関しては最初の処理でも2乗計算を連続で行うため、累乗専用の連続2乗関数を作るとさらに高速化が可能。後半だけで50％高速化したので、最終的には元の2倍のスピードで計算できるようになるはず。
long_mul関数でミス発覚。配列の要素がゼロだけになった場合結果が狂うことが判明。しかもコードを1行消すだけで改善された。
また、開発用のHTMLだと見づらいのでデモ専用のページを作成。alpha8以降試していなかった素数検索デモを置いた。
\e
デフラグやってHDへのアクセス速度は回復したが、タスクマネージャを見ると明らかに無意味なプログラムが走っており、レジストリの汚染が伺える。レジストリに関しては無知なのでこれを期に勉強しようかと思う。
乗算プログラムは内部的に配列で行う。累乗計算時は乗算を連続で行うが、その場合配列で表された巨大整数を文字列型に変換する処理は時間の無駄だ。加算・減算・除算で多少の計算量増加を許すならデータの格納形式自体を配列にしたほうが連続して乗算を使える。そうでなくとも複数の数値を一気に入力し、まとめて全部掛け合わせるlong_mul関数を作れば累乗・巨大累乗剰余の演算速度が上がると思われる。
仮にVer.0.5を作るとすれば個々の関数間でのデータの受け渡しが最速である配列を使う。結局要の乗算が一番速い組み合わせが最速なのだろうか。
中学教科書から人権の定義が最初から複数の権利の集合であったという記述を見つけた(というか何をやってるんだ)。最初から複数の権利の集合だったのかよ、と落胆するが、では何故国が名誉毀損とは別に人権侵害を定義するのか。また、過激に行われている人権教育において誰一人集合の要素を挙げようとしないのか。私は人権教育で人権以外の人の権利なんて聞いたことがない。教師に尋ねても"常識"という極めて非常識な方法で反論すると推定され全く役に立たない。第一私の学校のインターネット上のブログにおいて、指示語が指し示す内容が存在しない穴の空いた記述を何度も目撃している。
ユークリッドの互除法ページで、「最大公倍数」となってます。
指摘ありがとうございます。即修正しました。
全ページにある代替スタイル選択枠の横にほぼギャグ目的のリンクを作ったにょ。表示環境はIE及びOperaにょ。
\e
久々にまともな更新を行った。
気づけばJavaScriptをOFFにしてネットサーフィンしてた。ActiveXはとっくにダウンロード不可にしてあるし、長い間ネットを続けるとどんどんこうなっていくのかな。
人権は既存の権利を曖昧にして権力者が後から定義を追加できるようにするための危険な権利である、という結論に達した。皮肉にもこの結論に導かせたのは人権教育である。人権という権利は生存権・環境権・平等権・表現の自由などの既存の権利に細分化できる。また、人権侵害は名誉毀損で処理できる(国が発表した人権侵害の定義は殆ど名誉毀損と同じ)。何故既にある権利を包括するのかを考えたとき、導き出された結論は"後から好きに改竄できる"ことだった。定義自体が曖昧であることは人によって複数の解釈を生む。そしてどの解釈を採用するかは結局権力に依存してしまうのだ。人権は一つの権利ではなく複数の権利の集合体であることを明示し、個々の権利の定義を詳細に記すべきである。さもなくば廃止すべきだ。
国家間の条約においてもこれまで解釈問題は何度も起こっており、厳密性が求められる法律・条約において曖昧な定義を用いるのは極めて危険。
Googleサイト内検索「愛」の結果。今年の漢字である愛が使われたのは2005年9月だけで、しかも検索結果に表示されている文章の内容がぶっ飛んでるのにワロタ(我ながら)。
検索されているワードとページ内容を見ると「できる」のにやってないことが多い。素数検索などで結構検索されているで最新の巨大整数計算プログラムで強力な素数判定プログラムを提供すべきかと考えている。JavaScriptの最大の利点はダウンロード不要でアホな計算ができることにある。
\e
いつも以上に冷える。
階乗の計算速度が倍になった。階乗に限らず乗算関係全てが少しずつ速くなった。この高速化は全体のアルゴリズムの問題ではなく計算結果をいかに低コストで代入するかという問題。
\e
ネタはあるが切り出せず。仕方がないのでもう少しHugeIntを煮詰めてみる。あれは構造が複雑すぎてインクルードに障害が出そうな予感。
今の時間はこれにて。
階乗を30％ほど高速化。例によってデモ用関数のデバッグ出力部分でタイムを落としていた。
現実的な二題。国語の時間に俳句を作れと言われたが、「PC」か「勉強」か「以下のようなこと」しか頭にない。作れないOTL
こういうのを見ると正しいことをやっているように錯覚するが、自然界で生物が絶滅するのは日常茶飯事であって絶滅の危機に瀕しているということは生存能力が弱く生態系にとって不必要だからだ。生態系の変化についていけない生物を保護するのは人間の単なる珍しい物好きに過ぎず、そんな考えが地球を救うわけがない。また生態系というのは人間の活動も含めるわけで、人間は自分たちの活動が"特別なもの"だと考えているようだが大して特別ではない。早く自分たちも生態系のシステムの中にいることを自覚し、物理法則を無視したリサイクルや自然から資源を隔離するゴミ処分場などを考え直すべき。
\e
3時起きのつもりが2度寝して6時に…。不覚。
for (i = 0, j = passlen - 1, k = 0 ; i < enqlen ; i++, j--, k=0)
{
if (j < 0)
{
j = passlen - 1;
}
chr1 = indexbase.indexOf(keyin.charAt(j));
chr2 = indexbase.indexOf(encrypted.charAt(i));
if (chr2 < (chr1 + j))
{
nbase = (chr1 + j - chr2) / 0x5f;
k += (0x5f * Math.ceil(nbase));
}
k += (chr2 - chr1 - j);
decrypted += indexbase.charAt(k);
}HPビルダーのパスワードリンクは一度諦めたが再挑戦。調べるとデコーダは上に引用した部分だけだった。そしてデコーダを通したデータにはリンク先のURIとパスワードがつながって出力される。攻略すべき問題はchr1 = indexbase.indexOf(keyin.charAt(j));であり、このコードは入力されたパスワードで復元を行っている。
これも私が作ったパスワードリンクと同じ問題を抱えていそうだ。出力パスワードの長さは入力パスワードの長さに依存するが暗号データ自体は有限であるため、入力パスワードの長さを総当りして入出力が同じになるパターンを逆算すればよい。最悪の場合でも9025パターンであり、これは一瞬で終了する。
今回は原理だけで具体的なプログラムはまた今度。やる気があれば。
ブログのリンク先は
http://shadow07.s144.xrea.com/blog/ms.cgi?t=sketch&blogid=&ShowDiary_file=/zakki/1134272949
ですよ。
指摘どうも。修正しました。何があったか分からないがCGIに渡すパラメータが2重になっていた。
\e
ここ数ヶ月デフラグをやってなかったことに気づきデフラグを行った。過激に遅かったのはデフラグをしてなかったことが原因だったのかも。
ファイル削除がかなり軽快になった。1分も待たずに済む。
かなり前(中学時代)から是非とも全巻揃えたいと思っていたが、調べてみたら私が読んだものは既に絶版。新しいのが出ているようだが1冊1000円で、現状でこれを狙うのは無謀と判断した(最近他のタイトルを揃えたばかりだし)。
Latin-1コードの変換関数。こういうのをやたら使うサイトだから1発で相互変換できるようにしておく。スクリプトライブラリでも作ろうか(実はもうあるんだが)。
function encode_l( input )
{
input = String(input);
var output = new Array();
var i = new Number();
for( i=0 ; i<input.length ;i++ )output.push(input.charCodeAt(i));
return output;
}function decode_l( input )
{
if(typeof input != "object")return null;
var output = new String();
var i = new Number();
for( i=0 ; i<input.length ;i++ )output += String.fromCharCode(input[i]);
return output;
}
久々にプレステをやったが、ソフトの1つが相当バグってるっぽくミレニアムファルコンの挙動が理解不能。結局止めた。
正直リニュアールする前の方が見やすかったです（TOP
見づらいと思う個所を指摘してくださればこちらも対処できますので、気兼ねなく報告してください。どこが見づらいか分からなければ対処できませんから…。
そもそもこのリニューアルの目的は見栄えじゃなくてHTMLにあったり。
興味深い2題。批判するときはされる側にもなんらかの意見を提示する必要がある。単に罵声を浴びせるのは批判にすら該当しない言葉の暴力だ。
常識的に考えて子供が非行に走るのは十中八句教育・対人接触の問題のはずだが、何故か全責任をゲームに押し付ける。まぁ実際ゲーム(特にアクションモノ)は反射神経を鍛える一方前頭葉を鍛えないから、何かあったときに反射神経が優先され先に手が出てしまうということになる。だが子供のほぼ100％はゲームをプレイしており、同じゲームをプレイして問題を行動を起こした子供と起こさなかった子供を分けたのは一体何かといわれれば、間違いなくそれは教育であろう。子供は大人を映す鏡というのはまさにこのこと。
人権教育には私もうんざりしたことがある。特に手のない障害者がどーとかで、教師が生徒に足で字を書かせたこともあった。恐らく障害者の苦労を知ってバリアフリーな社会を目指せという理屈だが、私たちにとっての足が彼らにとっての手であることを忘れている。足で字を書けるなら字を書くという動作に関しては見事にバリアフリーが実現していると捉えるべきだ。そして我々が彼らにすべきことは、足では代替できない手の動作を手伝うことだけでよい。過剰な同情なんて必要ない。人は平等だろ。
今のような過剰な人権教育を受けたのは最近になってからだ。全戦争を否定させ自国嫌悪感を植え付けさせるように、過剰な人権意識を植え付けかの有名な人権擁護法案を通すつもりなのだろうか。重大なのは今まで散々受けてきた人権教育の中では、人権という権利の厳密な定義を一度も与えてもらえなかったことだ。試しにGoogleで「人権 定義」を検索すると案の定かなり議論されている様子。この際言ってやるが、人権を突き詰めると表現の自由と衝突する上に物的証拠を伴わない。そんなふざけた権利なんかさっさとなくすか、物理的証拠を伴い個人の主観に依存しない人権侵害を真の人権侵害にすべき。
Web関係のサンプル集のサンプルが結構な量になってたので分類分け。今日載せたLatin-1コードも日記で情報量がたまれば載せる予定。いっそ全記事を日記で書いてから"焼き直し"として記事にするのもいい。
トップの更新履歴とメニュー、
いままでは横にならんでいましたが、
今はずれていて、白く、何も無い所がたくさんあります
環境
OS XP
ブラウザ IE
横にお気に入り表示(表示しなくても同じでした)
ブラウザとOSはどうでもよくて重要なのはお気に入り。手元のIEでサイトバーを表示させた状態で画面解像度をXGA、文字サイズを大にしたところ、段組が崩壊した。これをVer.7.5で試したところ正常だったので、相違点を見比べ問題点を<h3>のborder-widthの値が問題であると断定した。念のため改行が効かないContentsをさらに短いMainに変え、問題のborder-widthを2emから半分の1emに変更。これでまず崩れることはない。また、2段目の日記の段組は幅が210pxを下回るとどう足掻いても画像が収まりきらずに破綻するので注意。
この指摘をしてくださった方には正常に表示されることを確認するために(できれば)連絡をしていただきたい。
\e
サイト一新。とりあえずHTMLは完璧だがCSSとJSは"仮"状態。日記は人間には編集不可能なので旧仕様。細部の修正は今後行う。
細かい修正が終わったら真面目に平常業務に戻る(業務かよ)。
代替CSSは現在使用不能だが、後に復活予定。
新しいHTMLの拡張性を試す実験として代替スタイルにSimpleを追加した。段組としてではなくメニューバーとして実装したHTMLだと配置は自由自在になる。外部JSなどの最適化が終わってないので現在修正中。一通りコードを整理したら改装終了。
リンク集に韓国は“なぜ”反日か？を追加。義務教育で散々日本の戦争(大東亜戦争)が悪いことだと教えられてきた人は必見。Googleで韓国史を検索すれば分かるが、あの国の歴史はヒットするサイトごとに違う。Wikipediaも韓国に関する記事は書き換え合戦で保護対象になっている。
バカ教育はインターネットの情報は信頼性に欠けると云うが、本当に信頼できないのは小数の人間に掌握された一元論的ニュース番組(NHKなど)である。それに比べれば多くの情報にあふれ政治的圧力のかかりにくいインターネット上の情報のほうがよっぽど信頼できる(もちろん間違った情報もあるからたった一つの情報源を信じてはいけない)。
\e
3時半起床。だんだんキチガイになってきた。この時間帯の空気が一番きれいなので星でも眺めた後窓を開け空気の入れ替え(自殺行為)。
日が昇る前に日記の編集に入りたい。
予定より半日送れている。21時をまわって残すは日記だけとなった。今後もHTML総書き換えがある可能性があるので、日記のHTMLをメインのシステムから独立させることにした。これ以上あんなふざけた量の編集はごめんだし。HTMLの準備が整って初めてJavaScript+CSSをいじる楽しみができる。ファイル転送に結構かかるので明日やるとすれば早朝しかない。
\e
日記さえもてきとーな状態だが1秒でも多くHTMLの編集に当てたいのですよ…。では。
凄いことにサーチエンジンにヒットするページの2位が連立方程式の記事だった。上位は殆どねおクエ攻略で埋まっているがこれだけは上位に食い込んでいる。こんだけ参照されるとなると行列展開の高速化を。
先日<h1>〜<h6>をheadlineなどと書いてましたがheadingでした。
今日で日記とWebSite作成系以外の編集を終える。情報量がとにかく膨大な日記には休日を丸一日費やすと思われる。現在出来上がっている"仮"スタイルシートで公開するのが不十分なら日曜に延期する。
これしかやってないので他にネタがない。
今度既存の記事に追加する関数でも書いておくか…。配列をコピーするのに一々forループを書くのは面倒なんでprototypeに追加する関数。
Array.prototype.Copy = function(){
var Result = new Array(this.length);
var i = new Number();
for( i=0 ; i<this.length ; i++ )Result[i] = this[i];
return Result;
}
\e
普通の人間はいつ寝ても大体同じ時刻に起きるが、私の場合いつ寝ても6時間後に目覚める。昨日比較的遅い0時前に寝てしまったため、起きたのは6時。
キーワード検索を試しているが、便利。というかWeb狭い。かなりメジャーなワードなのに上位10位かよと。一番多かったのは「ねおきでクエスト」関係であり昨日6時間で40回以上の検索があった。続いて何故かメルセンヌ数､行列など数学的なものが続く。優れたページならもっと他にあるのに何故かかるのかを考えてみたが、もしかしたらHTMLに余計な装飾(特にテーブル)がないからかもしれない。「タイトル」「ディレクトリ構成」「ページ概要」の3要素がHTMLの上にあるのがデカい。
ブログじゃないのに本当にいいのかなと。(そもそもブログの定義は何だということだが)
愚作の箱すら作業が終わらず。遅れ気味。本当に土曜に間に合うのか。
やっと愚作の箱の改修が終了。日記フォルダとWebSite作成系以外は楽にいけるので先にそれらを潰す。日記(ラスボス)は最後に片付ける。今日中に日記とWebSite作成系以外を仕上げる。
\e
室温、7度(AM4:30)。流石にヒーターつけた。ただし氷点下以上(外気温は3度)なので雪ではなく雨が降っている。
愚作の箱トップフォルダに含まれるHTMLを書き換えた。残るは深層フォルダ。愚作の箱は先に潰しておくと後が楽になる。しかしながら日記の書き換えが最大の難関。8月に一新したときはファイル数が4つで、この4つの編集に相当な時間を使った。あれからファイル数は2倍に増え9ファイルになっている。果たしてこれを編集できるのか。
多くの原子を持つ分子を用いた量子コンピュータについて考えていたとき不意に気が付いたが、高い処理能力を持つ量子コンピュータを得るために原子をどんどんつなげていったら、最後はDNAになるのではないか(Wikipediaを調べたらDNAコンピュータがあった)。どっかの科学系のニュースにも細胞は量子レベルで動いているという記事があったが、下手をするとDNA自体が量子コンピュータかもしれない(それも30億ビット)。これは今の人類の科学技術からすると途方もない世界。21世紀の技術なんて"単細胞生物"にすら到達できていない。
関係あるかないか分からないが、今までは原理的に人間を構成する全ての物質をスキャンして再構成すれば、全く同じ物ができあがると考えていた。しかし量子システムで動いているとなるとコピーできたとしても50％しか正しくならない。つまりコピー人間は同一人物にはなりえない。
このサイトはtrack feedでリンク元解析を行っているが、今までサーチエンジンのキーワード解析のサービスが欲しかった。もちろん既存のアクセス解析サービスにその機能を備えているものもあるが、Cookieによる追跡システムが大嫌いだから閲覧者にもさせたくないという理由で全て却下してきた。track feedを運営しているところが新たにtrack wordのサービス(alpha)を開始したようで試しに設置した。ブログ専用だろという突っ込みに関してはtrack feedを登録したアドレスにアルファテスタ募集のメールが来たということで。
1日200回以上ある"未知のワード"からのアクセスが分かるのはHTML構成時に有効なデータになる。
その肝心のHTMLだが、今愚作の箱を仕上げ中。細部の修正を含めると土曜に間に合わせるのは困難を極める。
\e
起動時のCPU温度12度。今日は一段と寒い。
Ver.8予定のHTMLが完成。今以上に簡単なHTMLに仕上げた。CSSもデフォルト用は完成し、サイズも今の9KBから6KBになり容量を3KB削減。やり方次第ではもっと縮む。
HTMLの大きな変更点は定義リストで、この日記などは各日日の最外殻要素が定義リストだが、これを見出し(headline)に変える。昨日"headline要素とdl,dt,ddの区別が曖昧"と書いたが、定義リストの乱用が全体のエントロピーをさらに増大させている。ならばこの使用を最小限のとし通常はheadlineを使えば無意味なクラス属性を抑えることができる。
また、"段組用のdivクラス属性であるfloat,clearが非論理的"と書いたがこの点も修正。段組目的でCSSを使わずコンテンツのリストを段組にする場合最外殻を<div class="contents_list">で囲い論理的な意味を持たせる。トップページのような7:3の段組は<div class="menu_list">で囲い、中を<div class="menu">と<div class="body">に分け実現する。
基礎が固まった。今週末にリニューアルする。表面(デザイン)上はほとんど変わらないが、記述されているHTMLは全くの別物になっている。とりあえずHTMLだけきちんと書いておけば後から幾らでもCSSで修正が利くのでデザインは放置して先へ進めている。
風が強い。こういう日は大抵次の日が雪であることが多いが、明日はどうか。現在のCPU温度は21度、6時間連続起動させているがファンから冷え切った外気を取り込むので低温を維持している。
前回のリニューアルで大半の<br />は根絶したはずなのに、まだ結構残っていた。次こそ葬り去る。明日中に愚作の箱を全て一新する。1700個あるサイトのファイルのうち1000個が集中している愚作の箱を潰せば一気に50％進むことになる。
\e
昨日の物理のヤツをまだ考え込んでいる。問題点を1つ潰したが速度関数を求めるには至らない。そろそろ集中力の限界orz。
「知るか」「どうでもいい」「なんとでもなれ」とか思い出したので集中限界。一旦休んで冷静に考え直す。
向上心とは恐ろしいもので、現在のサイトのHTMLが気に食わなくなってきた。理由は以下のとおり。
よくよくCSSによる装飾をするとリニューアルの手間が省けるだとかいうが、実際のところXHTMLに凝ってCSS全開のバカというものはHTMLをやたらと修正しまくる。おかげさまでこのサイトも6回のHTML書き直しをしているが、毎度毎度境地に達したといっておきながら時とともにエントロピーが増し破局に向かう。
こうなってしまう最大の問題は表では「論理マークアップ」を心がけているつもりが、無意識的に表示を意識してしまうことにある。「見え方」という概念を完全に葬り去りCSSによる装飾を意識せず純粋なHTMLのみに集中することが重要だ。また、CSSが特定の型のHTMLにしかマッチしないのも問題。的確な論理マークアップがされている限りどんなHTMLに適用できるほど柔軟なCSSが理想である。今後の方針は2つ。
これらが達成されなければCSSの変更だけでサイトをリニューアルするという極めて柔軟なHTMLは誕生し得ない。
何を言っているのかというと、つまりサイトの全HTML(現段階で164ファイル)を全て書き直す。今のサイトでは論理マークアップを100％実現していない。
\e
beta3。まともな更新はない。10進数を100進数に変換するデモ(一種の実験)を追加しただけ。
他、特になし。sin,cosの表を小数点以下100桁精度で作る他にやることが見つからない。
あえてfloatで段組を作る姿勢が気に入った（何。
Firefoxで<h6>の位置がおかしくなるのは<h6>の上下にはデフォルトで1emのマージンが含まれているからだ。Firefoxはマージン指定に忠実に従い余白をつけるがIEは上に文章がないから勝手に補正するが原因と考えられる。解決策としては<h6>のスタイル指定にmargin-top:0px;を追加すればよい。
先ほど掲示板にCSSについてのレスをしたが、標準準拠モードと過去互換モードの差を吸収するのが意外に面倒。XHTMLではMozillaが標準で動いてIEは過去で動きやがるので、CSSの指定が微妙に違う、このためわざわざIE用の拡張CSSを読ませているくらい。Web言語の難関は多種多様なブラウザへの対応に違いない。
\e
beta2、昨日言ってた除算の桁数問題を解決。まともに商を14桁ごとにしても前は失敗。そこで±2以上でも補正可能にした。単なるwhileなのであまりにデカい誤差が出ると手の施しようがないが、ここでは±5程度の比較的に小さな誤差を想定した。前回失敗したフェルマーテストをやらせたところ、見事余り1と答えた。前のようなミスは起きていない。
どちらかが7桁以下のときの乗算も高速化。単に2倍にするときなどは今までの倍の効率で計算できる。
\e
空が晴れているとよく冷える。
3時に起床したが誤って2度寝してしまい4時40分に...。100分のタイムロス。スターウォーズエピソード3を観る予定だったのだが今日の午後に先送りすることとなった(テスト中)。ちなみにスターウォーズはSFに分類されるが、個人的に時代設定が現代ではないのであまり好きではない。あと何よりストーリーの順番がややこしい。
JavaScript以外でなんとなく「分かる」プログラミング言語は今のところCぐらいだが、個人的にはD言語をやりたい。誰も使わないJSでふざけた計算をするのと同じ志向で比較的マイノリティーなDを。
今作っているHugeIntライブラリのコードは何気に型宣言が厳密な言語への移行用として作っていたりする。JavaScriptでは型宣言は全く無用だがわざとvar x = String()とか、関数の最初に全ての変数を宣言するとか、コードを適切にインデントするとか。ただどう頑張っても文字列or数値の区別が限界で、int,longなどはできたとしても効率的ではない。以下、できるだけ美しさにこだわったエラトステネス実行関数(JS)。引数に自然数をつけて呼び出すと一般にはその自然数以下の素数を返す。
function test( input )
{
var lists = new Array( 2,3,5 );
var i,j,Tmp1,Tmp2 = new Number();
var max = parseInt( input,10 );
for( i=1; i ; i++ )
{
Tmp1 = 6*i + 1;
Tmp2 = Tmp1 + 4;
if( Tmp1 > max )break;
for( j=0 ; j<lists.length ; j++ )
{
if( lists[j] > Math.sqrt(Tmp1) )
{
lists.push(Tmp1);
break;
}
if( Tmp1%lists[j] == 0 )break;
}
if( Tmp2 > max )break;
for( j=0 ; j<lists.length ; j++ )
{
if( lists[j] > Math.sqrt(Tmp2) )
{
lists.push(Tmp2);
break;
}
if( Tmp2%lists[j] == 0 )break;
}
}
return lists;
}
数学のテスト範囲であるベクトルは正直終わったかと思ったが、予想に反して問題を解くことができた。テスト前に覚えたことはやった一つ、ベクトルは方向と大きさを持つ単位であるという定義だけ。幸いにも昔に行列をやっていたのでベクトルを成分に分解できさえすればなんとでもなってしまった。
個人的にエレガントだったのがaベクトルに垂直な大きさ2のベクトルを求める問題。求めるベクトルの成分を未知数して垂直なベクトル同士の内積=0から方程式を作る。この方程式の未知数は2つありそのままでは解けないので未知数の片方を1とおいたときのもう片方の未知数を求める。この2つがaに垂直なベクトルの成分となり、さらにこの成分比を保ったまま大きさが2になるような組み合わせをピタゴラスの定理から逆算し目的のベクトルを計算した。聞くところによるとこれは公式で一発で出るそうだが、得体の知れない公式より上記の方法のほうが遥かに美しい。
結局10個の大問のうち半分は捨て、もう半分を2回解いて1回検算した。検算があっていたので問題文の意味さえ理解していれば少なくともやった問題の正答率は100％と想定される。
HugeIntの円周率計算が完成したのでコードを整理してbeta版製作中。
beta1、ソースコードを整理しただけで速度差はない。今後の高速化の課題としては、精度限界が15桁のはずのJavaScriptで何故11桁の精度でしか除算が正しく実行されないのかについて。概算でも絶対に15桁±1の精度で商を得られるはずだが、どういうわけか計算がおかしくなる"場合"がある。14桁の精度で商を得られれば除算はさらに高速化される。ついでに15桁未満用ではもう実装されているが、非除数を補充するときに一旦非除数の全数値に還元せず必要な桁数のみを補充する方法を用いても多少の高速化が期待できる。
\e