Hatena::ブログ(Diary)

純粋関数型雑記帳 このページをアンテナに追加 RSSフィード Twitter

このページはHaskellを愛でるページです。
日刊形式でHaskellなどについての記事をだらだらと掲載しとります。
2004 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 06 | 07 | 08 | 09 | 11 |
2007 | 03 | 04 | 05 | 07 | 08 | 09 | 12 |
2008 | 02 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 03 | 05 | 06 | 09 | 10 | 11 | 12 |
2010 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 12 |
2011 | 01 | 02 | 05 |
本体サイト

2004年09月28日(火) 小規模スクリプト言語とDSLの境界

[]雑記 雑記を含むブックマーク 雑記のブックマークコメント

M氏のおかげでacm.uva.esのオンラインコンテスト

忘れずに済んだ。

その復習?などをやっていたらこれまたえらい時間がかかってしまった

というかなんと言うか。

[]Domain Specific Language (或いはコンビネータ言語) Domain Specific Language (或いはコンビネータ言語)を含むブックマーク Domain Specific Language (或いはコンビネータ言語)のブックマークコメント

というわけで、前回の続きである。

続きである、とはいっても、前回のようなしょうもない話ではない。

(…しかしながら、なんだかぐだぐだで中途半端な話に…)。


唐突だが、何かを実現するのに小規模な言語を実装するのが

適当だと判断された場合、いかなる解決法を取るのが良いだろうか。

例えば、ゲームシナリオだったり、また例えば、

今回のICFPのように蟻コードを生成するような場合だったり。

私が行ったのは、これがいかにも普通のやり方だと思っていたのだが、

小規模なスクリプト言語コンパイラを実装するという手法であった。

要するにプログラムとしては、String→Stringなる関数であり、

これを普通に字句解析、構文解析、…とやって適当に作った。


が、Lisp界隈ではよく用いられている(?)もっと別な解決法も有る。

それが表題に書いたDSLと呼ばれる手法なのであるが、

(Domain Specific Languageはドメイン特化言語…そのものの意味では

別段小規模スクリプト言語とあまり違いがないのだが、

ここでは言語内にそのような言語様の物を構成することを考える)

言語生成に関して具体的に述べると、基本的に目的の蟻言語を生成する

プログラムを書き、その際に書きやすくなるようなライブラリを作る。

ということになるのだろうか。

(HaskellでもHtmlライブラリはこのような方法によっている。)


まず、もっともプリミティブなものを考える。

ターゲット言語はまぁ、一応蟻アセンブリということにしておく。

命令の詳細はICFPのページを見ていただくしかないが、

(http://www.cis.upenn.edu/proj/plclub/contest/ants.html これの2.8節かな)

まぁ、知らなくても大体は分かるのではないかと。

私自身もさっぱり覚えていないので。

Sense LeftAhead 518 510 Home
Turn Left 57
Move 512 518
PickUp 826 518
Sense RightAhead 514 518 Food

↑は、うちの蟻から適当に引っこ抜いてきたプログラムである。

例えば、このような"プログラム"を生成するプログラムは、

main = mapM_ putStrLn
  ["Sense LeftAhead 518 510 Home"
  ,"Turn Left 57"
  ,"Move 512 518"
  ,"PickUp 826 518"
  ,"Sense RightAhead 514 518 Food"]

このように書ける。

なんじゃこれは…?と思われるかもしれないが、

PerlCGIとか書いたら似たようなコードになるのではなかろうか。

このようなプログラムの生成をとことんまでに補佐するものを

作成しつつプログラム生成プログラムを書くのが、

この手法の主なアイデアである。


まず、上のコードのどこがまずいのか。

まぁ、明らかに上のようなコードは書く意味すら無いようなコードなのであるが、

ここはあえて順を追って考えていこう。

まず一つ目に、表示しているコードが間違っていてもそれを知る手段が無いこと。

つまり、

main = putStrLn "Tuen Loft 57"

とかになってしまうのをコンパイル時にチェックできないということ。


ここで一つ抽象化の度合いを上げる。

この時点で"蟻プログラム"というものは単なる"文字列"にされている。

単なる文字列ではなくて"蟻プログラム"というものを定義し、それを用いることにする。

data Mnemonic =
    Sense  Direction Int Int Condition
  | Mark   Int Int
  | Unmark Int Int
  | PickUp Int Int
  | Drop   Int
  | Turn   Direction Int
  | Move   Int Int
  | Flip   Int Int Int

data Direction = ...
...

type Program = [Mnemonic]

さて、今度はプログラムが単に文字列ではないので、

表示する際に文字列に変換する必要がある。

compile :: Program -> String

なる関数を作成すれば良いだろう。

ちなみに、この程度のデータ構造であれば

deriving(Show)して、compile = concat . intersperse "\n" . map show

でちゃんと表示できてしまいそうな気がしないでもない…。

ここで定義したものを用いると先の例は

main = putStrLn $ compile progn

progn =
  [ Sense  LeftAhead 518 510
  , Turn   Left 57
  , Move   512 518
  , PickUp 826 518 ]

等と出来る。これにてミスタイプが検出できるし、

ようやく少しだけまともになってきた。


次に、別方向にこれを拡張する。

今回、直書きが良くない最大の理由は自分で行番号を

書かなければならないことだったように思う。

…ので、上プログラム中、518とか、510とか、

どうでもいい数字を自分で管理するのはいやなのである。

(いやというか、ほとんど不可能だろう…)

そこで、今単にリストになっているプログラムに構造を与えて

その辺の管理を自動化させることにする。


蟻アセンブリを再度見てみると、

分岐する命令 :Sense PickUp Move Flip

分岐しない命令:Mark Unmark Drop Turn

分岐するものと分岐しないものがあることが分かる。

このうち分岐しないものは、ジャンプアドレス

常に次の命令のアドレスでもおいておけばよい。

分岐する命令も、片方はそうしておけばよい。

そうすると、分岐する命令の片方をなんとか指定できれば、

それ以外のアドレスは結構自明に管理できるということになる。

data Fragment = (コード片)

mark   :: Int -> Fragment
unmark :: Int -> Fragment
drop   :: Fragment -- Preludeと名前が被る…
turn   :: LeftOrRight -> Fragment

 -- 失敗時の分岐先を渡す。
sense  :: Direction -> Condition -> Fragment -> Fragment
pickup :: Fragment -> Fragment
move   :: Fragment -> Fragment
flip   :: Int -> Fragment -> Fragment -- これも名前が被る…

makeProgram :: Fragment -> Program
compile     :: Program -> String

プログラムの一部をコード片として表現し、

それらを組み立ててプログラムを作っていく。

 -- 逐次実行
seq :: Fragment -> Fragment -> Fragment

このようなものを作ると

clearAndSet a b = unmark a `seq` mark b

適当につなげられるようになって組み合わせの幅が広がる。

さらに、Fragmentに適当に文字列を設定してラベル付けが

出来るようになるといいかもしれない。

label :: String -> Fragment -> Fragment

goto :: String -> Fragment

全く実装の無いコードが続いてしまったが…

次のような使い方をするものと考えている。

(ちなみに、上記のコードは適当にでっち上げたので、

どう実装していいのか分からない)

main = putStr $ compile start

start = forever nop

forever f = label "forever" $ f (goto "forever")

nop next = flip 1 next

何もしない蟻…のつもり。

なんかすごく独りよがりなコードになってしまっているような?気がする。

Fragmentの実装をどうするのか…?という重要な問題をひとまず放置しているが、

参考にさせてもらった 'Team Dunkosmiloolump'

(http://urchin.earth.li/icfpcontest/2004/Introduction)

のコードがまさしくこのアプローチなので、私のしょぼい実装よりは

ここを参照してもらうほうが遥かに良いと思う。

(ライブラリ部分は難しくてよく分からなかったんだけど…)

http://urchin.earth.li/icfpcontest/2004/sub/tools/compiler/Test.hs

最終的には、このように蟻プログラムを表現できるようである。


と、説明はこの辺にしておいて。

コンパイラを実装するのではなくて言語内にDSLを作るメリットは何だろうか。

これはおそらく、用いた言語のパワーをそがれることなく

目的のプログラムの記述に使うことができる、ということだろう。

私の作ったスクリプト言語でも見てもらえば分かるであろう。

単に繰り返しとかですら、わざわざ実装しない限り使えないので、

今回のように3日限定等というコンテストではHaskellなみに強力な

コンパイラが出来上がるわけが無い。

"the language of choice for discriminating hackers!"

であるHaskellが蟻プログラムの記述にも使えるということは

その時点でかなり有利であるといえるのだろう。


反面、デメリットはというと、

コードの生成にHaskell理系が必要なこと、ぐらいであろうか。

これはおそらくゲームシナリオの記述にこの手法を使ってしまったりした場合、

その実行にHaskell理系が必要になってしまいよくないかもしれない。

まぁ、今回はHaskellで終始開発を行うものなので、なんら問題は無いだろう。


しかしまぁ、公開されてるソースとかを見ていると、

DSL的な手法を用いているチームが結構あるような感じだ。

こんなことに今更驚くなよ、という方も、ICFPに参加したのは

Haskellを本格的に勉強しようと思ってそう日も立たないころだったので、

温かく見守っていただけると幸いだったりする…。

とりあえず、今後こういうものを書かなければならない

ケースが出てきたときに使ってみようかと。

トラックバック - http://d.hatena.ne.jp/tanakh/20040928

2004年09月27日(月) 云いたい放題

うちのテレビブラウン管から液晶に。

ざ、残像が…。動きのある画面はやっぱり辛いようだ。

[][]ICFP 再考 前編 ICFP 再考 前編を含むブックマーク ICFP 再考 前編のブックマークコメント

来年度のFirst Prize獲得(?)に向けてちゃんと復習をしておこう…

まず、各々の強さの分析を。

(result等は昨日の日記を参照されたし)


resultのページには得点で成績が書かれているので、これを勝敗数にしてみる。

各蟻の評価は、361匹による総当たり戦、それぞれ100個のマップで戦い、

それぞれの位置を変えてさらに戦う。(結局一匹相手に200回戦う)

勝つと2ポイント獲得。負けると0ポイント。引き分けると両者が1ポイントを獲得する。

360匹相手に200回づつ戦うので結局72000回戦っていることになる。

引き分けがあるので、正確な勝敗数は分からないが、引き分けをとりあえず

高々1ということにして計算してみた。

Dunkosmiloolump-1    71073 勝  926 敗 1 分
Dunkosmiloolump-2    70973 勝 1026 敗 1 分
Fractionless Bananas 69153 勝 2847 敗 0 分
haskilled            68809 勝 3190 敗 1 分
anichkov             68490 勝 3510 敗 0 分

づんこの勝率はほとんど9割9分に近く、やはり圧倒的な実力であることが分かった。

うちの蟻は何発入れることが出来たのだろうか…。

ところで、resultの表にApproachという欄が有る。

higherとか、preとか、書いてあるところである。

下のほうを見ていくと、mutとかhandとかがあることに気付く。

一応、確認できるものを列挙すると、

higher pre mut hand oth unkn …が有るようである。

hand…は、手書きか。

mutは語感から言って遺伝的アルゴリズムだろう。

othはothers,unknはunknown,

ということはhigherは高級言語、preはプリプロセッサか。


と、それを踏まえて、結果を見てみる。

まず、Lightning Division。うちはシミュレータを作るだけで

一日以上かかってしまったのでこれには提出してないんだけど…

一位のところがhigher、二位以降がずらーっとpreで続いている。

使用言語は、Perl,Ocaml,Ruby,Perl,Scheme,…と。

なるほど。この辺の言語は高速プロトタイピングにはやはりそれなりに有効なのかな?

我らがHaskellは…21位のTeam Lone Haskellerがトップと。

(一人ぼっちHaskell使いとは…泣けるなぁ)

と、それはいいとして。

意外だった、Lightning Divisionですらhandは良い成績を残せていない。

今回の問題、手書きは駄目だったようである。

手書き解は全体を通しても、C++の25チーム、Ocamlの24チームに次いで

23チームが採用と、採用者自体はとても多いのだが、

どうやら、安易に手書き解で出してしまう人が多かっただけのようである。

アプローチのほうは、トップのRedTeamがhigherなのでなんともいえないが

それ以降のチームがほとんどpreなので、preのほうが平均的に

良好な結果が残せるかもしれない。

しかも、RedTeamはhigher採用しているといっても、チーム人数が7人と大所帯で

物量作戦が使えるので、その辺を考慮すると小規模チームにおける参考にはならないかもしれない。

2、3人で戦う場合、やはり24時間以内でシミュレータ作成、

高級言語コンパイラ作成、蟻実装は難しいのではなかろうか。

単純なプリプロセッサをちょちょいと実装して蟻を頑張って

でっち上げるほうが何とか成る蓋然性が高そうだ。


次に本題、Main Divisionのほうである。

今度は先ほどの結果とはうって変わってアプローチはhigher一色となる。

上位30匹中、higherが24匹、preが6匹となっている。

preの最上位は7位でThree-headed monkeyチームのもの。

ちなみに、このチームはLightning DivisionでPreを採用したチームのうちで

順位的に一番踏みとどまったチームである。

使用言語もこれまた先ほどとはがらりと変わり、

Haskell、C/C++、が上位のほとんどを占める。

OCaml,Perl,Python,Scheme,Lispがその合間をぽつぽつと。


まず、分かりやすい、アプローチによる考察から。

これは制限時間が3日ともなると、プリプロセッサと高級言語の間に

生産性の差が生じてくるということであろう。

要するに24時間という厳しい時間制限でとりあえず何か

作らないといけない場合、言語設計に時間を割くよりも

貧弱な(?)言語で蟻そのものを作る時間を増やすほうが良好な結果が出せて、

全体の時間がそれなりにある場合は言語設計にもそれなりに時間を割いた方が

絶対的には良好な結果が出やすくなるということであろうか。

しかしまぁ、うちのチームはおそらくpre→higherというように途中で変わった。

というよりも、私がどんどん蟻言語を機能強化していき、

某M君は刻々と変化する蟻言語で蟻実装を…という感じで。

まぁ、なるべく変化による負担は無いようにはした…つもりではある。

結果的にhigherが上位のかなりを占めているということから、

最初preでやっても、途中で言語の強化にも多少の時間を割いたほうが

結果的に良いものを作れた確率が高かったということだろう。


higherとpre以外、

例えばmutは今回の問題ではイロモノだったようである。

M君も少しmutでチャレンジしたらしいが、体系的に

強い蟻を生成することには成功しなかったようである。

(一応別チーム名で送ったようだけど…あんまり強くないね)

handはhigher>preと考えるならこれまた論外である。

othの人はどんなアプローチなのだろうか。結構気になる。

othは一チームしかいない上に全然強くないのだが…


次に、先ほど置いておいていたMain Divisionによる言語間の差異を考えてみる。

Lightning Divisionで猛威を振るった(?)スクリプト言語を振り払い、

HaskellとC/C++が上位を占めている。これはどうしたことだろうか…。

Lightning DivisionでトップだったRedTeam以外のLightning Division

の上位チームは大体preを採用している。

で、Main Divisionでは上位にランクインするにはhigherのほうがラク?

だったようである。Lightning Divisionでわりと上位にいた蟻も

preの縛り?によりことごとく順位を落としている。

やはり蟻の絶対的強さを上げるためには言語の支援が必要だと。

私の適当な予想だと、PerlPythonScheme、等の構文解析があまり得意ではない言語

(かどうかはよく分からんです…よく分からんのにこんなこと書いちゃいかんわな…)

においては、高級言語コンパイラを作るのが多少大変なのではなかろうか。


その点では、Haskellはおそらく最強クラスに入る。

パーザコンビネータというアイデアは柔軟性、記述の容易さともにすばらしい。

C++においてはC++そのものの力というよりもyacc/lexといった

超定番パーザジェネレータの存在が大きいだろう。

それ以外なら、OcamlはOcamlyacc/lexがあったような気がするし、

これも普通のyacc/lexと同様に使えたはずである…がOcaml

ふるっていないのはこれいかに。(不調?)

Perl正規表現でがしがし…は明らかに力不足。

でも、構文解析ライブラリがあるらしい…?

(ごめんなさい…Perlあんまり詳しくないので詳細は知りません…

PythonRubyなどにもライブラリありますね…)


で、結局のところなにが言いたかったのかというと、

今回のは、higherな…あるいは十分にリッチなpreなアプローチ

(…をhigherというのか?)をとりやすい言語が有利だったのだろうか、ということで、

そうするとHaskellC++、おおよそかけ離れた言語

今回の2強の言語になっているのもそうそうおかしな話ではないのかもしれない。

(いや…おかしいか…?)


長々とよく分からない話を展開して来たが、

ここでいきなりHaskell限定の話に切り替え。

Haskellでのhigherアプローチの方法論を考える。

考える…というか、これに参加した当時の私には

文法設計〜コンパイラ作成、の流れがほとんど自明な

手法だと思っていたのだが、トップチーム、づんこのとっている方法、

あるいはHaskell標準の数々のコンビネータライブラリを考えると、

もっと別なやり方で高級言語を設計できることに気が付いた。

(気が付くも何もあらへんけど…)

というわけで、Haskell特有のその辺の話を次回に。

(いや、Ocamlでも出来るのかな…。あるいはSchemeでも…。

まぁ、その辺はどうでもいいや)

トラックバック - http://d.hatena.ne.jp/tanakh/20040927

2004年09月26日(日) 驚き、喜び、そして悲しみ。

本読み中に溜めてしまったネタもそろそろ終わり。

[][]ICFP Programming Contest 2004 ICFP Programming Contest 2004を含むブックマーク ICFP Programming Contest 2004のブックマークコメント

6月の頭ぐらいに参加した"ICFP Programming Contest"

(うちのチームも http://fxp.hp.infoseek.co.jp/icfp2004/index.html

このへんに成果を公開しています)

の結果がようやく発表された。

http://www.cis.upenn.edu/proj/plclub/contest/results.php

長かったな〜うんうん。

結構強いやつが出来てたように思うけど、

どの辺まで行けたんかな〜。


………

………

………

(上のほうから見ていっている)

Full Main Division Results

Place Points Team Team size Ant Approach Language Ant size

1 142147 Dunkosmiloolump 4 M1 higher Haskell 3104

2 141947 Dunkosmiloolump 4 M2 higher Haskell 3134

3 138306 Frictionless Bananas 2 M1 higher Haskell 8004

4 137619 hasKilled 2 M1 higher Haskell 2834

5 136980 anichkov 3 M2 higher C++ 8558

………

ンン?!

>4 137619 hasKilled 2 M1 higher Haskell 2834

あ…あれ、これってうちのチームじゃなかったっけ?

(蟻のサイズを確かめてみる…確かにうちのチームだ)

ぎゃわー。こ、これはびっくり!!


まさか4位?4位ですか?

いや、Dunkosmiloolump(以下づんこ)が強さ同じぐらいのやつ2つ出してるから

チームとしては3位なのか!?

しかし驚いた。公開されてる蟻には結構勝ててるなぁ、と思っていたら

こんなに強かったなんて。私は今、猛烈に感動している!


http://www-ui.is.s.u-tokyo.ac.jp/~kwsk/ICFP2004/table.cgi

このへんのページを見ていたとき、づんこは手が付けられないほど強いなぁ…

と思っていたので、まぁ、づんこ優勝はやっぱりなぁという感じ。

Frictionless Bananasは正直あまり覚えていなかった。

上のページで見てみると、餌場折りたたみ方式のやつか。

改めて見てみると結構強いかもしれない。

づんこはもう徹底的にスピードにこだわった蟻で、

後は餌置き場を完全防御か。

しかし、何回見てもすごい。なんというか、足周りからしてすごい。

移動速度が違うんだなぁ…餌回収もなんだか無駄の無い動作だし、

戦略自体はうちもづんことほぼ同じなんだけど。

偶然にも餌倉庫の形も全く同じ…まぁ、若干の相違はあるものの。

基本的に餌速攻回収+回収した餌は渡さない方式。


しっかし、あと700点弱でSecond Prize、Haskellを公に自慢しまくれる権利が

獲得できたのか。あと、300ドルも。さらに、ICFPへの参加?

そう思うと非常に悔しい悔しい。もっとスムーズに作業できていればあるいは。

…いかんいかん。また来年来年こそは。


あ、一つ忘れていた。

今年は上位をHaskellが独占である。

づんこもFrictionless BananasもうちのチームもHaskell

やったー。Haskellばんざーい。

もう、便乗しちゃいます。

"Haskell and C++ are fine programming tools for many applications."

"Haskell is the language of choice for discriminating hackers!"

というわけで、みなさん、Haskellを使いましょう!

shinichiro_hshinichiro_h 2004/09/23 06:54 ひゃーすごいっすねぇ。おめでとうございます。来年こそ…ってこれは去年も言ってました。いやはや世の中はすごい人ばっかりだ…

tanakhtanakh 2004/09/23 18:31 どうもありがとうございます。…とはいえ、私はほとんどコンパイラばっかり作っていたようなもので。
今回初めて参加したのですが、かなり楽しかったので、
来年も是非参加しようと思います。
(そして、自力でHaskellを布教…ぐはぁ)

luvtechnoluvtechno 2004/09/28 20:36 はじめまして.kwskといいます.上で紹介していただいたアプレットの作者です.tanakhさんのantも登録してみましたのでよろしければ御覧ください.
ほんとはアップロード機能とかちゃんと作ればよかったんですけどね.

nvacanvaca 2004/09/29 15:26 はじめまして(練習会ではあったけど)チームGNCの一番へんな人といえばわかってもらえるかな?FPGAの人です。おめでとうございます〜!僕もIseriaQueenというチームで出たんですが(僕は可視化ツールを作ることしかできなかったけど・・・)うちらは35位でした。しかも、みんなC++で組んでいるという・・・(笑)うちらも来年も参加すると思うので、がんばりましょ〜!

tanakhtanakh 2004/09/29 18:27 >luvtechonoさん
どうも、はじめまして。登録していただきありがとうございます。
これでうちの蟻もあの蟻達と戦えるんですね。
早速見せていただいたのですが、うちの蟻、致命的なバグがありました…。たまに倉庫のフタ役の蟻がロストしてしまっているというか。あそこは中心位置に餌もちの蟻が来たら出発するはずなのですが、FriendWithFoodで判定すべきところをFriendで判定してしまっていて、餌持ってない仲間がふらふらっとやってきてもフタ役がどこかに行ってしまって、もうなんというか…どんどん終盤で餌もっていかれてますね。そこだけ直したいなぁ…と思ってももう遅いですね。
>nvacaさん
ええ、はい、覚えてます。その節(?)はどうも。しかし、ICFPに参加されていたとは、世界はなんとも狭いですね。Gokuriの川中さんも参加されていたようで、結構ICPCと客層が被っているのかな…。うちのチームはHaskellにC++にVBまで使って、いろいろ入り乱れていました。VBはM君(…分かりますかね?)の持ち言語なのですが、後一個順位が上なら、VBが”fine programming tools for many applications”というすごいこと?になってたですね。ではまぁ、来年も、お手柔らかに。

mayahmayah 2004/09/30 22:47 Gokuri の真耶です。チームとして3位おめでとうございます(直接)。
さすがに一人で全部やるのはかなり大変で、まったく強くないものが出来てしまいました。戦略もかなり中途半端で、私個人の限界課も知れません。Gokuri の k.inaba さんも ECMAScript で参加予定だったのですが、シミュレータだけ作って、その実行のあまりの遅さ(当然)にやめてしまいました。
東大で参加が多いのは、ML 演習(OCaml 演習)で TA が ICFP の参加を毎年煽っている(最終課題として認められる)からです。一度参加すると毎年参加するので、参加者が単調増加しています。
来年も参加します (さすがに来年はチーム組みたい)。お手柔らかに。

tanakhtanakh 2004/10/02 02:03 おお、mayahさん直々にとは恐縮です。
確かに今回は一人では大変だったかもしれませんね。しかも、結構分業が利くような問題でしたし。しかし、k.inaba さんも ECMAScript とはまた豪気ですね…。東大のML演習のページは実は去年あたりにOcamlの勉強のためにこっそり読ませていただきました(いやはや、日本語のML資料は貴重ですから)。最後のほうにICFPのことが書いてあって、それで私もICFPの存在を知ったような気がするんですが、まさか本当にあれで提出する人がいるとは思いませんでした…。
まぁ、来年も頑張りましょう。

racubg auolracubg auol 2007/02/04 14:49 iwvm xofr qkpjcu sodmq skbcewrvj nmlbe zyrewq

pwfv vbogefpwfv vbogef 2007/02/04 14:50 nwfyosih khybgu enbwzxa dfebxotmp mhrynsd ixzswnbhj ybfwnj http://www.npbgw.hinubt.com

vobduci jdgweqavobduci jdgweqa 2007/02/04 14:50 whsq ygtbi wjnmyta wkjybapr oklq cughrljey yhmrk <A href=”http://www.uefvozh.qwvmp.com”>bqaxg wtkb</A>

yaiu lfroaxyaiu lfroax 2007/02/04 14:50 boaic pykzo mdyuak lxtjdvnyg fjxq ghwsjtd olijza [URL=http://www.btuad.xqnpdfm.com]pfnetoxv qrth[/URL]

dbiptkeh ckyrzhjudbiptkeh ckyrzhju 2007/02/04 14:51 uodqmsfrb lfuvo swpbv xdpgv dqxfwaplh biltpqjwd glfkindbx [URL]http://www.ihogxf.vespzf.com[/URL] kbvutxslo krfiv

トラックバック - http://d.hatena.ne.jp/tanakh/20040926

2004年09月25日(土) 乱数プログラマと呼ばないで

書き溜めている話題が多いからどんどんいくよ〜

まぁ、どうでもいい話だけど。

[][]ICPC強化合宿(9/18〜21) ICPC強化合宿(9/18〜21)を含むブックマーク ICPC強化合宿(9/18〜21)のブックマークコメント

7月の初頭、私達はICPC国内予選に参加し一応5位という成績で通過したのであるが、

アジア予選日本会場の大会中国人が毎度毎度一位を掻っ攫っていくのが

とある方々?にとってお気に召さない様子で、

日本強豪チームを世界強豪レベルにまで持っていくことを目的として、

この度強化合宿なるものが画策されていたようである。


日本強豪チーム…とはあまりにも抽象的な定義であるが、

ここでは今回の国内予選で4問以上解いたチーム…とのことらしい。

ゆえに我らも召集される段と相成ったわけで、

新幹線でちょっくらそこまで、と東京行き。

本当はバスで来いとか無茶なことを言われたのだが、

虚弱体質な私は無論新幹線を選ぶのであった。

というか、会津大学と、うち以外はみんな関東圏なので、

なんというかもう、……。


…とまぁ、そんなことはどうでも良くて。

強化合宿では3日で19問の問題を本番形式で練習した。

Gokuri-Squeezeがやはりというか、強力無比だった。

19問中解けてなかったの2つだけだったのかな。

うちらはというと…

なんかもう、あほな部分だけを見せ付けたような印象であった。

今回の練習、入力がいやらしすぎ…だと思った。

解いても解いてもAcceptしない。

私はこんなところに"世界を統べる冷ややかな悪意"(cf.暗黒館)を感じ取って、

のっけからもう自暴自棄になってしまった。

実際問題、入力はコーチの人たちが用意したもんだったし、

しかもrejectされるのをみてケラケラ笑っているではないか!


そこから我らの反撃が始まったのである。(…うそ)

発端はこの問題。

1<=x,y<=9,(x,y)を中心とする半径1の円がいくつか有る。

それらにカバーされる部分の面積を求めよ。

(誤差は最大0.01に抑えよ)

これは実は幾何的に解くのは非常に難しい。

これまた他の問題が全然Acceptしない状況に痺れを

切らしまくっているときであった。

この問題は精度があまり要求されない、かつ座標の範囲が狭いので、

メッシュに切ったりするのが、まぁ普通な解法であろう。

が、そのように解くぐらいならもっと簡潔な方法がある。

モンテカルロ法である。誰しもが一度は円の面積を求めたことが

あるはずである。そして、そのあまりの精度の悪さにため息を漏らしつつ

それ以降まず使わないモンテカルロ法

私も円の面積を求めたときに、うわっ、一億回もやったのに

x桁ぐらいしかあってへんで。とか思ったような記憶がある。

(何桁ぐらいあってたかは忘れた)

まぁ、どっちにしろ3桁ぐらいはいけてたと思うので

ちゃかちゃか〜と試行回数100万回、1000万回、1億回、

の3バージョンをSubmit。他の問題で大真面目に

rejectを喰らいまくっていたので抵抗感はかなり少なかった。


そんなこんなで、うちのチームはすっかりモンテカルロチームとして

認識されることになってしまった。

その後の問題でもかなり投げやりプログラムで通しちゃったのもあり、

最後の講評で、SubmitしまくってAccept数を

稼ぐやり方は最近はあまりお勧めしない…とか言われてしまった。

はぁああ…私はそんな戦略をとったことは一度もないのにな…

というか、本番でrejectされたことは生まれてこの方一度も無い!

とかなんとか言ってみても仕方がないなぁ。はぁ。


で、合宿の成果としては…

Gokuri-Sqeezeの圧倒的な強さも分かったし、

うちのチームの駄目なところもよく分かった。

(安定結婚アルゴリズムとかウォーシャル・フロイド法ぐらいは、

名前だけじゃなくて、ちゃんと中身も勉強しとこうな!)

結局総合順位は7チーム中4位ということで可も無く不可もなく。

…これからもっと勉強します…。

トラックバック - http://d.hatena.ne.jp/tanakh/20040925

2004年09月24日(金) Haskell使い千夜一夜

頭上に輝くHaskellの文字…

にもかかわらず最近ミステリー話ばかりだったので

ここらで気合を入れてHaskellの記事を。

というか、お返事を…(とても遅くなりましたが)

[]Re:制限された関数だけクラスのインスタンスにする Re:制限された関数だけクラスのインスタンスにするを含むブックマーク Re:制限された関数だけクラスのインスタンスにするのブックマークコメント

うーん。ghcの拡張機能にあるのですか。

instance Manipulator (Handle -> IO a) where
  a << m = do
    h <- a
    m h
    return h

この前の関数インスタンスにしてみる。

なるほど、普通に出来ますね。

[]Re:型を返す関数 Re:型を返す関数を含むブックマーク Re:型を返す関数のブックマークコメント

dependent type …は知らなかったです。

一通りPDFとか読ませていただきました。

そういえば、C++のtemplateにも値をとるものがありましたね。


うーむ…私もまだまだHaskellについて知らないことだらけですね…

精進します。

トラックバック - http://d.hatena.ne.jp/tanakh/20040924

2004年09月23日(木) あいまいな殺人解決編

[]本当にあいまいだった殺人 本当にあいまいだった殺人を含むブックマーク 本当にあいまいだった殺人のブックマークコメント

9/11の日記にてあいまいな殺人なる番組のことを書いたが、

なんというか、そのことがGoogleさま他検索エンジン

ばれてしまった様で、このページが一時かなりの上位に

ランクインしてしまっていた模様。

そのおかげで9/11のリンクはこのページ始まって以来の

すごいことになったのだが、ちゃんと私も解いてましたよ。

5人(あるいは6人)の容疑者中3人も犯人と思しき人物が居る

とのことなので、狂言説か、という線で適当に考えて

まぁ、適当に通したというかなんというか。

襲った犯人だけは最後まであいまいだったような気がする。

ザ・テレビジョンの発売日以降じゃないと分からない問題が

一つあったけど、なんだかけだるかったので一日遅れでSubmit。

タイガー魔法瓶のマスコットで2回間違ったので結局合計95点ということに。

なんか悔しいので、親の携帯電話を使って100点のやつも一応作ってみたり。

しかしまぁ、普通に賞金はもらえなかった。

常識的に考えて送ったのが遅すぎだなぁ。


で、解決編なのだが、私は9/18〜21まで東京の片田舎で

ICPC強化合宿なるものに参加していたので視聴できず。

帰宅後録画したやつを見ることに。


結局DMは女の一画目ということで決着。

遅刻して榊以外の名前を知らなかったので名前はありえない、

被害者は野球を全然知らないので球団のマーク?でもない

(ごめん、私も野球全然知らん)。

まぁ、ここまでは当然として、だからといって榊の最後の台詞、

このメッセージはあいまいなんかじゃありません。

状況を良く思い出すとたった一人の人を見事に指し示していることに気づくはずです。

…のようなことに繋がりはしないと思う。

状況というのが前述の2項だとすると(…というか、そうだけど)、

それだけで、あのDMが女の一画目だと限定することは出来ないのではないのか…

(例えばジャビットと呼ばれていた男の、"し"とか)

結局まだあいまいだと思う。

あと、撮影ミスと思われる箇所が多すぎる。

色々考えて損したかもしれない。

あとはまぁ、解決編で言ってたことは大体分かってたことだったけど、

斧を隠した理由が窓ガラスを割って風を部屋に入れて

半紙を移動させるため…というのはわからなかった。


まぁ、そんなところかなぁ。

次回…があるなら、もうちょっと完成度の高いものを頼みます。

トラックバック - http://d.hatena.ne.jp/tanakh/20040923

2004年09月22日(水) 暗黒館読了

エエ、暗黒館の殺人を読むために、

しばしのお暇をいただいていたわけなのですが、

それもこのたび完了いたしました次第ですので、

ここのところ書き溜めてしまった文章を一つ一つ書いてゆきます。

[]読了です 読了ですを含むブックマーク 読了ですのブックマークコメント

(一応内容に関するネタばれはないつもり)

………

なんかもう時間ばっかりかかった。

確かに無駄に長いわけではないんだろうけど、

私は本を読むのが遅いので、もう少し短いほうがうれしい…。

内容は、ひたすら胡散臭かったなぁ。特に上巻。

その分下巻はほとんど問題の解決に当てられているのだけど…


綾辻氏自身も

この物語はちょっと自分の手には余るのではないか、

あとがきで語られているが、確かにこのアイデア

矛盾なくインプリメントするのはとても大変そうだ。

そうなんだが、プロット自体が…うーむ。(こんなこと書いていいのか)

いや、わたしも

「暗黒館はまだか、まだか、まだか、まだか……」

な人間の一人だったので、その辺もあるのかもしれない。


例によって例のごとく、読み終わってから考えると

上巻のほうに伏線がたくさん張り巡らされていたかも知れないが、

さすがにもう一回読み返す時間がないっぽい。

………

………

………

そういうわけで、まぁ、期待通りとは、あれでしたけど、

それなりに楽しめました。

とにもかくにも、次回作(奇面館になるのか?)期待しています。

そのころには私も40歳ぐらいでしょうか…(おいおい)

合間に安楽椅子探偵でも頼みます。

次こそは50万円を戴きに参上いたしますので…。

トラックバック - http://d.hatena.ne.jp/tanakh/20040922

2004年09月11日(土) ねんがんの アンコクカンをてにいれたぞ!

[]雑記 雑記を含むブックマーク 雑記のブックマークコメント

暗黒館の殺人を手に入れた。

実は昨日のことだけど。

普通にプラッツ近鉄の旭屋書店に行ったら売ってあった。

やっぱり入荷は9月10日だったようである。

ついでに先日の解析魔法少女〜を嫁にもらうことにした。

なぜか「モバイル」の棚にあるので人の出入りが激しい。

人の途切れた一瞬の隙を見切り、さくっと暗黒館(上/下)で挟み込む。

ほとんど強襲であった。

ちなみに「モバイル」の棚には他にもCPUの創り方とかが置いてあった。

ナニをモバイルするのであろうか。


さらにこれだけではレジに出すときに心もとないので

カムフラージュのために大人の科学なる大きな本を追加。

なんかラジオが作れるやつを買うことに。

念には念を、会計は男店員(三人中一人)に割り当てられるタイミング

見計らい敢行。我ながら大変に小心翼翼である。

結局この日は本代に7千円以上使うことになった。

プチ散財?まぁ、いいか。


というわけで、これから暗黒館読みに入ろうと思うのであるが、

新書サイズで上下合計1300頁ほどもあるので、読み終わるのいつになるやら…

[]あいまいな殺人 あいまいな殺人を含むブックマーク あいまいな殺人のブックマークコメント

関西ローカル懸賞金付き推理ドラマ

「あいまいな殺人」なるドラマがあった。

最近めっきり更新していない本体サイト"純粋関数空間"の名前

ネタ元である同じく関西ローカル懸賞金付き推理ドラマ

安楽椅子探偵シリーズで前回、エレガントな解答上位10個に選ばれつつも、

抽選で50万円を逃し結局"UFOの夜"のDVDをもらった経歴の有る私は

(http://www.asahi.co.jp/anraku/f_tosen.html この辺…名探偵賞ですか…)

適当に解いてみるかな〜という具合で挑戦したのだが、

応募が携帯サイトのみ、しかも問題が10問あってそのほとんどがお使い

というのになんというか、疲弊してしまった。

(プリングルスの緑色の味は?とか)

というか、そういうの調べてて全然問題編見れなかったのですが…

[]ソクラテスもどき ソクラテスもどきを含むブックマーク ソクラテスもどきのブックマークコメント

最近M氏との対話からネタというか疑問が生まれることが多い。

お前はソクラテスか、…という人はおらんと思うけど、

今回もHaskellで引っかかったネタを。(毎度勝手に書いてごめん)

氏いはく、


型を返す関数は作りたい。


ということらしい。

range :: Particle -> (何か型)

つまり

range (一次元Particle)
 => Double
range (三次元Particle)
 => Vector3

で、

move :: Particle -> Time -> range Particle
(type Time = Int)

見たいな事がしたいらしい?

(ParticleがTime時間後どこに行くのかを求めるとのこと)

さすがにこんな記法はだめじゃろ…

たんにモノによって関数の返る型を変えたいのであれば

move :: Particle p => p r -> Time -> r

Particleがあらかじめrangeの型を保持しておけば

出来るんじゃないのか?

と提案したところ、まぁ、なんかそんな感じかなぁということで

納得してもらえた?ようである。


ただし、こっちはこっちでParticleの形になんだかいやな制限が

加わったような気がしないでもない。

その後で考えたところ、本気で適当な型を返したければ

Data.TypableのTypeRepが使えるし、

任意の型のデータを返したければ

Data.Dynamicの関数群を使えば出来るような気もする。

でもDynamicって正直どうなの?とも思うし、あまりよくないようにも思う。


よく考えると、そもそもその辺の各Particle固有のデータを外に

出さない設計のほう良いのでないか?

move :: Particle -> Time -> Particle
transform :: Particle -> Coordinate

とか、適当に隠蔽するとか。


うーん…今回はよく分からん文章になった。

というか、自分でもなんだか意味がよく分からない。

あかん、全然真理が導き出せてへんで。

yaneuraoyaneurao 2004/09/12 08:23 そこまでして美咲を嫁に..あ、、ありがとうございますm(_ _)m

tanakhtanakh 2004/09/13 01:18 いえいえ。ではまぁ、しかと読ませていただきます。

トラックバック - http://d.hatena.ne.jp/tanakh/20040911

2004年09月10日(金) 再度、マニピュレータ

[]マニピュレータ マニピュレータを含むブックマーク マニピュレータのブックマークコメント

最初にお断りしておくのだが、今回の文章は

Cマガ2004年9月号(つまり今書店に行ったら売ってあるやつ)の

「επιστημηのオブジェクト工房」の記事をかなり参考にしたので

そちらをお持ちなら先に読んでもらえるとよいかもしれない。

まぁ、話題はiostreamに対するマニピュレータの定義をしやすくする

"マクロ"あるいは"テンプレート"というようなことなのだが、

(こんなこと書いていいんかな…)


で、その一節に

…メカニズム自体は関数オブジェクトにも通じていて

なかなかにプログラマゴコロを刺激するのではないだろうか…云々

ということが記載されていて、

関数オブジェクトもとい、ファーストクラス関数言語では

そんなことは直截的なんだ…といつものごとく考えてみたり、何とかしたり。


ここではマニピュレータとはCマガと同じように、

streamに何らかの作用を及ぼすもの、という意味で用いている。

cout<<endl;

とかのendlとかになるのかな。

そこで問題となるのが自分でマニピュレータを作る場合。

星(アスタリスク)をn個表示するようなマニピュレータ、

cout<<stars(5);

のようなものを作りたいと。


私の第一感ではoperator<<を定義したクラスをつくるのかなあ、

て感じだったのだが、ここは星n個から成る文字列を返す解法が書いてあった。

おそらく、正格性評価を考慮したときの使用スペースの問題を度外視すると

問題をoperator<<(ostream &,string&)に還元する解法のほうが

クラスを定義するよりも遥かに綺麗なやり方だと思う。

Haskellだと遅延評価なのでなおのこと。


そういうことで、文字列をストリームに突っ込むだけのものならば

文字列に還元でいいのではなかろうかと一人納得する中、

話はクラスを定義する方向へ。

ostream &foo(ostream &os,...){
}
OAPP(...) manip(foo);

C++ライブラリにあったiomanipを使えばこのようにostreamに対して

任意の操作を行うことが出来るマニピュレータが作れると。

その実はOAPPマクロがこっそりとクラスを定義しているらしい。


Cマガのほうではその後templateを使ったiomanipの再実装

みたいなことになっていくのだが、ここではHaskellでの実装を

行ってみようかと思う。関数型の考察、あるいはちょっとだけ<<オペレータが

懐かしかったのかもしれない。


まず、<<をどうするか。

<<に突っ込めるものをManipuratorクラスとしよう。

ManipulatorクラスがShowクラスから継承されていればデフォルト

実装が作れるのでそのほうがよいかもしれない。


ということで、定義してみたのが以下のManipulatorクラス

class Show m => Manipulator m where
  (<<) :: IO Handle -> m -> IO Handle
  a << m = do
    h <- a
    hPutStr h (show m)
    return h

何か色々めんどくさかったのでostreamの変わりは単にHandleで。

IOが付いてるのは都合上。付けないとコマンドが実行できないので。

これでShowクラスインスタンスは何でも突っ込めるのだが、

明示的にinstanceしておかないといけないので、

instance Manipulator Int
instance Manipulator Integer
instance Manipulator Double

適当にこのあたりを追加。

Charに対してはshowして欲しくないので

instance Manipulator Char where
  a << m = do
    h <- a
    hPutChar h m
    return h

このような特殊化を施す。

さらに、リストに対して

instance (Manipulator a) => Manipulator [a] where
  a << m = foldl (<<) a m

このようにインスタンスを定義。

これで文字列、整数などは突っ込めるようになった。

また、<<が組み立てるのはIO Handleなコマンドなので、

cout = return stdout

このように定義しておく。

これで、

main = cout<<"Hello, World"<<endl

endl = "\n"

のようなC++チックなことが出来るように。

で、前述のstarsのようなものがどう定義できるのか。


main = cout<<stars 5

のように書いて星が5こ表示されればよい。

私が第一感で浮かばなかった手である文字列への還元、で考えると

stars = flip replicate '*'

これでよい。

例として上がっているclsやlocateも

cls = "\x1b[2J"
locate x y = "\x1b["++show x++";"++show y++"H"

ありゃ、出来ちゃった…

でもまぁ、やっぱりあれなので、

文字列では収まらないとき、バッファのフラッシュとかをするものとかを

作ろうと思うとHandleを触る必要が出てくるので、

そういうのを考えると任意のHandle操作を行うものをマニピュレータに

すると言うのはあながち無駄では無さそうな気もする。


で、そういうものを考えてみると、

まずひとつ浮かぶのが普通にデータ型+インスタンス

という方法。

data Stars = Stars Int deriving (Show)
instance Manipulator Stars where
  a << (Stars n) = do
    h <- a
    replicateM_ n (hPutChar h '*')
    return h

main = cout<<Stars 5

これはC++でoperator<<を定義したクラスを定義するのに極めて近い。

Haskellならでは?…のカリー化を用いた方法も考えられる。

(<<<) :: IO Handle -> (Handle -> IO a) -> IO Handle
a <<< f = do
  h <- a
  f h
  return h

新たに<<<というオペレータを定義し、

それの第二引数としてコマンドを受け取れるようにする。

すると、

starsf n h = replicateM_ n (hPutChar h '*')

星をhにn個表示する…といった普通の関数

main = cout<<<starsf 10

このように使用することが出来るようになる。

この方法は個人的には良いんではないかなぁと思うのだが、

いかんせんオペレータを共通化できなかったのが痛い。

制限された関数だけクラスインスタンスにすることが出来れば

(Handle -> IO a) の関数をManipulatorクラスにすることが出来るのだが、

出来ない…あるいはやり方がわからない。

というか、そもそもHaskellクラスはそういうもんではないのか。

やはりまぁ、よく分からんというか、結局これだけ書いて文字列解が

一番よさげなのはどうしたものか。

トラックバック - http://d.hatena.ne.jp/tanakh/20040910

2004年09月09日(木) マニピュレータ

[]目ヲ合ワセルナ 目ヲ合ワセルナを含むブックマーク 目ヲ合ワセルナのブックマークコメント

このページも徐々に日記化しているような感がある。

前は目立つところに日記じゃないとか何とか書いていたけど、

日記じゃないことを保つのはかなり難しかったようで。


私が14歳のころから刊行を待ち望んでいた

暗黒館の殺人」という本(ISBN:4061823884)が、とうとうというか、

いよいよ、今日(9月9日)発売されるらしい。

でもまぁ、シリーズをリアルタイムで読んだ人よりは多少待った時間は

少ないかもしれない…。


というわけで、買いに行ってみた。近所に本屋はないし、

(ないというか、なくなった。今現在最も近いところで徒歩30分ぐらい)

有ったとしても発売日の入荷はどうなのかなぁという感じなので、

京都まで行くことに。

とりあえずプラッツ近鉄内の旭屋書店を物色。

…ない、ない、あらへんで。

検索したらデータはあるけど棚情報が空みたいな感じ。

入荷がまだなのか〜。相当ショックだ。


せっかく来てこれで帰るのもナンなので、

一部で話題の「解析魔法少女美咲ちゃん マジカル・オープン!」なる本を

探してみた。これ、大学生協で探してもみつからかったので・・・。

でまぁ、普通に見つかったのだが、平積みにしてある上に

そのコーナーにずっと人が居たので立ち読み断念…

さすがに恥ずかしかった。また今度チャレンジします…。


さらに、せっかくきてこれで帰るのもまたナンなので、

京都駅付近のもう一つの大き目の本屋ということで

アバンティ6階の本屋にも行ってみた。

しかし、やはりというかなんというか、売られておらず。

検索してもデータすらなし。現実は厳しい。


で、そんなことはどうでもよくて、本題はこれから。

本屋から帰るときに英語の何か?の勧誘の人と目が合ってしまった。

大失態である。極めて気の弱い私は勧誘をよう断らんのである。

それゆえ、この世には"悪質"な勧誘が氾濫していることを知った

大学生以降は基本的に勧誘の人と目を合わせずに基本的に

無視をするというようなスタンスで対抗していたのだが、

休み期間中なのかなんなのか、こんなときによもやということなのか

今日は気が抜けていたようである。

そういうことで、見事に引っかかってしまった。

8時過ぎから8時40分ぐらいまでなんか話を聞いたのだが、

(こんな夜遅くに非常識ですよ!)

元来英語に全くさっぱり興味がないし、

そもそも英語教育自体にも疑問を抱いている私には

いくら聞かされてもなんともかんともなのだった。

とりあえず被害は名前と住所と携帯電話電話番号で済んだ。

(…ぜんぜん駄目やん)


というわけで、今日は暗黒館は買えないわ勧誘に引っかかるわで

散々な目にあったのだが、私が英語というものをどう考えていたのかは

分かった。国際化社会においては英語は必須?

そんなのは理論的にはおかしい。

国際交流をするにあたりとある国の言葉を暗黙的に使用すること自体が

異常ではないのか。真の国際化は各地の人々が自分の使いたい言語を使いつつ

コミュニケーションをとることが可能になるということではないのか。

私はそれをかなえるのがソフトウェアであると信じている。

つまるところ、地球人全員に英語を教え込みモノカルチャー化を推進するのではなく

任意言語間の翻訳を行うことの出来るデバイスを開発を行うことのほうが理想的であると。

もちろん、現実的にはそういうものは実用レベルでは実現していないので

そういう用途に用いる言語なっちゃっているらしい英語を使う必要があるのだが、

(逆に言うと"英語"を勉強する理由はそのこと以外には"ほとんど"ないだろう)

それを認めてしまうということは明らかに技術的な妥協である。

計算機科学者は機械に出来ることを人間がやってはいけない。

だから私は勧誘を受けても英語塾には行かないのだ…


…とその場で言えたらなぁ…はぁ。

(変人やと思われますですよ)


暗黒館はamazonで調べると9月10日発売??

明日も見に行くか…

[]解析魔法少年tanakhちゃん 解析魔法少年tanakhちゃんを含むブックマーク 解析魔法少年tanakhちゃんのブックマークコメント

立ち読みに行ったけど、周囲の目が気になって立ち読みできなかった

http://yaneu.com/book/misaki/ の本であるが、

クラックしてくれ、なプログラムが置いてあったのでクラックしてみた。

私もこう見えても昔はゲーム画像の復号とかをよくやっていたので

ちょっとした腕試しにはなるかな〜、ということで。

ちなみに愛用の逆アセンブラはwin32dasm…とかいうやつでした。

久々にダウンロードしに行ったらなんかちょっと新しくなってた。


クラックですわ。

crackme01.exe はシリアルを通せ、てなプログラムなのかな。

万が一にも単純文字列コンペアの可能性があるので、

とりあえずバイナリエディタプログラムを覗いてみる。

失敗時のBAD PASSとかの文字列で適当に探すとちかくに

"goodpass"なるものが。まさかとは思いつつ入力してみると、

"送金ありがとうございます"というメッセージが。

これは簡単すぎ。拍子抜け。


crackme02.exeは使用制限日時はずし?

とりあえず逆アセンブルしてエントリポイントから眺めると

GetLocalTimeをして色々判定している部分が。

違ったらMessageBoxを呼ぶほうに飛ばしているので、

判定部分をNOPで塗りつぶし…で普通に起動してしまった。

こちらも簡単すぎ…


というか、意図的に簡単にしてあるんだろうけど、

あんまり遊べなかった。残念。

[]マニピュレータ マニピュレータを含むブックマーク マニピュレータのブックマークコメント

表題に書いたネタだけど、えらく時間がかかってしまったので

やっぱりまた今度に。

yaneuraoyaneurao 2004/09/10 00:58 そう言わず、ぜひ美咲を嫁にもらってやってください(笑)

tanakhtanakh 2004/09/10 17:08 うお、ご本人直々とは…これは買わないわけにはいきませんなぁ。
…ええ、人が居なければ。

トラックバック - http://d.hatena.ne.jp/tanakh/20040909

2004年09月08日(水) 体調が…

どうにも体調がよくないので数日ぼーっとしていたら、

えらく間が空いてしまった。

間が空いてしまったというか、すでに前に書いたネタなんやったかいな〜、

てな具合でどちらかというと頭のほうが心配である。

具体的にはやりたかったゲームをやってみたり、将棋の観戦?をしてみたり。


前回あたりに書いた"Problem H Count the Numbers"とかも

のべ3時間ほど考えたけど効率解を見つけられず。

なんだかとんでもなくめんどくさそうな方法ならぼんやりと

見えるのだが…


まぁ、もう、これでお茶にごし…

length [() | x <- [a..b], any (isPrefixOf (show n)) $ tails (show x)]

[]Re: Re: Functor と Monad Re: Re: Functor と Monadを含むブックマーク Re: Re: Functor と Monadのブックマークコメント

うーむ…効率ですか。

しかし、例えばリストの例だとそんなに問題になるレベルの

差ではないように思います。Maybe、IOも然り…


しかし、やっぱりそのうち圏論も勉強しないといけないなぁ。

[]うんざりするほど優柔不断 うんざりするほど優柔不断を含むブックマーク うんざりするほど優柔不断のブックマークコメント

今、なんというかいつもより多少規模の大きなプログラムを書いている。

というか、すんなり書けていればとうの昔にこのページのネタに

なっている予定だったのだが、つまりまくりなのである。


別に全く困難なものではないのだが、私が優柔不断すぎていけない。

大まかな設計で2択を迫られるともうそれを決めるのにものすごく悩んでしまう。

昔は気力があったのでそれでも最終的にモノを仕上げることが出来たのだが、

今は悩んで悩んでそのうち放置…というパターンが増えてきているような、

そんな感じで。これはどうにかしたいものである。


ということで、今回は実質ネタなし。

次回以降に乞うご期待。

トラックバック - http://d.hatena.ne.jp/tanakh/20040908