syswrite ってどういうときに使うだろう?
google で syswrite を探してちょっと眺めてみる。
つまり、世の中の人は、だいたいにおいて バッファリングをしない書き込み位の認識しかないのであろう。 要求がそれだけなら、これは出力した後 flush するほうが stdio との混用による面倒がないぶんマシである。
そして、返値を検査していないコードがたくさんあることから、 partial write の可能性を知らないか、無視しているひとが多いこともわかる。 まぁ、明示的に non-blocking に設定されない限り partial write は起こらないので、 これは正しいわけだが。
唯一まともな理由だと思ったのはアトミック性か。
浅井達哉, 半構造データからの頻出パターン発見アルゴリズム, 第13回データ工学ワークショップ(DEWS2002)
ちょっと(ナイーブに)実装してみる。
Paul Graham はプログラムの複雑さは(頭の中に描く)構文木のノード数だと主張する。
さて、ここで頭の中に描く構文木と、 処理系の中に作られる構文木はどのように違うだろうか?
たとえば Lisp でプログラムを書く場合、 プログラムは S 式であるから、たとえば cons セルがノードになるのだろう。 しかし、頭の中でプログラムを cons セルの連なりとして捉えることは多くないように思う。 まぁ、マクロを書くときはそうすることもあるけれど。
では、頭の中に描く構文木とはどんなものだろうか? S 式のリストをひとつのノードとしたようなものだろうか? abstract syntax tree だろうか? あるいはもっと他のものだろうか?
また、cons セル(のような concrete syntax tree のノード)に 重みづけして複雑さを値として求めてもよいだろうか?
さらに、そうするとしたら、その重みの適切な値を実測することは可能だろうか?
ひさしぶりに読書キューを空にした。
思うのだが、ノベライズというのは質が悪いものが多いように思う。
というか、質の下限が低くて、平均が下がっているというべきか。 また、上限はオリジナルなものと同じだと思う。 これは想像するに、オリジナルに比べて質が悪くても売れて、 採算がとりやすいためではないだろうか。
というような想像が正しいかどうかはともかくとして、 そのような認識をしている人間があえてノベライズを買うには ある程度のきっかけが必要である。 たとえば、いろんな人の感想だとか、気に入っている作家だとか。
さて、ここにノベライズがあって、 それなりに気に入っている作家と全然知らない作家の共著だった場合、 買うべきか、買わざるべきか?
まぁ、結局のところ 「ナースウィッチ小麦ちゃんマジカルて 小麦大乱戦・ゲーム世界からの脱出!」は 買ってしまったのだが、あまり正解ではなかったような気がする。
さすがにナイーブに書いただけあって遅い。
アルゴリズム自体が遅い気もするが。
キューが空だと、買う欲求に対する耐性が下がることに気がつく。
日本語入力で、状況に応じて挙動を変えると効率が良くなることがあるが、 「じしん」を変換するのに、 ふつうは最初に「自信」や「自身」に変換されるのが適切にしても、 地震が起きた直後は即座に「地震」に変換されるというのはどうだろうか。
(Ruby の) SDBM を試してみる。
うぅむ。長さ以外にも制限があるのか?
% rm ww.{dir,pag}; ruby -rsdbm -e '
d = SDBM.open("ww")
d["\373\221"] = "a" * 534
d["\371\367"] = "a" * 477
d.close
'
sdbm: cannot insert after SPLTMAX attempts.
-e:4:in `[]=': sdbm_store failed (SDBMError)
from -e:4
そんなエラーを出されてもなぁ。
Unix Incompatibility Notes: DBM Hash Libraries
うぅむ。1018bytes か。
しかし Solaris で試すと 1017bytes なようなのだが...
お、survey があるか。
Jeffrey Scott Vitter, External Memory Algorithms and Data Structures: Dealing with Massive Data, ACM Computing Surveys, 33(2):209-271, June 2001.
えーと、タイトルのところの massive data の文字が大きいのは意図的なんですかね?
うぅむ。論文内のタイトルでも大きい...
XTemplate を使ってみる。
テンプレートは concrete syntax とみなせるのかもしれないと思い至る。 まぁ、concrete syntax tree たる生成する対象の構造を 表現してるんだからあたりまえか。
だが、そうだとすれば、 それに対応する abstract syntax とを考えることができる。 ここで abstract syntax tree はなにかといえば Amrita のデータみたいなのがそうなのかもしれない。 すくなくとも繰り返しと配列の対応は自然だと思う。 でも、ふつう syntax といったら繰り返し以外にも要素があるわけで、 たとえば、regular expression なら連接、選択、繰り返しがある。 まぁ、連接はただ並んでいるというだけだから問題ないとして、 選択に対応するものは必要ないのだろうか。
まぁ、繰り返しを利用して選択(を含む構造)を作ることはできるので不可能ではないのかもしれないけれど、 やりにくくはないのだろうか。
を読み返す。
XMLStarlet pursues a goal to create a commandline XML toolkit to transform, query, validate, and edit XML documents and files using simple set of shell commands similar to the way it is done for plain text files using grep/sed/awk/tr/diff/patch.
問題に行きあったら、なにはともあれ現状保存である。 再現できなければ話にならない。
だが、サーバが絡むのは難しい... とくに自分の管理の及ばず、さらに日々刻々とコンテンツが変わるやつは。
問題を保存するようにプログラムを削っていく場合に、 だんだん問題が起こる率が下がっていくようなときにはどうしたらいいだろう?
テンプレートが syntax であるとすれば、 生成だけでなく、パーズすることだって不可能ではない?
帰る前に ML にメールを出し、帰ってみるとまだ届いてなかった。
Linux だと socket に関しては O_NONBLOCK を設定しなくても MSG_DONTWAIT で済むのか...
新しいマシンに Debian をインストール...
う、Woody のインストールフロッピーは Intel Pro/1000 は認識しない? まぁ、じゅーぶんあり得る話か。
さて、解決する方法を何種類考えられるか?
しばらく、vim で matchit を使っていたのだが、ついにその遅さにめげてやめる。
コンピュータの背面を見るとコネクタにいろいろ記号が書いてある。 プリンタの記号とか、USB の記号とか。
ここで、分からない記号があるのだが、これを調べるにはどうしたらいいか? これを検索できるか?
こういう記号は入力できないので検索できない?
まてよ? Unicode にはあったりして?
とりあえず、UnicodeData-4.0.0.txt を USB で grep してみても 見つからなかったのできっとないのであろう。
sizeof(long double) はいくつか?
月曜は東京
新橋
微妙に調子が悪い気がしたので、さっさと帰って寝る。
... うぅむ。寝てて地震に気がつかなかった。
テンプレートの部分評価ができると面白いのかも知れない。
persistent storage の扱いにくさについて考えてみよう。
第一の問題は persistent っつーのはプロセスよりも長命だっていうことである。 だから、いったん外に吐き出して、また読み込まないといけない。 まぁ、これは marshaling が言語で支援されていればたいしたことはない。
第二の問題は persistent っつーのはプログラムよりも長命だっていうことである。 つまり、吐き出したときのプログラムと、 読み込んだときのプログラムが同じとは限らない。 プログラムは開発の進展にともなって変化する。
これをどうやってうまくあつかうか?
アプリケーションによらない解としては、 バージョンをつけることが考えられる。
バージョンが違ったときに読み込みを拒否するか、 (スキーマエボリューションてな感じで)変換するかという選択肢はあるが、 拒否するのは悲しいし、変換するのは面倒である。
アプリケーションに依存してもいいとすれば、 もっと楽な方法はあるか?
いろいろと考えると、インクリメンタルに計算するのが問題なのかも知れない。
一般に、プログラムが複数回起動して persistent なデータを読み書きすると、 persistent なデータの中には起動した各時点の記録を混ぜるようにして 計算された情報が蓄積されることになる。 そういう情報は、各時点における(異なるかもしれない)プログラムの影響を 受けたものになる。 しかし、もし、インクリメンタルな計算を行わないとすれば、 persistent なデータは各時点における事実の記録だけになり、 そういう混ざりかたはしなくなる。
プログラムというのは要するに計算をするものなので、 インクリメンタルな計算を行わないことは、 persistent なデータに対するプログラムの影響を最小限におさえることになる。 つまり、プログラムの変化に対する耐性が高くなる。
また、データを時系列順に並べておけば、 古いデータから捨てていくことも容易になる。 これは、古い(今とは異なるプログラムによって生成されたかも知れない)データの 影響を確実に捨てられることを意味する。
逆にいえば、このような構造は、 影響がずっと重なっていくことを目的とする場合には使いにくいことになる。 (時間が経つにつれてデータがどんどん大きくなってしまう)
つまり、プログラムが何回も起動され、 最新のいくつかのデータのみに依存して計算が可能で、 計算自体はたいして重くない、 そういうアプリケーションならば、 インクリメンタルな計算を除去することによって、 プログラムの変化に対する耐性を高めることが出来るのかも知れない。
そうそう、データ自身が大きくないことも必要か。 いいかたを変えれば、 入力されたデータを十分に小さくまとめる部分の計算が十分に安定していることが必要、 ともいえる。
"1-button mouse": 964 "2-button mouse": 14500 "3-button mouse": 28400 "4-button mouse": 1110 "5-button mouse": 1420 "6-button mouse": 51 "7-button mouse": 36 "8-button mouse": 36 "9-button mouse": 6 "10-button mouse": 10
雨
そういうふうに書いてみる。 期待した程には利点ばかりではない。
記録してあるのが時系列順の生の情報ということは、 プログラムで実際に必要な形になっていないということである。 そのため、必要なときにいちいち変換しないといけない。 今回は 3回(行動の決定、出力の生成、記録の削除)必要になった。 まずは気にせず 3回書いてしまったが、そういう変換を共通化する必要があろう。
インクリメンタルに計算していたときは、 そういう変換は明示的に共通化しなくても一回書くだけでよかったわけで、 今のスタイルは以前に比べると手間がかかる。
[latest]