注: 実際に噛まれたわけではない
プログラムからその意味への関数を考えて、その関数を微分するとどうなるだろう?
それは拡張性を意味したりしないだろうか。
つまり、プログラムの小さな変更で意味が大きく変更できると微分は大きくなるはずだ、とか。
もちろん、行いたい変更にたいするところが重要なのであるが。
Binary 2.0カンファレンス 2006 で話してきた。
ネタと発表時間があっていなかった。
最初は Ruby 側の workaround まで入れようと思ったのだが、ざっと書いた段階で 36枚になってしまい、gcc の変化につながる流れだけに絞った。それでも時間はオーバー気味だった感じである。
workaround のほうが笑える話になるとは思うのだが、問題自体を説明しないのもなんだし。
「楽々 ERD レッスン」を読む。
「諸般の事情でスライド6枚」 という件について考えてみる。
この「諸般の事情」なる制約は、立方体の面の数からきている。
したがって、まず考えられるのが、将来、ディスプレイおよびプロジェクタが正三角形に発展するという可能性である。そうなれば正二十面体により、スライド20枚が可能になる。
また、四角形から三角形になるのは数が減っていて発展とはいえないとすれば、五角形ということも考えられる。そうだとすれば、正12面体により、スライド12枚が可能であろう。
しかし、四角形以外になるのは現実的でないという意見もあるかもしれない。
そこで、正多面体以外の多面体を検討してみた。具体的には Wikipedia の図形の一覧 から、3次元の図形を眺めてみた、ということである。
まず使えそうなのが、斜方立方八面体である。正方形が18枚で、スライド18枚である。しかし、正三角形が8枚まざっているので、純粋さに欠けるという意見があるかもしれない。
その場合、菱形十二面体はどうであろうか。これであれば、菱形が12枚で、純粋である。しかし、菱形はプロジェクタの形にはあわないという意見があるかもしれない。
では、凧形二十四面体はどうであろうか。凧型もプロジェクタの形にあわないではないかという人もいるかもしれない。しかし、ここで、スライドが3次元空間に配置されていることを思い出してほしい。3次元空間を 2次元に投影した場合、遠近法により像が歪む。近い点は画面の中心から離れ、遠い点は中心に寄る。したがって、適切な距離と方向に配置すれば、凧型を正方形に投影することは可能であろう。(たぶん)
というわけで、凧形二十四面体による、スライド24枚はどうであろうか。
鴨志田さんの発表 に名前が出ていた Succinct Data Structure を調べる。
集合について理解するのは難しくない。
wavelet tree はしばらく考える必要があったが、理解できた気がする。
ぬぅ、月例会を完全に忘れていた。
Succinct Data Structure に限らないが、前処理を必要とする高速化アルゴリズムというのは扱いが難しい
前処理のコストがかかるので、どんな場合でも自動的に適用する、というわけにはいかない
もちろん、事前にその高速化が必要であることがわかっていて、最初っからそれを使うと決めてプログラムを書く場合には大きな問題はない
しかし、後から遅いことがわかったとか、あるいは機能拡張にともなって高速化が必要になったとか、既存のプログラムを高速化しようとしたときにはそう簡単にはいかない
既存のプログラムを高速化する場合、前処理の結果として生成される補助データをどこに格納するかという点が問題になる。すぐに考えられる可能性としては2つあり、それぞれに利点・欠点がある
また、補助データの寿命の問題については共通する問題がある
「プログラムを書き換えなければならない」というのはとてもいやな欠点である。高速化のためだけに、高速化には直接関係のない箇所まで変更するのは避けたい。変更してプログラムが壊れてしまってそれを直すのは徒労である
とはいえ、グローバルなハッシュもいろいろと欠点がある
では、もっとマシなやりかたを可能にする言語機構としてはどんなものが考えられるか?
そういえば、両対数グラフの使いかたを習うのって、どのくらい一般的なのかな。
スミスチャートよりは一般的だと思うのだが。
Python が stdio を捨てるという話を調べてみる。
iostack というやつで、説明を読む限りはいろいろ統合するのが狙いらしい。
さて、non-blocking I/O がどう扱われるかというと、Open issues の項に入っていてあまりまじめな検討はされていないくさい。
NetworkStream の may_read, may_write, readavail が案のようだが、これらについての議論はとくにされていないようだ。
webgen を試す。以下の点が気になった。
webgen がサポートしている HTML 以外のフォーマットは Textile, RDoc, Markdown であるが、これがどれもうまくない。
Textile:
"<" をそのまま出してしまう
% /usr/bin/ruby -rredcloth -e 'puts RedCloth.new("a < b").to_html'
<p>a < b</p>RDoc (の SimpleMarkup):
Markdown:
というわけで、最初からサポートしているのはすべて却下である。ただ、新しいフォーマットをサポートするのは簡単だと書いてあるので RD を試してみると、以下のように plugin/rd.rb と config.yaml を作ると動いた。
% cat plugin/rd.rb
module ContentHandlers
class RDContentHandler < DefaultContentHandler
summary "Handles content in RD format"
register_format( 'rd' )
def format_content( txt )
str = nil
IO.popen("rd2", 'r+') {|rd2|
th = Thread.new { rd2.read }
rd2 << txt
rd2.close_write
str = th.value
}
raise "rd2 fails: #{$?}" if $? != 0
raise if %r{<body>(.*)</body>}m !~ str
$1.strip + "\n"
rescue
self.logger.error { "Error converting RD text to HTML : #{$!}" }
''
end
end
end
% cat config.yaml
# Configuration file for webgen
# Used to set the parameters of the plugins
PageFileHandler:
defaultPageMetaData:
useERB: true
blocks:
- name: content
format: rd
なお、useERB: true というのはデフォルトがそうなので変えていないのだが、良いことなのかというと疑われるものがある。
[latest]