No Such Blog or Diary

そういえば鬼物語が発売されていたので買ってきた．まだ読み終えていないけど．

閑話休題．

一人がしゃべり続ける節では各々のセリフに開き鉤括弧は置かれているもののセリフ終わりの閉じ鉤括弧は節末のひとつ以外は省略されいてる．これが西尾維新特有のものなのかどうかはしらんけど，まあ，しゃべりが続いているのだから最後まで閉じなくてもいいよねとは思う．ただ，大量に開いたカッコに対して閉じ括弧がひとつしか無いというのは……　

Lisp のスーパー閉じ括弧か！

ということで，西尾維新は Lisper だったのかぁとかいう下らないことを思った．

そういや高専の現国の先生が Lisp を絶賛してたっけなぁ……

まさかあの動きがモータ１個で作られていたとは．

ARMTRONの内部構造をさらしてからアレやってみた という動画を見てその内部構造を初めて知った．おもいっきりガキの頃に遊んだ記憶があるのだけど，あれだけ自由に動くくせに動力源はモータ１個で回転方向や速度の調整まで全部機械的にやっていたとか驚きでしかない．一般人的には，モータ複数積んで電気的に回転方向や速度をコントロール，という構造程度しか思いつかないのだけど．

当時はモータを複数積むよりギアでつなげたほうが安かったのだろうか．または内部の構造は当時の産業ロボットと同じでそれを縮小しておもちゃを作ったのか．よく分からんけどこれを玩具として作った技術者の根性がすごい．

遊星ギアって便利だなぁ

よく通る交差点の信号の挙動が最近変更された．具体的には，以前は歩行者信号と車両信号が同時に青になっていたが，変更後は歩行者信号が先に青になり暫く後に車両用信号が青になる．

で，歩行者信号が青になった途端に信号無視して発進する車多発．見切り発車いけません．

歩行者が安全に歩道を渡れる時間を確保しようという意図でのタイミング変更だろうけど，信号無視して突っ込んでくる車が多発しているのでかえって危なくなっている気がしなくもない．暫くすれば状況も安定するかもしれないが……　その間くらいは「信号のタイミングが変わったので注意」とかいう看板を置いて注意喚起してもいいと思う（そういった看板の立っている交差点が近くにあるし）．事故が起きてからでないとそういった看板は立てられないのかもしれないけれど．

警察に苦情を伝えておけば改善するのだろうか？

自分が著者に入っている論文が参考文献に入っているのに自分の名前が著者名から抜けているとき～

ま，2番目以降なのでどうでもよいのだけど．

とりあえず今後論文書くときには参考文献により気を付けることにしよう．

閑話休題．

正規表現マッチングを並列化するのにSSFAというオートマトンを作るとマッチングの計算量には状態数が現れなくなって嬉しいよねという発表を聞いた．「並列化＝状態間の写像の合成を分割して計算」でよいのだけど，どうせ現れる写像は限られているので，毎回写像の合成を計算する代わりに一文字読んだ時の写像との合成結果を文字をキーにしてテーブルで引けるようにしましょうよと．まあ，NFAをDFAに変換するのと同じ．

で，NFAをDFAに変換するのと同じなので，そこでの問題が再発するんじゃないのかなぁとか疑問に思った．通常，テーブル（DFA）を作っておけばテーブル引くのは写像の合成を毎回計算する（NFAの合成では状態数の3乗の計算量）よか速い．けど，最悪テーブルはNFAの状態数の指数の大きさになるので，その時にはキャッシュミスの効果も出てきて写像の合成計算したほうが速かったりしないのだろうか，という疑問．アルファベットを {a, b} にして，.*a.*a.{20} とか（aが2回出てきて，かつ，後ろから21文字目はaであるべし）．NFAの状態数は22だけど，SSFAの状態数は大きいんじゃないかなと．まあ，実験してみないと分からん．

閑話休題．

何となく，足の薬指が中指に微妙に押しつぶされるような歩き方になっているような気がする．なので長距離（10キロ）歩くとそこにマメができると．よく考えたら西沢渓谷の時も富士山の時も（別の靴だけど）ここにマメができていたっけね．去年靴を変えるまではもっと長距離を歩いてもこんなことなかったので，ここんとこ履いている靴達が微妙に合っていないのかも知れない．とりあえず次に靴を買うとき考えよう．

青い海，青い空，青い俺の脚．

新しいジーンズ穿いて歩いたら脚に色移りしたという．それなりに汗をかくくらいにまだまだ沖縄は暑い．風呂で脚洗ったら青い泡が流れて行くとか奇妙すぎた……

閑話休題．

首イテェ．肩というか背中というか首というか．

とりあえず普通のHaskellプログラマが書くであろうフィボナッチ数列の計算：

fib = 1:1:[a + b | (a, b) <- zip fib (tail fib)]

Parallel List Comprehensions を使ってみた書き方：

fib = 1:1:[a + b | a <- fib | b <- tail fib]

Generalised (SQL-Like) List Comprehensionsを（無駄に）使った書き方：

fib = 1:1:[sum a | a <- fib, then group using (\b -> zipWith (\c d->[c,d]) b (tail b))]

こいつは -XTransformListComp で機能を有効する必要あり？　とりあえず束縛時と使用時で変数 a の型が変わるのがまぎらわしい．ついでに using の後の関数の型が forall a. [a] -> [[a]] でないといけないのを時々忘れて怒られる．ついでに by をつけたときには forall a. (a -> t) -> [a] -> [[a]] でないと怒られる．第一引数の (a -> t) という型の部分には by の後に指定する式から作られる関数が渡されるので，そこでリストの要素を見て適当な型 t の要素に射影して，その結果を使ってリストの要素をリアレンジしても良いよと．でも，その関数以外ではリストの要素に触れてはいけないよと（forall がついてるから）．むずい．

さらに -XViewPatterns を有効にして無駄に分かりにくい書き方をしてみる．機能の無駄遣い．

fib = 1:1:[sum a | a <- fib, then group using (\c@(tail->b)-> zipWith (\((:[])->c) d -> d:c) c b)]

とりあえず，変なプログラムを書いたおかげで Generalised (SQL-Like) List Comprehensions の使い方が分かった（元論文はだいぶ前に読んであったのだけど）．