Hatena::Grouptopcoder

chokudaiの日記

2011-07-14

TopCoder Open 2011 Marathon Round 3 思考過程ログ

13:08 | TopCoder Open 2011 Marathon Round 3 思考過程ログ - chokudaiの日記 を含むブックマーク はてなブックマーク - TopCoder Open 2011 Marathon Round 3 思考過程ログ - chokudaiの日記 TopCoder Open 2011 Marathon Round 3 思考過程ログ - chokudaiの日記 のブックマークコメント

6/30

2:04

問題を開く。文字列の圧縮系問題?よくわかんない

2:13

凄く可愛い問題ではあるなぁ、これ

1:a2a

2:b3b3b

3:c

みたいなのの時に、abcbcbcbaみたいな文字列が生成される圧縮システム、みたいなのを作って、この1,2,3を当てていくらしい

作っていい文字列数がNで、各文字列に対して、いくつ作っていいよ!みたいなのが決まってる模様

2:18

自明な得点として、まぁ、sum(limit)-N+1文字一致までは余裕で取れそう ここら辺はどうせ最速でyowaさんが提出するから、それを参考に

明らかに同じことをやる人がいてくれると、自分の提出時間を使わないで済むから楽

2:24

これは生成式が凄く大切。完全に生成できるように出来てるんだったら、最適解ゲーになるし、そうでない場合はちゃんと作らないといけない。

2:40

基本的に、元の生成予測データみたいなのが存在するなら、それを予測するゲームになりそう

それ以外の方法がまともに取れる気がしないかなぁ とりあえず生成式をちゃんと読む

2:50

英語が読めないので、ソースコードを確認

順番ソートをして、自分より下位の奴をランダムで1~4回使うらしい

だから、上の例の1は、3を含んでいないから有り得ない、と

で、そこから生成された文字から、0 0~0.04 0.04~0.16 0.16~0.32で均等分布なerorr率を決めて、それだけぶっ壊すらしい なんか分布に違和感があるけど大丈夫かこれ

まぁ、どう見ても元データの予測ゲーである。

2:55

とりあえず、全部30文字とすると、最長で

1つ目:30文字

2つ目:30*4 + 30 = 150文字

3つ目:150*4 + 30*4 + 30 = 750文字

4つ目:2250文字

5つ目:11250文字

みたいな感じで増えてく。これ概算だけど毎回5倍か

まぁ毎回3倍くらいで考えるのが妥当な概算で、20文字平均だとすると、

20 60 180 540

でだ、何を考えてるかというと、next_permutationで全数列に対して、文字数から逆算で予測できね?ってのを考えてる。DPとかで

下から順番にa文字、b文字、c文字、d文字みたいに考えると、i番目の選び方は、4^(i-1)通りしかないわけで、N=4の時、最後の選び方も64通りしかなくって、というかそれぞれ1,4,16,64とかになって、あ、これ全探査出来るね、みたいになる

これ4096だから、N=4の時限定で使えるかなぁ いやなんかどの並び順でも結局うまく言っちゃいそうでダメな気しかしてこなくなってきた パターン数多いよ!

3:03

これ、スコアの判定式もポイント

i文字目が同じかどうか、でひたすら一致を取ってるから、「似たようなもの」を見つけたとしても、それをぴったりの場所で出さないといけない これが難しい

制約がかなり厳しいから、元のを完全再現しないと、ある程度「似たようなもの」を見つけても、最後の方が尻切れになるか、

文字数が合わずに結局使い切れずみょーんって、なる これは避けたい

3:06

これ、1から、見て、下位の奴が、必ずlimit[0]文字以内に始まる、というのも大切なポイントな気がする

で、それが、min(limit)文字以上続く、ってのも大切そう そこからなんか頭から見つけてく、みたいなのが出来なくはない感じ

発見するべき最小単位が、3とか4とかじゃなくって、16なのはかなり気楽 errorが0.32だとしても、まぁ10文字は残ってるわけで、これは楽!まぁエラー2回含んでても、5文字か6文字くらいは残るよね あれこれだと雲行き怪しいか

3:12

これは最適解見つける方向でしか考えられないんだけど、それじゃだめなのかなぁ うーん

今提出した人が、予想通り最速提出したyowaさんを52.12点まで落として、81.82点になってるんだけど、これはやっぱ最適が見つかることを証明してる気がする

もちろん10万とかの時見つからないから、そっちはどうするか、とかも考えながらお布団に入ろうかな

3:24

ちょっとめも

一個下の奴を参照する回数が1回だけの場合、単なる足し算的な感じになって、発見しづらくなる気がする

まぁ、一番上でない限り、上位からの単独指名が入るから、必ずそう、というわけではないけれども

9:35

やっぱり満点並んじゃうんだ・・・TCOのR3で満点並んじゃうんだ・・・

にしても、hirosegolfさんは3時半に提出してるし、相当簡単なプログラムでも満点行っちゃう?

確かにどうにでもなりそうではあるけど・・・えーえー TCOR3でそれは・・・

9:49

いやいやいやいやいや待て待て待て待て 朝だって寝ぼけ過ぎだろう

これ相対評価だろう? 全部特定出来てるのであれば、満点が揃うはずだ そうじゃないとおかしい

それでなんて、みんな78.59で並ぶ?自明解を見逃してる?

10:04

自明解が1文字のみ、ってのもあり得るなぁ

sum(limit)-N+1文字って大体、4*20で80くらいとして、全体長が5000くらいあったら、/26で大体200くらいで負けるよね

一番多く出てきた文字を拾ってくるだけで、ある程度行くよね そういうことなのかなぁ

それを実装するだけで、まだ1位になれるような状況だったりするんだろうか

小ケースの時にsum(limit)が1位になってて(これがyowaさん、jdmetzさんのスコア、18.10)、大ケースの時に、komiyaさんとか1文字単が1位になってる(78.59)と解釈するのが妥当かな?

それだと足して100点に満たないのが明確な矛盾点になるし、誰かがマッシュアップ版くらい組みそうなものだから、MSGMさんかOgieKakoさんが、なんかちゃんと解析するのを組んでそう、くらいなとこか

TheRavenさんが21.00出してるし、そっちもそれっぽいなぁ

よし、納得した 十分説明できる 提出して裏付けが欲しい所だけど

10:14

とりあえず方針を

現在の方針

  • 基本的には、元となるデータの生成を頑張る
  • ダメだった場合、最頻出文字or前半完全一致の、点数の高い方を採用

って感じで 最頻出文字とかの方の誤魔化しも、1秒くらいかけてちゃんとしたごまかしができるようにはしたい

10:24

いやいや待て待て

さすがに最頻出ワードの特定はいくらでも出来るとは思ってて、それが出来るだけでもうかなり省略できるんじゃね?

完全再現が出来なくても、そこそこに省略は出来るんじゃないか、くらいの仮説は立てておくべき気がする

10:33

やー、でも1文字長さを間違えてハマるパターンが怖いなぁ

最頻出をほんとにちゃんと拾えるかは疑問な気もする

10:40

最頻出ワードは、sum(limit)文字以内に現れる、ってのが1つのポイントな気がする

一応捕捉すると、最頻出ワードはS[order[Nとかそんな感じ order[0]かもだけどどっちかは忘れた

2つ目からは、最頻出ワードを特定したら、これが16~32文字なわけだから、これが半分以上一致するワードを適当に探してあげて変換する、とかで良い気が

8文字だと0.32の時全部拾えなくて死ぬのかなぁ うーん?

ちなみに、16文字に対して、ランダムで8文字一致する確率は、一致率1/26だから、二項定理かDPかそんなので計算出来て、

162.29311815363771E-232.29311815363771E-23
159.17247261455085E-219.19540379608723E-21
141.71983861522828E-181.72903401902437E-18
132.006478384433E-162.02376872462324E-16
121.63026368735181E-141.65050137459804E-14
119.78158212411086E-139.94663226157067E-13
104.48322514021748E-114.58269146283319E-11
91.60115183579196E-091.64697875042029E-09
84.50323953816488E-084.66793741320691E-08
71.00071989736997E-061.04739927150204E-06
61.75125982039745E-051.85599974754766E-05
50.0002388081573269250.000257368154802402
40.002487584972155470.00274495312695788
30.01913526901658060.0218802221435384
20.1025103697316820.12439059187522
10.3417012324389390.466091824314159
00.5339081756858421

まぁ、ほぼ無視できる確率、としたいなら、8文字かなぁ 9文字あれば全システムテストで1ケースくらいな気がする

満点ゲーになった場合、これじゃダメだし話は別になってくるけど

で、次、一致率2/3として、検出側のを考える。1/3文字一致くらいの中で多数決を取って、それで検出した後もう1回多数決を取る、みたいなシステムにする予定だから、それなりに、元データに近いものを拾って来れるはず

160.001522438840347450.00152243884034745
150.01217951072277960.013701949563127
140.04567316521042330.0593751147735503
130.1065707188243210.165945833597871
120.1731774180895220.339123251687393
110.2078129017074260.546936153394819
100.1904951598984740.737431313293293
90.1360679713560530.873499284649346
80.07653823388777970.950037518537126
70.03401699283901320.984054511376139
60.01190594749365460.995960458869794
50.003247076589178530.999207535458972
40.0006764742894121940.999884009748384
30.0001040729676018760.999988082715986
21.1150675100201E-050.999999233391086
17.433783400134E-070.999999976769426
02.32305731254188E-080.999999999999999

検出率1/3だと辛いかぁ そんな信用しない方が良さげな数値 まぁ一番辛い場合だけだけど

まぁけど、一番辛い場合はギリギリ無理で、そうでない場合は別にギリギリ、って程でもない、って言うのを裏付けるデータっぽくは見える

満点ゲー?っぽくも見えちゃうなぁ

あとはアレだ、今1/26で計算したけど、実際1/26が妥当か、と言われると、かなり微妙な所だったりするのも気になる所

だって、最大32*8で256文字のアルファベットしか使わないわけじゃん これ多く見積もり過ぎだから、200しか出てこないわけで、ここからゴリゴリやることを考えると、だいぶ偏ってはいそう

まぁ、「半分」が妥当なラインではありそうだなぁ・・・

11:00

とりあえずN=8 errorなし(完璧に分けれる) length=100000くらいで考えてみよう

N=8だから、8通り、32文字の文字列、これに対して、曖昧な検索を行うとする

まぁ、計算量は、100000*32*8=256000000くらい これを8回やっても、なんか30秒間に合いそうな勢い 甘いなぁこれ

大体のケースで満点取れるんじゃね?スタートラインが95点とかになりそうな

13:01

実装してるけど、なんか勘違いした?実行時間が酷い

14:07

直した おいおい大体のケースで一発でちゃんとした回答出てるじゃないか・・・

失敗してる例は、

  • どこで区切るかを間違えちゃったケース
  • 文字数が多すぎて、探索し切れなかったケース

の2つ

後者は高速化すれば多分間に合うし、前者は、前回の上位3パターンくらいを残してあげればどうにかなりそう(当然3倍時間はかかるけど)

速度勝負だなぁ うーん・・・

14:24

http://gyazo.com/0dadca751c7e4a394eddedaecfb392eb.png

これは記念撮影してもいいんじゃないの?w

Submit1: Overall score: 96.85

14:33

10万文字以上で、最後が切れた時の処理を全然やってないから、そこら辺もどうにかしないと

基本的には、最後にs[0]を弄ってあげるだけでいいんだけど、その手前の計算式とかが影響を受けちゃうとちょっと面倒

どうしようかなぁ・・・

15:07

数字参照の一致の時のボーナスで、評価関数がおかしくなってた

これで、最後の方の時に、ちょっと残念な判定をしやすくなってる

これを直してあげると、ちょっとだけよくなる気はす

scoreがover0.68なものが、78個から92個に うん、これは良い

15:33

ぶっちゃけ時間がかかってるの、最初の1ワードを拾う処理だけだし、ここからbest3やら5やら拾ってあげるようにすればおしまいではあるよね

それで十分な高速化が出来れば満点ゲーである 前提が偽?w

いやでも、オーダーがN分削れるのは自明だし、10万ボーダーであれば、確実に高速化できるような気がするなぁ・・・

上記表における誤判定が発生したらアウトだけど、今のところは大丈夫そう システムテストで1個あるとアウトだけど・・・

Submit2:Overall score: 99.91

16:25

最後の尻切れ部分の処理だけど、何文字目まで正答率どれくらいで出せたよ、みたいなのを作ってあげて全探査しないとだめなのかな?

多分100000まで到達してる時だけで良いはずだけど、ちょっと自信ない んーっと、だいじょうぶだよね?

17:17

基本的に、最頻出ワードが探索し終われば後はどうにでもなりそうな感じだなぁ

そこから先は、もう全探査・・・とまでは行かないけど、それに近いものが可能になっちゃうし

17:59

ループの順番を変えようと思ったんだけど、それが出来ないことに気が付いた

何週かさせることで、最頻出文字を正確にさせてるから、そこの部分で結局ダメになっちゃう

ここの計算量落とさないとダメだなぁ 落ちないにしても、高速化しないとだめだなぁ、どうしよう?

19:58

とりあえず複数選択を実装してみたんだけど、どうも具合が悪い んー?

重くなって最頻出発見できなくなるわ、なんやかんやで散々な感じ

21:33

うまくいってない原因は、ワード選択が上手くいってないんじゃなくって、単純に変換できなかった子が拾えてない模様

となると、これが後からのフォローで拾えるような工夫をしてあげたほうがよさげ ワード選択自体は貪欲でも良さげ

1個でもアウトだと全アウトだからなぁ 

上に書いた通り、0.32で長さ16だと、1つにつき、ちゃんと回収できる率32%だからなぁ まぁ無謀だろう・・・

回収し損ねたのを上位レイヤーで回収しようとしたときに、ちゃんと上手く行ってくれるかなぁ

23:42

うーん、誤判定が酷い この時点で、満点ゲーでないことは確信出来た

それならどうするか、なんだけど、んー、どうするべきなんだろう

基本的に、逆転が発生しちゃってたらどうしようもないんだよねぇ・・・w

23:54

ボーダーラインを色々動かしてみて何度も探索すれば、まぁある程度のものになる気はしてきた

大体、最頻出・第二頻出ワードくらいは外れないから、それ再利用して幾つかのアルゴリズム試せば良いんじゃないだろうか

7/1

1:09

色々試してるけどなんか迷走気味

一回寝て頭冷やそうかな・・・

12:56

バグを直したら、前半100ケースの全てで0.68点を越えてしまった・・・

やっぱり満点ゲー?細かい部分適当に処理してるから、満点ゲーだと死ぬなぁ・・・

ほぼ満点+端数ちゃんと確保ゲーとかそんなになるのかなぁ それはそれで嫌だなぁ・・・

みんな満点付近まで追いついてきませんように RedCoder集団にそれをお願いするのは無謀にも程があるけど

16:00

複数候補を出す時に、長さがバラバラになるようにしてみた

同じ長さのもう1個の候補を採用することはまずないだろうから、水平にズレた奴を大量に拾う、みたいなのを避けるため

500ケース中、1ケースにだけヒット こういう細かい戦いだと、サーバー沢山ないとダメなのが・・・w

18:00

よくよく見ると、0.68以上出てても、最後の方が尻切れになってて点数が取り切れてないケースがあるっぽい?

そういうケースをちゃんと拾いに行こう

21:16

最後の2ワード決定時にミスりまくるから、そこだけ全探査に近い事をするようにしてみた

ここまで来ると文字数が少ないから、一応それでも機能してそう

採用ワード数は増やしてるけど、全体の文字数が削れてないやつはぽんぽん削ってけばどうにかなるみたい

頻出ワードが取得できない・誤認しちゃう、の2つが怖くって、その2つを減らせば大きな失点はなくなるわけだし、そっちを詰めたいなぁ

22:34

Submit 7 Overall score: 99.96

うん、まぁ、こんなもんだよね というか満点ゲーなのか・・・

現時点で取れてないのが、seed1~500までで、seed346 398の2つ 1/250かぁ・・・

多分テスト数足りてないんだけど、実行サーバーの問題で500以上はちょっとなぁ・・・うーん

とりあえずこの2ケースがどうして取れないのかの解析をぱぱっとしてみよう

7/5

11:44

とりあえず先頭1000ケース取れたと思って喜んでたら問題制約変更ですよ・・・

基本的に、0.4くらいまでは復元可能性はあると思うけど、それを越えると絶望的だよね・・・

となると、ランダムに適当に生成して多い文字列を採用する、とか、そんな小細工しか浮かばないや みょーん

12:26

適当な小細工でもちょっとは伸びるみたい?

まともな解析しないと勝てないだろうから、こんなん気休めでしかないけどw

Submit 13 Overall score: 93.8 6位/72

まぁこんなもんでしょ、うん

17:11

Psyho 95.41 1 07.05.2011 02:09:14 C++ 9 24

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

ainu7 94.79 2 07.05.2011 03:04:44 C++ 19 21

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

jdmetz 94.48 3 07.03.2011 22:04:49 C++ 4 4

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

rudradevbasak 93.87 4 07.04.2011 09:54:24 C++ 21 12

wata 93.85 5 07.04.2011 05:55:56 Java 11 7

chokudai 93.84 6 07.05.2011 00:50:48 C# 30 13

RAVEman 93.77 7 07.05.2011 01:08:08 C++ 25 17

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

EmK 93.08 8 07.04.2011 23:32:58 C# 7 6

wleite 92.96 9 07.04.2011 19:47:51 Java 1 9

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mojito1 92.51 10 07.04.2011 16:41:30 C# 13 11

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Astein 91.90 11 07.05.2011 03:23:35 C++ 18 18

O_O 91.86 12 07.04.2011 22:42:39 C# 2 6

 

こんだけ判りやすく判れてるってことは、何ケースできちんと解けてるかの勝負になりそうな感じ

トップのPsyhoさんには3ケース分くらい負けてる、って考えれば妥当っぽい

けどなんだろうなぁ、だとすると、最高点95.41の説明が付かない

自分より上の人たちはそもそも戦略が違ったりするのかねぇ うーん

21:06

初手の検出自体は、errorが0.9とかでも上手く行ってるのがあるくらい上手く行ってるみたい

じゃあなんでダメかって、初手検出は出来てるけど、その変換率があまりに低すぎるせいっぽい

きちんと変換率挙げてあげないとだめっぽいけど、初手だけは文字絡みじゃないから、誤検出が怖いなぁ・・・

とりあえず基準甘くしたのを提出

Submit 14 Overall score: 94.28

22:30
  • 16文字
84.50323953816488E-084.66793741320691E-08
71.00071989736997E-061.04739927150204E-06

基本的にこうなんだから、limitsが長い時は、ぎりぎりまでerror許容数を増やすべきだよね

これ16だから半分でこの水準なだけで、n文字のランダム文字列が一致する確率ってもうちょい高いはず

  • 20文字
113.21513330768218E-113.31400981359489E-11
108.84161659612598E-109.17301757748547E-10
92.00945831730136E-082.10118849307621E-08
83.76773434494005E-073.97785319424767E-07
75.79651437683085E-066.19429969625561E-06
67.24564297103856E-057.86507294066412E-05
50.0007245642971038560.000803215026510497
  • 24文字
108.02294944011394E-098.4497642199333E-09
91.33715824001899E-071.42165588221832E-07
81.88037877502671E-062.02254436324854E-06
72.21221032356083E-052.41446475988568E-05
  • 28文字
113.00360620854222E-093.18256281920352E-09
104.58884281860616E-084.90709910052652E-08
96.03795107711337E-076.52866098716603E-07
86.79269496175255E-067.44556106046915E-06
  • 32文字
121.07984943277803E-091.15008991597298E-09
111.54264204682576E-081.65765103842306E-08
101.9283025585322E-072.09406766237451E-07
92.09598104188283E-062.30538780812028E-06

ということで、安全に行くなら、20以下で9文字、28以下で10文字、その他11文字一致で十分、ってとこかなぁ

最悪な100ケースについて、1ケースくらい誤認しそうなとこをボーダーにしてる errorが小っちゃい時は、これに+1か+2してあげれば超安全

もう1厳しくても良いかな、くらいの印象だけど 0.35↑なときもう1厳しくするかぁ

いや長さとの兼ね合いで弄るべきなんだけど、ってそういうとこ細かく見てくとキリがないw

23:30

つーことで、最頻出ワード選択もerror率反映+error判定上限を↑のに設定で提出

Submit 15 Overall score: 96.68 いちばん!やっほい!

7/6

0:03

無理な時(dataが短く、error率が頭おかしい時)の焼きなましって、permutation決めて、適当に配置した後に、あるレイヤー以上のpermutation変更と、中身変更で対応できるんじゃないだろうか 中身変更するのは、permutation変更したのの1個下か0個下とかで

これをうまくやれば、結構いい感じに組み替えられる気がする ちょっと机上の空論っぽいけど

探索途中で打ち切りの場合は、自信の持てるところまで、要素の中身固定でいいしね!

最頻出ワードが出てる場合なんかはさらにらくちんだし 最頻出の出現位置だけ合わせてあげるように焼きなまし、多分できそう

ちょっと組むのが面倒になりそうだし、そこまで得られるバリュー大きくないから後回しだけど

・・・つっても他にやれそうなこともないし、明日何も思いついてなかったら明日組むかぁ

1:33

テスト結果見てると、ある程度データが長ければ、error率0.6とかでも何とかなってるケースがある模様

自分のプログラム頭おかしくないかこれ ここまで出来るもんか すげーw

となると、↑の実装無駄じゃね?って気も ここまで回収できるのに、それをする必要があるように思えない うーん

小さいケースなら一応強いのかなぁ うーんうーん あんまり強い気がしないなぁ

3:06

なんか実質的にTLEっぽくなってる問題がちらほら

速度改善しないと最終的に勝てなそうな感じ うーんうーん

14:47

なんか色々とバグっていた 修正

バグ修正だけでまだまだ上がる時期 丁寧なプログラム組むの凄くたいせつ

Submit 20 Overall score: 95.49 1位タイ Psyhoさんと仲が良すぎるw

23:41

うーん、error>0.32の時の対策がまだまだ甘い!

とりあえず、+1やら+2とかで動かしてたボーダーを線形に変更 これがたまにうまくいかないから、最初線形でやってみて、うまくいかなかったら定数調整で、みたいな感じで余裕があれば2回やってみる感じにまぁもともと確実に上手く行くラインじゃないから、線引き出来ないなら両方試すのは正当性があるし何の問題もない

 

んで、1発目で文字上手く取得出来てないから、最初だけゆとり的に、エラー許容数をやたらあげて探索して、出てきたワードのn文字目の最多出現文字をn文字目な感じのにしてもっかい探す、的な感じに

これはもともとやってたけど、知らないうちに削除されていた

で、ゆとりシステムを入れるとなぜか点数が落ちるのは、おそらく、「文字が長いもの」を優遇し過ぎなため

これは、元々は文字が長い方が取得しづらかったからだけど、error率によっては文字が短いもののほうが取得しづらいため・・・ってあれ、元々文字長いほうが難しくね?

よくわかんなくなったけど、とりあえず文字の長さの優遇を減らしてこれを改善してあげる ねむいんだよばかー!

あと下限作ってて調節が上手く行ってないのもどうにかしてあげる 長さが違ってもある程度平等に評価できるようにするのがむずい むぅ

7/7

たなばた!

21:17

エラー許容数を、

maxerror = (int)(maxerror * (Math.Max(errorpoint - 0.3, 0) * 2.5 + 1));

って書いてたんだけど、

maxerror = (int)(maxerror * (Math.Max(errorpoint - 0.27, 0) * 2 + 1));

にした方が良いっぽいのが、統計により明らかになったので訂正

線形で直したい時は、適当に定数を弄った後、errorpointがどういう時にどっち側にズレてる、みたいなのがすぐ判るから、1ケースごとに見て行けば、こういう部分の妥当な設定はそこそこ簡単

まぁ、線形でおkって予想が正しくない場合に死ぬんだけどねw

Submit 28 Overall score: 96.51 これでようやく1位に復帰っ

7/9

17:43

院試から帰宅したら、3位に落ちていたので、隠し玉を発射

ランダムで答えを出す際のを丁寧にしただけ 2つくらいアルゴリズムを用意して使い分け

Submit 32 Overall score: 96.56

+0.5を期待して+0.5だったけど、nhzpさんに0.04及ばず2位 みょーん

途中から余裕がなくなったのでここまで 最終10位まで落ちました みょーん

MariargeniMariargeni2012/07/10 05:46Thanks for sharing. Your post is a useufl contribution.

kcbdqckcbdqc2012/07/10 16:25olAwf5 <a href="http://emtrwqbzuucj.com/">emtrwqbzuucj</a>

rgbzfstoislrgbzfstoisl2012/07/11 20:531XUN6E , [url=http://hmbaznmyhpjf.com/]hmbaznmyhpjf[/url], [link=http://yjwwllimimpp.com/]yjwwllimimpp[/link], http://nutgonijbopo.com/

znyagalbznyagalb2012/07/12 12:381vDEdl <a href="http://nxcilmpgprud.com/">nxcilmpgprud</a>

gzrjuwnmfgzrjuwnmf2012/07/12 18:11ggpOLH , [url=http://eqrvhfrqwezq.com/]eqrvhfrqwezq[/url], [link=http://hxgufjhuuldz.com/]hxgufjhuuldz[/link], http://sceiwcbcbqcl.com/