トップ «前の日記(2017-05-13) 最新 次の日記(2017-06-03)» 編集

日々の破片

Subscribe with livedoor Reader
著作一覧

2017-05-21

_ 汐留に行く

妻と飯食いに出かけたら、目当ての店が改装中でしまっていた。

では神保町でロシア料理でもくおうかと思ったら、駐車スペースが空いてない。

では汐留はどうか? と妻が提案する。中国飯店のカジュアル部門が入っていて、それなりに美味しい(中国飯店のクラシック部門にやたらと好きな店があるのが前提としてある)。

では行くか、と行ったらさっぱりどこに停めれば良いのかわからない。

結局、首都高の駐車場に入れたら、驚いた。4箇所ある出口がすべて右側(車道は下り側)にしかない。だが、汐留のタワー群は左側なのだ。

しょうがねぇなあと面倒だがそのうち一つから出たら、番地がない中華料理店があった、と妻がはしゃぐ。しかし、おれはそれは見損なった。

地上に出ると、異様にさびれていてびびる。はて、これが汐留なのか?

と、中銀カプセルタワービルが目の前にある。網がかかっている。

おお、こんな間近で観られるとは。

入り口にカフセルタワーヒルと、濁点がすべて落ちた板が埋め込まれている。

張り紙がペタペタと、ここはマンシオンです、ホテルではありません、と主張している。まあ、見学してみたくなるからなぁと通り過ぎる。

ふと振り返ると、上の看板にローマ字でNakaginと書いてあることに気づく。今までずっとチュウギン(なんか中部銀行の不動産部門とか)だと思っていた。

それにしても、さびれきったところだなぁと、どうすれば首都高の向こうのタワー群に行けるのか困る。

結局、歩道橋しかないじゃんということになって進むと、途中、首都高をくぐるために数段下がり、首都高をくぐって数段上がるというアドホックな作りになっている。

いかにも昭和っぽい。

交通安全のために信号を全部撤去して歩道橋を作ろう。

で、作り始めて、おや、歩道橋の法定高度では首都高にぶつかるぞ、では少し下げますか、とかやったとしか思えない。何も考えていないのだな?

で、首都高をくぐって上に戻ると別の世界になっていた。今度は、自転車を押して通れるような広さの歩道橋に変わっているではないか。

すげぇ。線路をまたいだ南北格差とかはたまに見るが、高速道路をまたいだ格差というのは初めてだ。というか、駐車場の出口がすべて片側に寄っているのが過去の栄華ということだな。

で、駅舎の遺構の上に建てた駅舎(地下に降りたら遺構を観られるようにガラスで地下を見せていて、先日テレビで見たアッピア街道終点のベルディ劇場みたいだなと思った)を見学したりしてから飯を食う。

というか、出土品とかいってラムネの瓶とか展示してある(妙な形状で小児用の尿瓶かと思った)のがおもしろい。ポイ捨てしたゴミも100年以上たって掘り出せば興味深い出土品になるのだな。

というわけで、なかなかおもしろかった。というか、首都高駐車場が安くて驚いた。

_ 純粋関数型データ構造

アスキーの鈴木さんから頂いた。

おもしろい。しかも難しい。

難しいのは2点ある。

まず本質的に難しいことを書いてあるから難しい(でも、これはOK)。

次にリストがSMLという全然馴染みがない言語だという点。もっとも付録にHaskellで書いたリストが付いているし、馴染みはなくても言語構造が明確なので読むだけなら読めなくはない。(が、練習問題を書いてみようと思っても書けない)。

前提知識としてO記法(というか、O(n)が線形に時間がかかり、O(1)がデータ構造としては望ましく、O(log n)がわりと良い線程度の知識で十分に思えるが、なぜそれがそうなのかはわかることは前提なのだろう)と基本的なデータ構造を知っていることとしてあるが、本当にそれだけで済むかは怪しい気がする。償却のところは何度か読んでいるうちにおもしろさがわかってきたのだが(が、ここで何がおもしろいのかうまく説明できない程度に理解していないことがわかった)、最初、この人は何を書いているのだろう? と感じる程度にさっぱりわからなかった。

というわけで、まじめにすべて読むのはあきらめておもしろそう/理解可能そうなトピックの拾い読みをするわけなのだが、するとおもしろい。個々の章はある程度独立しているので、拾い読みが可能なようになっている。

本気で読むのであれば、教科書として使ってくれる先生の授業を取るか、それなりのメンバーを集めてガチな読書会とかするのが良いのではなかろうか。その一方で何百人いるかはわからないが、普通に読める人には問題を解くことを含めて相当おもしろいのではないかなぁ(おれはそこまではいかない)。

その一方で、内容は原理から入って十分に抽象化して説明されているから、特定のデータ構造を使うときには普通に役に立つように思える。考え方を流用するだけなら命令形で書くこともできる(が、そこにどれだけの意味があるかは別問題で、実用的なデータ構造はライブラリ化されていることが多い)。

関数型には代入という概念がない(といって良いのだと思う)ので書き換えができない。できるのは置き換えと再作成だ。

でもそれによって、ポインタ更新地獄に落ちなくても済むとして、しょっぱなで赤黒木の実装が示される。これはかっこよい。

抽象的な話かと思うと、これこれの場合はメモ化がはたらくので効率が良いといような実用時の話もあったりして、それはそれでおもしろい。なんでも再帰だが、ある時点で以前に行った呼び出しと同じ引数を見つけるとメモから結果を取り出せるのですべてをくそまじめに計算するわけではないというのはおもしろい。副作用が前提の言語ではそうはいかない(すべてをstaticとして記述すればできなくはないはずだ)。

いずれにしても、店頭から消えたら二度と買える機会はないだろうから、読みたい、興味ある、将来的に必要そうな予感などがあったら、さっさと買うべきだとは思う。

純粋関数型データ構造(Chris Okasaki/稲葉 一浩/遠藤 侑介)


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|

ジェズイットを見習え