No Such Blog or Diary

問題：次のメールを読み，送信主の主張をわかりやすくまとめよ．

タイトル「電子メールに関するポリシーについてのコメント・苦言など」

一度、話しかけられた事のある相手に対して、面識に基づくコミュニケーションを要求する事は、面識があるかどうかについて深く求める事は関係を求められる事になり、関係を求められる事は責任を求められる事になるから、翻って、面識を求める事は責任を求める事につながる以上は、強すぎる要求である事は確かですが、電子メールの扱いに関してうまく関心を共有できなかったのは、一方で、Ｋさんが、電子メールアドレスについて、emokenさんが、比較的寛容な、ポリシーを示していて、その内容と、一貫しなかったから、それに対する、首尾一貫性を説明する補足的電子メールの、追加を、待っていたからです。〇〇さんについて、アドレスを尋ねたのは、実際知ろうとしていたのもそうですが、一方で、そうでない場合には、そういったポリシーを、説明してもらえるのかと、思っていました。コメント回数で言えば、わたしが〇〇さんに対してコメントした回数は、emokenさんが訊ねた回数を超えていないと思います。気にかかるのでなければ、公共の場での発言はお控えになった方がよいと思います。もしそういった言動が見られなければ、わたしも、そういった電子メールを送らずに済んだ訳ですから、話をややこしくする必要はないと思います。

よく分からないのでエキサイト翻訳で英語にしてみた．ますます訳分からんのだけどとりあえず全部を訳してしまう翻訳機すげぇ．［ ］とか / とかは何処から湧いてきたんだ？

Requiring the communication based on acquaintance to the partner who had addressed once, As for it being too strong a demand, it is clear that asking deeply about whether it is acquainted can ask for a relation, and it can ask for a relation, if it leads to asking for acquaintance searching for responsibility on the other hand at all, since responsibility can be searched for, but. One side was not able to share concern well about the treatment of an E-mail, and Mr. K, It is because it was waiting for the addition of the additional E-mail [ as opposed to / since the policy in which Mr. emoken is comparatively tolerant about an e-mail address is shown and the contents did not cohere / it ] explaining coherence. I thought whether, about Mr. 00, one side asked the address, and although actually trying to get to know is also so, when that is not right, it would have such policies explained. I think that the number of times that I commented to Mr. 00 will not be over the number of times that Mr. emoken asked if it says by the number of times of a comment. If not worrisome, I will consider the utterance in a public place as it is better to cut down. If such speech and conduct are not seen, I also think that I do not have to talk puzzling since it is a reason for not having sent such E-mails.

出かけたけど寒すぎてモチベーションが下がったので途中で引き返してきた．満月じゃないし．

閑話休題．

去年普通二輪の免許を取った教習所から大型教習の割引のご案内が来た．夏に比べれば空いているのかね．うーん，９万弱か……　わざとコケてみるとかやってみたい気もするので悩ましい．

succinct data structure というものを初めて知った．使用する空間量が情報理論的下限（つまりはエントロピー？）に近く且つ幾つかのクエリ処理が高速に行えるデータ構造であると．分類としては，適当なデータを表現するビット量の情報理論的下限をZとしてやると，Z + O(1) ビットで表現できる構造は implicit data structure で，Z + o(Z) ビットで表現できる（つまり係数も一致して漸近的に下限に至る）なら succinct で，O(Z) ビットで表現できる（つまり下限の定数倍程度）なら compact というと．

例としては，{0, 1, ..., n-1} の部分集合の表現（つまりは長さ n のビットベクタ）に対して rank と select というクエリをO(1)で行うギミックを付けた構造があると．rank(x) は x ビット目までの 1（ないし 0）の数を返すクエリで，select (y) は rank(x) = y なる最小の x を返すクエリ．rank を O(1) で計算するために o(n) なサイズのテーブル３つをうまく用意してやると．大きな１つのテーブルですべての答えを用意しようとすると n lg n になってしまう（引数の数がn通りでそれぞれの答えが lg n だから）ので，とりあえず (lg n)^2 毎に区切ったブロックの先頭だけの rank テーブルを作って（これで n / ((lg n)^2) * lg n = n / lg n ビットのテーブル），次に残りのブロック内の先頭からの rank の差分をどうにかしましょうとか考えるのね．残りの部分をどうするかだけど，とりあえず愚直に全部のインデックスに対してブロック先頭からの差分を保持すると O(n) 以上かかるのでダメで，一方，存在しうるブロックの全パタンを網羅しておこうとしてもブロックサイズが大きすぎてこちらも O(n) 以上かかる．しょうが無いのでもう一段ブロック化を導入してあげて，この小ブロックのサイズを lg n / 2 にしてあげると，この小ブロックに関して全パタン網羅しても o(n) で済むし小ブロックの先頭の rank （の大ブロックの先頭からの rank の差分）を全部保持しても o(n) で済みますよと．これにて一件落着．クエリ時には３つのテーブルを引いて足しあわせりゃいい．select はめんどいらしい．

まあ，再帰の段数を固定して適度なサイズ以下の問題は定数で答えが返るという状態を作っておけということなのか？　計算の一部を適当なサイズのデータに変えて取っておこうよというかよく使う部分計算はテーブルに取っておこうよというか．

それはさておき，rank/select で具体的に何が出来るのかがよく分からん．あとは一般にどんなクエリなら効率をデータ構造に押し付けられるんだ？　どの程度自動化できるんだ？　よく分からん（論文読め）．

変な姿勢でディスプレイ眺めてたせいなのか……　とりあえず行動不能．

働けるとこに感謝して一日中働く日だと教えられた気がする．

例え元のプログラムが正しかろうとコンパイラが間違っていれば出てくるものもやっぱ間違っているわけで……　例えば，車とかに入りまくっているチップの設計に使われるようなHDLのコンパイラはどの程度正しいと証明されているのだろうか？　コンパイラのバグ踏んだー！とか言って事故るのはゴメンなのだけど．