No Such Blog or Diary

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

ま，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 の使い方が分かった（元論文はだいぶ前に読んであったのだけど）．

fib((-1+)->n@((-1+)->m))|m<0=1|((,,fib n)m->(fib->x,_,y))<-()=x+y

ViewPatterns, PatternGuards, TupleSections の拡張機能を使ってみたかっただけともいう．

View patterns はパターン部分に計算を書けるしそれを連ねることもできるので（関数結合と逆向きだけど），なんとなくモナド（のbind演算子）でプログラムを書いている気分を味わえる気がする．Pattern guards はまあ面白い使い方がまだ思いつかない．Tuple sections は場合により便利だけど変なプログラムを書くのには使いにくいかも？　λ式にも view patterns 書けるので，かっこを使いまくりな id 関数とか：

i=(\((,)() -> ((),x)) -> x)

ついでなので階乗を求める関数も．

fact n|1>n=1|((-1+)->fact->x)<-n=n*x

そのうちの一通：タイトル「test」で

test

まさに迷惑以外の何物でもない．

ちなみに，その一通前のメールはタイトル「twitterについて」で

　より正確には 言わなくていい、言う側だけでなく聞かされる方の事も考えろ という基準に満たないという感想です。

身に覚えがないけどとりあえずブーメランだよね．意味のないメールを送りつけられる方のことは考えられないらしい．能動的に読む twitter はさておき，受動的に読まざるを得ないメールで上記の読み手に何の利益もないメールを送るとか常識的におかしいだろうに．

ま，迷惑メールの送り手が他人の迷惑考えられるわけないのだけど．

去年行けなかった中川村の赤そばの花を見にいってきた．少々雲が多すぎたのが残念だったけど．

赤そばの花のアップ．大量にいたミツバチは花が小さいせいか動きが激しくSTF＋接写リングではまともに撮れなかった．残念．

おまけでふつうのそば．見事に白い．赤そばも珍しくてよいけれど真っ白も素朴でいい．

帰りは去年通行止めで通れなかった国道152の続き（大鹿村から分杭峠を経て北へ国道20号にぶつかるまで）を走ってきた．都合の良いことに松川から大鹿村へは県道59+22で真東に行くだけだったので．まあ，地蔵峠や青崩峠のような酷さは無く殆どの区間が快走路で少々微妙だったけど．