Hatena::ブログ(Diary)

当面C#と.NETな記録 このページをアンテナに追加 RSSフィード

2008/4/18 (金)

[][] モナドとかLINQとか  モナドとかLINQとかを含むブックマーク  モナドとかLINQとかのブックマークコメント

一つ前の記事のコメントがすばらしすぎるのですが、長すぎて扱いづらいので無理やり記事を書いてみたり(^^;

NyaRuRu さんが挙げた

>・IEnumerable<T> は [a] というより IO [a] ?

>・実は LINQ to Object は IO と List の合成モナド?

の部分について、ちょっと考えてみた。

LINQ to Object の IEnumerable<T> は単に IEnumerable<T> と言っただけでは遅延評価の側面が欠けてしまうので、遅延評価の IEnumerable<T> と言わないと正しくないですね。

× LINQ to Object: M a = IEnumerable<a>

○ LINQ to Object: M a = 遅延評価 IEnumerable<a>


って話と何の脈絡もなく唐突にはすける

inc :: (->) Int Int
inc n = n + 1

動いた。気持ち悪いw

もう今日はこのあたりのこと以外、すべて上の空…マズイ…

トラックバック - http://d.hatena.ne.jp/siokoshou/20080418

2008/4/15 (火)

[][] LINQ is Monads. リンクはモナド  LINQ is Monads. リンクはモナドを含むブックマーク  LINQ is Monads. リンクはモナドのブックマークコメント

nsharp さんに教えてもらったビデオを見てみました。ごちゃごちゃしたメモだけどもう眠いのでそのまま書き残しておきます。

http://channel9.msdn.com/Showpost.aspx?postid=358968

「LINQなんてのは、実装は適用連鎖ですが、根底にある発想は関数合成の方だったりします。」って言葉がとても気になったので。


ヒゲと帽子が似合うって話はおいといてw

関数の合成、圏論のモノイド、関数合成がモノイドを成すこと、そしてモナドを説明してくれるビデオ。でも、英語聞き取るのが難しいorz

型 A を取って同じ型 A を返す(集合 A から A への)関数全体は、関数合成、恒等関数 id (Iコンビネータですね)に関してモノイドを成す、っていう定番のお話。そして、関数合成とモナドの「>>=(bind、束縛)」は同じように「くっつけるもの」だって言ってるようです。モノイドとモナドの関係についてはよくわかりませんでした(早口でなんか言ってる)。モナドもモノイドって言ってるのかな?

LINQ is Monads. って言葉がとても印象的。「オブジェクト、SQLXML」はデータモデルが全然違うのに LINQ が同じように書けるのは、これらをモナドとして扱っているからだそうな。そういうことだったのか!

もうひとつ、bind is SelectMany. がとても気になったので、ビデオにはないけどちょっとやってみる。

SelectMany はこう。

public static IEnumerable<TResult> SelectMany<TSource, TResult>(
    this IEnumerable<TSource> source,
    Func<TSource, IEnumerable<TResult>> selector);

bind はこう。普通は b c を a b、M も小文字で書くけどビデオにあわせました。

(>>=) :: M b -> (b -> M c) -> M c

ここで、TSource を b, TResult を c, IEnumerable を M と置き換えて、関数型っぽく書いてみます。

SelectMany : M b -> (b -> M c) -> M c

おおおお!!ピッタリ一致!SelectMany って >>= だったのか!

ふつケルに書いてあった、モナドが床下配線って意味が LINQ を通してちょっとわかってきた感じ。



以下、ごちゃごちゃしたメモ。

ほかに印象に残った言葉 : 関数もデータ。(モノイドで)シンプルな関数を組み合わせて、複雑なものを構成できる(シンプルなものを組み合わせて複雑なものを作るってのは、確かに LINQ や関数型言語の重要な性質ですね)。時計を例にしたモノイドの説明。unit は 12。

モナド:

f : a -> M a (注: f は関数ね)

タイプコンストラクタがつく。型 a を取って M a 型にして返す。

\a -> (f a) >>= \a -> (g a)
\a ->  Ma        a ->  Ma

M はどこかで何かする何か。IO だったりデータベースだったり…とにかく何か。それは問わない。

LINQ is monads. エリックメイアーさんがとても注意深くデザインしてある。モナド偽装。

>>= はモナドの合成演算子。

疑問:モナド則はモノイドのメタルールを満たすようにデザインしてあるってこと?

return : a -> M a

return が unit ?

bind は結合則を満たす。

LINQ: M a = IEnumerable<a>

nsharpnsharp 2008/04/15 07:41 > モナドもモノイドって言ってるのかな?

Monadの場合は、モノイド則を満たすように「プログラマが実装してください」ということです。

関数(a -> b)の場合は、合成(.)とidに対して「必ず」モノイド則が成り立ちます。

 (1) h . (g . f) = (h . g) . f
 (2) f . id = f = id . f

というのも、合成とidの中身がはっきりしてるからです。

 g . f = ¥x -> g (f x)
 id = ¥x -> x

一方、Monad(a -> m b)の方は、m自体が抽象的なので、合成とidの内容は規約(シグネチャ)があるだけで具体的な中身は決まってません。
(MaybeとかListとかStateとか、mが具体的になれば実装内容も具体的に言えますが・・・。)

 (.) :: (b -> m c) -> (a -> m b) -> a -> m c
 id :: a -> m a

なので、上記(1), (2)をプログラマ自身で保証してください、それができたらMonadと名乗っていいですよ、という感じです。

結局のところ、HaskellのMonadがわかりにくい最大の原因は、bind(>>=)を通して見てしまうからだと思います。
合成を通して眺めれば、Monad則というのも(1), (2)のシンプルで形のきれいなルール相当だということがわかると思います。

nsharpnsharp 2008/04/15 07:43 > LINQなんてのは、実装は適用連鎖ですが、根底にある発想は関数合成の方だったりします。

以下を比べてみてください。

 (1a) (.) :: (b -> c) -> (a -> b) -> a -> c
 (2a) id :: a -> a
 (3a) flip ($) :: a -> (a -> b) -> b

 (1b) (<=<) :: (Monad m) => (b -> m c) -> (a -> m b) -> a -> m c
 (2b) return :: (Monad m) => a -> m a
 (3b) (>>=) :: (Monad m) => m a -> (a -> m b) -> m b

bind(>>=)は、関数適用($)の引数をひっくり返したものに似ていることがわかると思います。
flipしているのは、コードの流れを左から右に流したいからでしょうか。(手続きをエミュレートするため。)

Monadを使ったプログラミングは、関数適用相当の(>>=)を使いまくりますが、Monadを理解するには(上にも書いたとおり)合成の方がはるかにすっきりするのです。
言いたかったのはそんな感じです。

NyaRuRuNyaRuRu 2008/04/15 08:41 > LINQなんてのは、実装は適用連鎖ですが、根底にある発想は関数合成の方だったりします。

質問なんですが,Enumerable.Take みたいなのは monad の枠組みではどう扱うのでしょうか?
「LINQ = monad」というロジック紹介の仕方だと,Take(5) のような処理の説明に困るので,最近は「LINQ は LINQ でいいのかなぁ」と思っていたりするのですが.

siokoshousiokoshou 2008/04/15 08:45 おぉ、これはすごい!すばらしい解説ありがとうございます。
return が単位元っていうのはあってたんですね。モナド則がモノイドを成すように定めてあるってのもあってるんですね。
1a〜3a と 1b〜3b、似てますねぇ。1b の <=< ってなんだろ。後で調べてみます。
このビデオと nsharp さんのコメントでモナドがちょっとわかりかけてきた感じです。ビデオ見るまでは bind がなんなのかもわかってなかったし(^^;

NyaRuRuNyaRuRu 2008/04/15 08:52 例によって Haskell はあんまり詳しくないんですが arrow の stream function に近かったりするのかなぁ.

nsharpnsharp 2008/04/15 10:15 > 質問なんですが,Enumerable.Take みたいなのは monad の枠組みではどう扱うのでしょうか?

お気づきのこととは思いますがw、yield return, SelectManyで説明することはできません。

IEnumerableがMonad(のインスタンス)である = IEnumerableに関するすべての操作がunit, bindで説明できる、というわけではありません。
HaskellのMaybeがMonadのインスタンスだからといって、isJustやfromJustがreturn, (>>=)で表現できるわけではないのと同じように・・・。


> 最近は「LINQ は LINQ でいいのかなぁ」と思っていたりするのですが.

MonadはLINQの「発想の由来」とか「特徴の1つ」であって、LINQのすべてではありません。

ので、目的が「LINQを説明/理解すること」だったら、それでいいと思います。


・・・というか、gushwellさんのところをもう一度よく見てみたら、

> LINQなんてのは、実装は適用連鎖ですが、根底にある発想は関数合成の方だったりします。

この発言はMonadとぜんぜん関係ない文脈(通常の関数の適用・合成の文脈)で言ってた。w

こじつければ、Categoryとして括れるかもしれませんが・・・。
ttp://www.haskell.org/ghc/dist/current/docs/libraries/base/Control-Category.html

siokoshousiokoshou 2008/04/15 10:46 Haskell でもリスト(モナド)を扱う関数がいろいろありますし、Take は LINQ to object と LINQ to SQL でそれぞれ定義された関数、ってとこなんでしょうか。

> yield return, SelectManyで説明することはできません。
ムム。ここに yield return が出てきて、モナドの return と yield return が対応するってことに今気づいた!なるほど〜。

siokoshousiokoshou 2008/04/15 12:33 今ちらっと「モナドのすべて」を読み返してみたら、ガッテンしまくった。
http://www.sampou.org/haskell/a-a-monads/html/meet.html

NyaRuRuNyaRuRu 2008/04/15 23:19 >HaskellのMaybeがMonadのインスタンスだからといって、isJustやfromJustがreturn, (>>=)で表現できるわけではないのと同じように・・・。

なるほど.そういわれれば確かに納得です.

一回どこかで LINQ の特殊性もきちんとまとめられるか挑戦してみたいところ.
以前副作用の時に話題になりましたが,個人的には次の部分も引っかかっていたり.
・LINQ to Object は IEnumerator<T> ではなく IEnumerable<T> を連鎖させる
 ・IEnumerable<T> は [a] というより IO [a] ?
 ・実は LINQ to Object は IO と List の合成モナド?

>根底にある発想は関数合成の方

これですが,arrow の SF がまさにそんな感じじゃないかなぁと.
http://d.hatena.ne.jp/propella/20070807

んでは朝ご飯食べにキャンパス行ってくるです.

siokoshousiokoshou 2008/04/16 00:04 > 一回どこかで LINQ の特殊性もきちんとまとめられるか挑戦してみたいところ.
おぉ、wktkしながら待ちます。

> ・LINQ to Object は IEnumerator<T> ではなく IEnumerable<T> を連鎖させる
LINQ to Object のオペレータの中では(言い換えるとシーケンスを受け取ったメソッドの中では)、受け取ったシーケンスを「評価する」ってことが、IEnumerable<T> から IEnumerator<T> を取り出すことってのがなんだか特徴的だなぁと思います。以前某所で混乱してしまったんですが><
IEnumerator<T> を2つ取り出してしまうと2つの別のシーケンスを扱ってることになるのが気持ち悪いし、またそれができてしまうことも不思議な感じがしてます。意味論みたいなことをきっちり考えてみたいけど、もやもやしてきちんと考えれないのがもどかしい、引っかかる部分だったりしてます。

nsharpnsharp 2008/04/16 08:29 > ・LINQ to Object は IEnumerator<T> ではなく IEnumerable<T> を連鎖させる

yield returnの使用を考えたとき、IEnumerator<T>ではあまり自由度が高くないのが原因かな?と思ってみたり。

たとえば、こんな関数は確かにコンパイルは通りますが、

  static IEnumerator<int> F() {
    yield return 1;
    yield return 2;
  }

foreachで使うことはできません。

  foreach (var i in F()) {  // ← コンパイルエラー

激しく不便です。(´・ω・`)

> ・IEnumerable<T> は [a] というより IO [a] ?
> ・実は LINQ to Object は IO と List の合成モナド?

本当は純粋な [a] にしたいんだけど、言語仕様上仕方なく IO [a] になってしまってる、という感じでしょうか・・・。

> これですが,arrow の SF がまさにそんな感じじゃないかなぁと.

Kleisli + 合成(>>>)の使い方はまさにそうですね。

ただ、上にもリンクを出しましたが、次のバージョンのGHCでは、(>>>)関数は Control.Arrow から Control.Category に移動してしまってます。
ので、合成だけなら純粋にCategoryで解釈した方がシンプルです。


Summit最終日に外向けにも何か大きな発表があるのかな?と勝手に期待してみたり。
いずれにしても、来週末が楽しみです。

nsharpnsharp 2008/04/16 08:47 > Kleisli + 合成(>>>)の使い方はまさにそうですね。

あぁ、すいません。よく読んでみたら、SFの部分はKleisliとは関係ありませんでした。(´・ω・`)

リストが絡むと、ふつうの関数(->)とMonad的な関数(Kleisli List)の側面をよく混同します・・・。

siokoshousiokoshou 2008/04/17 07:53 話についていけてないけど、刺激的で楽しいです。
arrow って圏論の射ってやつなんだろうな〜、でも射が関数を抽象化したものらしいってことしか知らなくて、関数と射って何が違うんだろうな〜、みたいなことをぼんやりと思ってるだけだったり。
もうちょっとハスケろう!

nsharpnsharp 2008/04/17 19:36 > でも射が関数を抽象化したものらしいってことしか知らなくて、

いや、もうそれで十分だと思いますよ。w
(目的が圏論じゃなくてHaskellを知ることでしたら。)

射は抽象概念、関数はその具体例の1つ、という感じです。

 射 : 対象Aと対象Bに何か関係があることを示す。どういう関係なのかは具体的に知らんけど、とにかく何か関係がある、という状態。
 関数 : 集合Aを集合Bにマッピングする操作を示す。写像とか言うんでしたっけ・・・?

Haskellでの

 class Arrow a
 instance Arrow (->)

というのは、そのことをストレートに表現していると思います。Arrowはクラス(抽象的)、関数(->)はその具象の1つ、ということで。

圏論の概念は、ウィキペを手がかりに覚えてみるのもよいかもしれません。(つーか、漏れもそのレベル以上の知識はありません。w)
ttp://ja.wikipedia.org/wiki/%E5%B0%84_%28%E5%9C%8F%E8%AB%96%29

siokoshousiokoshou 2008/04/18 09:42 ムムムム!「instance Arrow (->)」!!おぉぉ、関数が射の一つになってる!
もしかして、ここで定義された -> が関数の型宣言の Int -> Int みたいなので使ってる -> だったりするんでしょうか?

「haskell arrow」でぐぐると、モナドとアローについていろんな人が同じような道をたどって似てるみたいなことを書いてますね。yharaさんのとことか
http://mono.kmc.gr.jp/~yhara/d/?date=20070718
読んでると自分の頭の中も徐々に整理されてきてもうちょっとわかってきた感じです。

圏論はなんだかメタ数学って感じですねぇ。日本語でOkって言いたい…。
WinHugs の Arrow.hs を読んでみたところ、これは圏と関数、圏とモナドの関係を書いてあるソースってことなんでしょうか。読んでもさっぱり意味がわかりませんでした><

siokoshousiokoshou 2008/04/18 10:12 > もしかして、ここで定義された -> が関数の型宣言の Int -> Int みたいなので使ってる -> だったりするんでしょうか?
あ、それだと class Arrow a の中の -> がループしちゃうか。やっぱ文法なのかな。

nsharpnsharp 2008/04/18 12:05 > もしかして、ここで定義された -> が関数の型宣言の Int -> Int みたいなので使ってる -> だったりするんでしょうか?

そです。1 + 2 が (+) 1 2 と同じなように、a -> b は (->) a b として扱えます。

そうすると、(Arrow a) => a b c というのは

 (->) b c  -- b -> c と同じ
 (Kleisli m) b c  -- runKleisli を呼ぶと b -> m c が得られる

となるわけです。

ここで元のChannel9のビデオに戻ると、あの4段階の説明というのは、実は

 1. 関数の説明
 2. モノイドの説明
 3. カテゴリの説明
 4. Kleisliカテゴリの説明

となるわけです。

結局のところ、HaskellのMonadって何?っていう答えは、「構造(b -> m c)とその間に成り立つ法則(モノイドのアレ)」という抽象的なもので、その具体例がMaybeとかListとかExceptionとかStateとかSTMとか、現実のプログラミングで役に立つものが多数ある、ということです。(LINQもそのうちの1つ。)

LINQを知る上でこういう知識が必須だとは思いませんがw、新しいモノの見方が増えればどこかで役に立つかもしれません。

nsharpnsharp 2008/04/18 12:17 > 「構造(b -> m c)とその間に成り立つ法則(モノイドのアレ)」

「構造(b -> m c)とその間に成り立つべき関係(モノイドのアレ)」と、もう少しアバウトにしておきます。w

siokoshousiokoshou 2008/04/18 14:40 > そです。1 + 2 が (+) 1 2 と同じなように、a -> b は (->) a b として扱えます。
ええぇぇ!Haskellには驚かされることばかりですが、今回はとびきり驚きました…。てっきり文法だとばかり…。でも、class Arrow a の中の -> はどう解釈されてるんだろ…。

> そうすると、(Arrow a) => a b c というのは
なるほど!ここはそういう意味だったんですか。 a b c ってのを見て固まってましたw

それにしても、圏論の射を使って関数ってものを定義してたんですねぇ。Haskellを学ぶことは数学を学ぶこととほとんど同じことだと気づいたり。どうでもいいことだけど、関数を自身で定義しているんだったら、すでに関数型っていう言葉のイメージからはみ出してますねw

ビデオを通して一貫して語ってることは「組み合わせること」だなーと思いました。関数にもモナドにもLINQにも共通するテーマだと改めて感じてます。くっつけること大事!くっつけれることがもっと大事!

でもなんだろ、一つ理解するたびに3つくらい新たな疑問が沸いてきて困ってますw
あと、モナドについても、LINQとモナドの関係についても、理解が進んだことは間違いないんですが、でもやっぱりあんまり理解できた気がしてなかったり(^^;

できの悪い生徒なのにこんなにいろいろ教えてもらって、とても感謝しています(^^) 本当にありがとうございます!

NyaRuRuさんの疑問の「IEnumerable<T> は [a] というより IO [a] ?」を気にしながら、Haskellのコードを読んでみようかな〜。

nsharpnsharp 2008/04/18 17:28 > a -> b は (->) a b として扱えます。

念のため、こんなサンプルを。これがコンパイルが通ります。(メリットないですけどw)

incr :: (->) Int Int  -- Int -> Int と同じ
incr = (+1)

> それにしても、圏論の射を使って関数ってものを定義してたんですねぇ。

Control.Arrow とか Control.Category は後から出てきたものなので、「再定義」という感じでしょうか。
でも、概念的にはすごくわかりやすくなったと思います。

> でもやっぱりあんまり理解できた気がしてなかったり(^^;

ボトムアップ(コードを書きながら覚える)と、トップダウン(数学的な概念から解釈する)の両方が必要なんだと思います。時間が解決すると思います。

つーことで、炎上したのか!?と思われかねないコメントの量になってしまいましたがw、気長にやってください。

siokoshousiokoshou 2008/04/18 18:07 あら、すれ違ったようですw

> Control.Arrow とか Control.Category は後から出てきたものなので、「再定義」という感じでしょうか。
すごいですね、こんな基本的なところを再定義してしまう言語っていうのも!

> ボトムアップ(コードを書きながら覚える)と、トップダウン(数学的な概念から解釈する)の両方が必要なんだと思います。
じっくり取り組んでみます。

> つーことで、炎上したのか!?と思われかねないコメントの量になってしまいましたがw、気長にやってください。
大変感謝しております(^^) 今後ともよろしくお願いします。

炎上と聞いてやっ(ry炎上と聞いてやっ(ry 2008/04/19 06:05 一応言っておくと、Arrow は arr と *** の分だけ
一般的な圏の射より狭くて、一般的な圏の射を表すためにこんなのがあります
http://www.haskell.org/ghc/dist/current/docs/libraries/base/Control-Category.html

siokoshousiokoshou 2008/04/19 08:16 なるほどなるほど〜。勉強になります。
でも、arr と *** がなんだかわからない><

NyaRuRuNyaRuRu 2008/04/22 10:27 >Summit

この辺にこっそりと追記 (ひどい).
Steve と Ray の Keynote の Transcript が以下に公開されてます.
Ray Ozzie の話は,Press も入ってましたし,基本的には当たり障りのない話なのですが,ヴィジョンということでまああんな感じかなと.
しかし Ray Ozzie は話うまいですね.

http://www.microsoft.com/presspass/exec/ozzie/04-17MVP.mspx
http://www.microsoft.com/Presspass/exec/steve/2008/04-17MVP.mspx

次に各個別製品に関してですが,昼間の私は例によって XNA/DirectX 漬けだったので,他製品に関しては夜にひたすら情報収集という感じでした.
.NET 開発系はやはり Silverlight/WPF の存在感が強かったようで,このあたりは MIX 08 あたりからの一貫したメッセージのような気がします.
この分野には大量にリソースが投下されているぞ,と.この辺はほぼ確定未来ということで,個人的には (次に行って) いいかなと思います.

言語周りですが,今回はあまりフォローできてないです.
聞くところによれば F# のセッション等もあったとのこと.余談ですが F# は主に金融向けを想定しているみたいですね.
なお,先日の組織改編では F# のみが大きなニュースになっていましたが,大きくは今後 4〜5 年に再ターゲットして (静的) 言語系部門を大幅に Restructure したということで合っているような気がします.あんまり書くとアレかもしれませんが,例えば Phoenix Project とか憶えてますか? みたいな.C# チームもだいぶ人が入れ替わったそうですね.波村さんもそうですし.
まあ MS の保有する言語ポートフォリオを見ても,今後しばらくは十分に戦えるだけの基盤は揃ったと思いますし,しばらくは周辺ライブラリやインフラ側の活躍を眺めておけばいいんじゃないかなと.Anders も Linq to X の大増殖には苦笑気味らしいですが.

とまあ以上 Private Communication で入ってきたような情報ばっかりでお届けしました.
他にも Redmond にあった ○○○○ 開発チームが解体されてインドに行っちゃったとか,真の Live のお披露目は予定通り ○○○ とか (日本の TechEd 涙目),日本人がシアトルで生活するノウハウとかそういう雑多なネタを仕入れてきましたが,その辺は折を見て.
ではでは.

nsharpnsharp 2008/04/22 19:45 おおっ、ギリギリな情報ありがとうございます。(゜∀゜)

> Keynote

なんで最終日にやるんだろうと思ったら、Q&Aセッションだったんですね。Canadian大人気w

> 例えば Phoenix Project とか憶えてますか?

あー、device meshとか、そちらの方面で活躍しそうですね。

> しばらくは周辺ライブラリやインフラ側の活躍を眺めておけばいいんじゃないかなと.

確かに、言語よりもライブラリですよね。特に並列・分散周りが・・・。(´・ω・`)
このへんは、Hadoopとかやってると、ライブラリ面でのJavaの底力をすごく感じて激しく嫉妬。

> 真の Live のお披露目は予定通り ○○○ とか

部分的には、明日の朝あたりから(ry
なんだかんだ言っても、あと半年なんですよねえ・・・。

nsharpnsharp 2008/04/23 09:33 > 部分的には、明日の朝あたりから(ry

午後1時まで待たなければならないようです。w

siokoshousiokoshou 2008/04/23 10:15 おぉ、貴重な情報ありがとうございます!
Keynote は公開されるんだ。カナダカナダと強調されてるのは何だろうw

> しばらくは周辺ライブラリやインフラ側の活躍を眺めておけばいいんじゃないかなと.
なるほどー。並列とか同期とか楽しみですね。

> 真の Live
全貌がとても気になります。


> 午後1時まで待たなければならないようです。w
mesh?

siokoshousiokoshou 2008/04/23 14:12 おぉ、ついに mesh.com が!

nsharpnsharp 2008/04/23 14:37 来ましたね。情報が多すぎて追いきれん・・・。(;´Д`)
開発者向けの情報(MOEとかMeshFX)はしばらく出ないみたいですね。

想像してた以上に壮大なプラットフォーム構想のようで・・・。

NyaRuRuNyaRuRu 2008/04/30 09:51 某社も6月のイベントでなんかお披露目やるらしいですね.
App Engineはあのタイミングで一緒に公開すると思われていた何かとかなんとか.

今年は一段と競争が激化しそうですのぅ.

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