※麻雀ロジック研究会※
■ このスレッドは過去ログ倉庫に格納されています
麻雀のロジックについて研究しませんか?
麻雀ゲームなんかで強いCPUキャラクターとやると
どうしてもプログラムの方で積み込んでいるとしか思えません。
人間の思考に近づくロジックを話し合いませんか? すまん、やっぱりあるね。
自分の脳内トレーサじゃ >>24しか思い浮かばないや・・・ >>24
あまり変数はいじってないんですけどね。
return の前に悪いやりかただろうけど大域変数のflagを使ってるだけで・・・
この人麻雀研究で有名だし、やっぱり漏れが悪いんだろうなあ。 その関数は悪くないと思うよ。
どんな使いかたしてるの?
見てあげるからソース貼ってみそ。 http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/212.txt
クソコーディングすまそ。
最初、イーシャンテンでテンパイまでの受け入れ枚数を数えるプログラムを
作ってみようと思ったんですけど(鳴き、チートイ、国士はまだ)
どうもagari_checkのところで何かおかしなことになってるっぽいんです。 そのままコンパイルして実行してみたけど、問題無かったよ。
この状態でスタックオーバーフローになるの? スタックオーバーフローは、恐らくなんですが・・・
VC++6のデバックモードだと、きちんと表示されるんですが
リリースモードと、BCCでは、最後のprintfが表示されないんです。
何が原因なのかなあ。 >>29
tehai[43]で面子を作ろうとして無限ループ(再帰)してるな。
この関数はtehai[43]==0を前提にしているらしい。
tehaiの定義を 1増やして、
int tehai[44]=
{0, 0, 3, 0, 0, 0, 0, 0, 0, 0, //0-9
0, 0, 0, 1, 1, 1, 0, 0, 0, 0, //10-19
0, 2, 1, 1, 1, 1, 1, 1, 0, 0, //20-29
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, //30-39
0, 0, 0, 0}; //40-43
で、うまくいくかも。 >>32
おお、最後きちんと表示されるようになりました。
まだおかしなところがあるかもしれませんが、とりあえず前進しました。
ありがとうございますm(__)m
そんなに数無いんだし自分で作れば?
漢字フォント作るより楽だと思うよ。
上がり得点/期待値が最も高い手になるようプログラムすればいいじゃん。
統計的には確実に強い打ち方になるぞ >>16
対戦させられるような仕組みは、
>>7の「MJSim」、>>19の「まうじゃん」というところか・・・
で、作っている人いるの?
あがり判定とか役判定ってどうやんの?
それだけで結構難しくない? 麻雀のルールって、増築に増築を重ねた「九龍城」みたいなものだからな・・・
実際にさまざまなルールを統合してプログラムを作成しようとすると、
あちらこちらに矛盾点が出てくるんだよね。
実際にゲームをしている時には殆ど発生しない
レアなケースでのみ起こる矛盾点もプログラムにする以上、
ちゃんと解決しなくちゃいけないし。
例えば、「完全先付け」とかさ・・・
あれ考えた奴、脳みそのネジが5,6本、抜け落ちているんじゃないのか?
麻雀に関してのプログラムの書いてある本
何でもいいので教えてください んとね、テクノポリスに書いてあった。
探すのめんどいから何号かは知らん。 >>46
ゲームプログラミング
『遊びのレシピ』
ttp://www.cmagazine.jp/books/recipe/ >>1
そもそも上がり、いやテンパイにまで持って行けるの?
と言ってみるテスト >>44
>例えば、「完全先付け」とかさ・・・
>あれ考えた奴、脳みそのネジが5,6本、抜け落ちているんじゃないのか?
タコ麻雀対策だろ。
麻雀格闘倶楽部やってるとたまに後付で勝つウザイ香具師が多い >>51
いや、俺が思うに、多分あのルールは
筋者の方々が素人さん相手に勝負をする時に
散々難癖を付けて、カネを搾り取るためのものだと思う。
その理由は・・・
1.ルールの出自が関西であり、今も関西でしか行われていない
2.「完全先付け」には様々なパターンと、それに対する様々な解釈があり、
それら全てをゲームの前に確認しておくのは不可能
3.その後のゲーム中で、事前に確認が取れなかったケースが
発生した場合、間違いなく腕力の強い奴の主張がまかりとおる
まぁ、そんな深読みをしなくても、実際にプログラミングをしてみれば
すぐ分かる。
「完全先付け」がどれほどトチ狂ったルールであるかが・・・
「完全先付け」というルールの存在自体を無視することをお奨めする 麻雀AIのロジック。
ツモ麻雀できるロジックを示しす漏れが来ましたよ。
A.総当り式
1、牌を積もる。
・上がっているーー>「ツモ!」
・上がってないーー>2、へ
2.捨てられるパイを仮捨てしてみる(捨てられる牌数分のパターンあり)
・積もる牌がまだ有るかーー>3、へ
・もう可能性ツモがないときは、
_・上がりリストから最良のデータを使い捨て牌を決定し捨てる−−>1,へ
_・上がりリストがない時は、牌評価数値表からいらないのを捨てる。
3、つもり可能性のある牌をつもってみる。(積もれる可能性分のパターンあり)
・上がりかーー>4、へ
・上がらないーー>2、へ
4.上がり評価
待牌の確立と点数の期待値を計算する。上がりリストに登録。
・次の可能性ツモ牌が有る時はーー>3、へ
興味があったらageみて。 ほい、
BOOL 上がり判定(int 手牌[])
{
if(国士か(手牌)) { return TRUE; }
if(チイトイか(手牌)) { return TRUE; }
for (int i = 0; i < 34; i++) {
if (手牌[i] >= 2) {
手牌[i] -= 2;
if (面子確認(手牌)) {
手牌[i] += 2;
return TRUE;
}
手牌[i] += 2;
}
}
return FALSE;
}
3つの関数は自分で考えろ。
聞くだけなら、もう何も出ない。 役判定のソース
ttp://software.nikkeibp.co.jp/software/download/down04c.html >>56
お〜い、それじゃフリテンと複数の可能性を考えられないぞ〜 みんなで麻雀の思考ルーチンを作って、東風荘とかで対決してみたいなあ。
東風荘の画面から牌の情報を読み取ったりするライブラリは >>23のHPで公開されているから、
純粋な思考ルーチンの部分を作るだけでいいし。
age >>57
麻雀のソースずっと探してたんだ、ありがとう 「振らない」というのはロジックにどう組み込みますか?
というか、捨て牌から手役の高さと待ちを読むロジックは
あまり研究されてない分野と思う マージャンはルールが不明な部分が多いんだよな。
カンが四つで流れるってルールとスーカンツは両立しないけど、どうなってるんだとか。
・一人でカンを四つの場合は流れない
・カンを四つした時点でスーカンツができてなかったら流れる
・その他
とか、いろいろ考えられるけど、本屋に売ってるマージャンの本なんかには
載ってないし。
(なんとか協会とかのルールには決められてるんだろうけど) >>64
仕様(ルール)の振れ幅は決まってるんだから、たいした問題ではないだろう >>62
真面目に組むんだったら、捨牌戦略は割と簡単に組める
・裏筋チェック
・壁チェック
・自分の手牌と場に出た牌の数え上げ
・染め手系のチェック
・序盤の中張牌(変則待ち)チェック
・・・といろいろあるが、はっきり言って、上の3つ程度を行えば十分だし、
それ以上やったら、かえって弱くなる傾向がある。
(変則待ちや染め手を警戒するあまり、棒テンにぶち当たる)
本当はプレイヤーの待ち牌をチェックして出さないことだが、それはあくまでも反則ということで。
あと、日本プロ麻雀連盟の公式ルール(抜粋)
ttp://www.ma-jan.or.jp/rule.htm
あと、スーカンツは1人で4つのカンをした場合に成立し、その場合5つめのカンの発声および牌の提示とともに流局となる。
それ以外の場合は、全て4つめのカンが成立した時点で流れとなる。
カンの成立は、カンをした人が、リンシャン牌をツモり、手牌の中から不要な牌を打牌した瞬間。
(カンドラありのルールの場合、チャンカン時にはカンを行った人の打牌が行われていないため、新ドラが成立しない) >>66
手役の高さを推測し、期待値計算して自分の手の期待値と比較して
相手のノミ手より自分のとびまんを優先して 危険牌でも打つ みたいな
そういうロジックを組みたいよな
あと、当然ネットワーク対戦等の 神(サーバ)があり 打ち手(クライアント)
があるという構成での最強を目指したいよな >>68
実は色々やっているんだが、実は「リーチ一発・裏ドラあり」というルールや、
「カンドラ・カンウラあり」とか「赤五ピン・赤五ソーあり」とか
「ウラドラチップ制」などの、祝儀たくさんのインフレ麻雀になればなるほど・・・
(1)自分から見える情報だけで、もっとも待ち牌がたくさんある面子選択を面前で行う。
(2)字牌を除き9-10枚以上同種牌が無いとチンイツに行かない。(ホンイツは想定外)
(3)聴牌はもっとも残り枚数が多い形(たいていはリャンメン待ちかその変形)
を選択し、リーチを必ずかける(裏ドラが乗るため)
(4)相手のリーチはこちらが2シャンテンより遅い場合は全て無視
・・・という棒テン・即リー・タコツッパリ君AIが強かったりする。
逆に一発ウラドラなしルールだと、AIのウエイト変数を工夫した、
敵側の捨てパイ読み部分のプログラムの作成が楽しくなるのだが。
また同じAIを使っても、棒テン即リー君ばかりのAIx4人の相互対戦の場合とか、
染め屋さんAIが一人入るとか、なんちゃって鳴きの竜AIが入ってくるか、
・・・またそのAIがどこに座るかによって、対戦結果が有意(5%以上)違ってくるので、面白い。
まだまだ研究途上だけどね。 >>61
Javaでいいなら、ここでダウンロードできるよ。
tp://www5e.biglobe.ne.jp/~tatano/index.html >>70
おお、ありがとう。思考以前に麻雀動かすだけで四苦八苦ですわ >>68
点差の問題や残り牌の問題もあるので相当難しくなりそう。
>>69
麻雀格闘倶楽部ではライフ制の香具師がライフ切れ落ちすると次局からCPUになるが
そのCPUの下家は圧倒的に有利w おまいら教えてください
最強の麻雀ロジックを作るため研究を始めました。
まずポンチーカンロンなし、役もなしですべてのプレイヤーがひたすら上がりに向かうという
シミュレーションを行っているのですが、この状況で誰かが上がる確率が50%にしかなりません。
麻雀そのものにそれほど詳しくないのでこれが妥当なのかよくわからんです
次に今のアルゴリズムを書きます >>73
一枚引いて14枚になったら・・・
IF 聴牌
return どの牌を捨てたら一番待ちが多くなるか()
FOREACH hai IN 手牌
仮想手牌 = 手牌からhaiを取り除く
評価(仮想手牌)
return 一番評価の高かったhai
>>74
評価関数は・・・
評価(牌の配列)
int SCORE
WHILE 順子 がある
配列から取り除いて、SCOREに順子値をプラス
WHILE 刻子 がある
配列から取り除いて、SCOREに刻子値をプラス
WHILE 両面 がある
配列から取り除いて、SCOREに両面値をプラス
・・・
という感じで重要な構成要素から点をつけています。
この両面値などを適当に調整しているのですが、この方法ではパラメータがプログラマの
マージャンの知識に依存してしまうし、仮定のような簡単な状況(役なしなど)でなくなった
場合に応用が利きません。
なにかよい方法はないでしょうか? >>73
>ポンチーカンロンなし、役もなしですべてのプレイヤーがひたすら上がりに向かう
という状況なら
>誰かが上がる確率が50%
そんなもんだろ
>>75
>この方法ではパラメータがプログラマのマージャンの知識に依存してしまうし、
>仮定のような簡単な状況(役なしなど)でなくなった場合に応用が利きません。
詰め将棋のように今の手配から上がるまでを総当りで調べる
>>76
>詰め将棋のように今の手配から上がるまでを総当りで調べる
これをやってしまうと10000回とかのシミュレーションが行えず(時間がかかりすぎるため)
悩んでいます。
しかし50%が妥当なのであれば、そろそろ次のステップに行こうかと思います
・ロンできるようにする
・捨て牌を見る
・役判定をいれる
くらいからはじめようかなと思っています 枝狩り。理想は総当りだが、実際には時間に合わせて読むようにする
それか、数牌だけとか抽象化したモデルで先にデータベース化(定跡)するとか
さらに、こちらの番やアニメーション+音声の再生時に読むとか
これが難しいなら、積み込みや手牌透視ができるインチキ対戦CPUを作る
>>78
それだととんぷうそうで勝てないんだよね・・・ コンピュータ対戦も可能なネット麻雀を作ったら面白いな。
対戦相手はランダムな選出だけど、運良く二人以上が選ばれたら
通しもしていいというルールで。
まあ同一IPからの接続は二人まで、と縛っとけば
CATV以外の人はそう困らんでしょう。
山に対する仕掛けが出来なければそれなりにフェアだし。 >>78
手牌透視とかはアーケードの某ネット対戦麻雀でも大々的にやってるらしいな
315 名前:焼き鳥名無しさん[sage] 投稿日:2005/09/07(水) 03:54:12 ID:???
金突っ込まないと上がれないようにする。これ当然の話。
MJは知らないが、以前組んだオンラインマージャンシステムだと・・・
まずは、リーチをかけようがポンしてもチーしてもツモ牌は変わらないようにする。
すなわち配牌グループ13枚x4,ツモグループ17枚x4程度を事前に作る。
投入資金をパラメータ化しておき、高額支払い者が比較的有利になるように
乱数を使って、ほどほどに偏りのある有利度補正値を適宜決定する。
有利度補正値によって、配牌グループでは、(1)(2)(3)(4),ツモグループでは(1),(2)を作る。
(1)中張牌の出現頻度を10,20,30,40%多いグループを作る
(2)特定の柄(ピンズ、ソーズ、マンズ)が10,20,30,40%多い割合で選択されるグループを作る。
(3)場風と字風と三元牌を2枚もしくは3枚含むグループを作る
(4)ドラ牌を2枚もしくは3枚含むグループを作る。
なお、何も補正を加えなくてもいい場合は、完全ランダムで牌を選ぶ。
テストプレイでは、中張牌が20%程度多い配牌で、同様のツモグループにするだけで、
飛躍的に得点が伸びるし、リーチ一発も多くなる。
しかも、一見して細工しているのがわからない。
役満(三元牌を5枚以上積み込む)などの露骨な細工は、(露骨過ぎるので)あまりしないでほしいといわれた。
(ただ一色手方向の補正が大きくなると、大車輪・九連宝灯・緑一色などの出現頻度が高くなる...四暗刻も増える)
AI同士を対戦させるプログラムを作ってみようかなあ。
し よ う
基本は、>>7のMJSimと同じ。
・AI同士のみの対戦。
・東風荘ルール。
・東風荘のログを出す。
・AIは、.netで作る。作るの楽だし、開発環境無料だし。
・勝敗は、東風戦200回以上の合計得点で決める。
・「勝敗」にほとんど関係のない(めったに現れない)ルールは無しにする(役満、チャンカンなど)。
MJSimは、AIに「普通の麻雀」をさせようとして作るのが難しくなっている気がする。
麻雀のルールを、AIが作りやすい形に変えてしまえばいいのではないか。
まあ、できるかどうかわからん。
1ヶ月たって音沙汰が無ければ頓挫したと思ってくれ。 東風荘の代打プログラムを作って、100試合ほど打たせてみた。
安定Rが1100しかなかった(´・ω・`)
実装した機能は以下の通り。
・普段は単純に聴牌一直線。具体的には、シャンテン数を落とさずに
受け入れが広くなるように切る。ドラおよびドラ付近は評価を高めに。
・鳴きは役牌のみ。
・残り山枚数が20枚以下になると、形式聴牌を取りにいく。
・相手から先制リーチが入ると、現物→字牌→筋の順でベタオリ。 >>97
そうかなあ。
ベタオリ機能を実装してから、成績がだいぶ安定したから
必須機能だと思ってたけど・・・ ベタオリする条件を先制リーチと別に、もういくつか設定してみたらどう?
たとえば残り山数が少なく、シャンテン数が高いとか
切れる牌が危険牌だらけとか上がれそうもなかったら、ベタオリ。
まだ、山数が十分あるとか、シャンテン数が低いとか、切れる牌の危険度が
低かったら続行するとか。
>>96からさらに100試合ほど打たせてみた。
すると、その100試合の安定Rが1650で、
>>96の100試合と合わせた計200試合の安定Rが1450に。
まだまだ試合数が少ないから断言はできないけど、
今までは運が悪すぎたのかなあ。
とりあえずは旧上ランの入り口である、R1600を目指して
がんばります(`・ω・´) 勝ちが安定しないって、ようは運任せで、アルゴリズム関係なしなんでは?
シャンテン数が高いときはベタオリにして、
それ以外のときは
ゆるくオリるような打ち方がいいんではないかと。
つまり、現物、字牌、筋、
リーチ者が序盤に切った牌の周りなどを
安全そうな牌としといて、
安全そうな牌かつシャンテン数を落とさない牌を打つようにする。
さらに精密にやるなら安全度を点数化するといいかも。 やっぱりベタオリは改善の余地があると思う。
勝ってるときはベタオリ、負けてるときは、続行とか。
あとは鳴きが役牌のみってところかな?
チンイツとかホンイツとかトイトイとか、いくつかの役に対して、シャンテン数計算して、
いくつ以下ならその手を目指してチーポンを積極的に行うとかはどうだろうか。
みなさんレスありがとうございます。
平日は忙しい上に、PCがつかえない環境にいるため、
返事ができなくてすみません。
ところで、他にも東風で代打プログラムを
動かしてみたいという方はいらっしゃいませんか?
もし、代打プログラムを作ってみたいが、とつげき東北さんが配布されている
MJexeIO.dllを使ってもスキルが足らずに作成できない・めんどくさいという方が
おられましたら、僕が作成したプログラムでよければ公開させていただきます。
今のところ搭載している機能・特徴は以下のとおりです。
1.とつげき東北さんが配布されているMJexeIO.dllに皮をかぶせて使いやすくしています。
具体的には、
○画面から情報を取得する関数を自作の関数の中で適切によびだしているため、
プログラマ自身が画面から情報を取得する関数を呼び出すタイミングに頭を悩ませる必要はありません。
画面から取得された情報は、自作の構造体(手牌構造体やプレイヤー構造体など)に格納されます。
○自分の順番が回って来た時にどの牌を切るかを返す関数、チーやポンをするかどうか尋ねられた時に
鳴くかどうかを決定する関数のみを実装すれば、自分の思い通りに動く代打プログラムが作れます。
2.一度起動すれば、プログラムを終了するか、東風が回線落ちするまで、延々と打ち続ける機能を搭載しています。
3.自分の手牌のシャンテンを計算する機能、場に見えている牌の枚数を数える機能、有効牌を計算する機能
(ここでいう有効牌とは、自分の手牌のシャンテン数を下げる牌を意味します)、4人の捨て牌を時間順に並べる機能
(この機能により、MJexeIO.dllのSimulateOrder関数に付きまとっていた、切られた牌の順序決定不可能性の問題
を回避できます)など、代打プログラムを作成する上で、必要と思われる機能を搭載しています。
(時間があれば、自分の手牌の役を認識する機能を搭載する予定です。)
4.僕自身はプログラミングを趣味としているただの学生ですので、スキル的な問題により、ソースコードは汚いですし、
上記機能の処理速度も速くはありません。デバッグは十分に繰り返したつもりですが、バグがないことを保障できません。 >>104
興味あり。公開してほしいな。
まあ、俺は代打プログラムを作れるような頭は持ち合わせていないが。 うちは、代打ちじゃなくて全部オリジナルで作ってるんで、
プログラム自体は必要ないけど、アルゴリズムとか、
どんなことをやってるかソース中にコメントとかあれば見てみたい。
作ってるのはエロゲなんで、強い思考ルーチンはいらないんだけど。
しかし、こんなにいるんや。
こんなこと考える人!
やっぱ、パラメタ、重みつけ。
あと、ひたすら統計になるんかなー? 統計取るなら聴牌思考の指向性についても考えたほうがいいんじゃないかな
具体的には棒聴即リールーチンと期待値計算して遠回りしても高い手を和了るルーチンのどちらが強いか
ってのを東風かなにかで実戦に投入しながら統計をとるってことで
でも、麻雀の統計として具体的に何局ほどサンプルをとればいいんだろうか…
20万局ぐらい? >>100からさらに改良を加えて、200試合ほど打たせてみたところ、
安定Rが1600付近まで上昇しました。
特に、好調だった80試合を見ると、安定Rが1900強に。
改良点は以下のとおり。
<聴牌に向かっているとき>
今まで:面子手のみ。
↓
改良版:チートイツも組み込んだ。
<ベタオリ時>
今まで:2人が同時に攻めてきた場合、自分から反時計に見て
近い方しか警戒していなかった。
↓
改良版:他家それぞれに警戒係数という指標を導入し、
複数他家の攻撃にも正確にベタオリできるようにした。
<状況判断>
今まで:他家からリーチがかかったときのみベタオリ
↓
改良版:他家のリーチだけでなく、食い仕掛けにも対応。
また、自分の手がよければ、先制されても攻めるようにした。
<牌効率>
今まで:シャンテン数を下げない牌を一枚切る。
その際に、内側の牌・ドラ・ドラソバに高評価を与えていた。
改良版:一打一打ごとにモンテカルロシミュレーションを行い、もっとも手牌のあがりへの
寄与が低い牌を切るようにした。 カルネージハート(或いは、FF12のカンビット)のように
みんながアルゴリズムを組みやすいアプリケーションがあればいいと思った。
麻雀がうまくてもプログラムなんて組めないって人多いだろうし。 麻雀は、カルネージと違って、サブサンプション的にどうこうするってものでないからな
アルゴリズムというよりむしろ統計処理か
まあ、パネルプログラミング的なインターフェイスはあったら面白いかも >>109
研究用にソース欲しいんですけどオープンソースですか? >>112
僕のしょぼいソースでよければ公開させて頂きますよ。
言語はCです。
ただ、あくまで東風代打ツールとして作ってるんで、
研究用には使えないかと思います。
>>104で書いたんですけど、反応が薄かったんで、放置してました(笑) >>113
ありがとうございます。
リアルでも使える代打ちプログラムを作りたいと思ってるので助かります。 >>115
いろいろ改良を重ねているうちに、ソースが汚くなってきたので、
ちょっと整理に時間がかかるかと思います。
明日の夜には間に合うと思いますので、
申し訳ありませんが、それまでお待ちください。 そんなことより、ちょいと聞いてくれよ、>>1よ。
昨日、あるホテルで高島易断の鑑定会やったんです。鑑定会。
そしたらなんか人がめちゃくちゃ少なくガラガラなんです。
で、よく見たらなんか貧乏臭い客がいて、「運勢鑑定3000円ですよね」、とかほざいてるんです。
もうね、アホかと。馬鹿かと。
お前らな、運勢鑑定如きで普段来てない高島易断に来てんじゃねーよ、ボケが。
御祈祷だよ、御祈祷。
なんか親子連れとかもいるし。一家4人で高島易断か。おめでてーな。
よーしパパ運勢鑑定頼んじゃうぞー、とか言ってるの。もう見てらんない。
お前らな、3000円やるから帰ってくれと。
高島易断ってのはな、もっと金持ちが来るべきなんだよ。
テーブルの向かいに座った奴に因縁話吹っかけてもおかしくない、
乗せるか逃げられるか、そんな雰囲気がいいんじゃねーか。女子供は、すっこんでろ。
で、やっと別の客が来たと思ったら、そのうちの一人がまた、3000円ですよね、とか言ってるんです。
そこでまたぶち切れですよ。
あのな、3000円の鑑定なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、3000円の、だ。
お前は本当に3000円の鑑定を受けに来たのかと問いたい。問い詰めたい。小1時間問い詰めたい。
お前、3000円の鑑定って言いたいだけちゃうんかと。
高島易者の俺から言わせてもらえば今、高島易者の間での最新流行はやっぱり、
年間36万円の因縁切りの御祈祷、これだね。
2年分72万円。これが通の頼み方。
御祈祷ってのは金がまとまって入る。そん代わり手間が掛からない。これ。
で、それに1年分100万円の特別祈祷。これ最強。
しかしこれを勧めるとと次からカモ(客)に警戒されるという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前ら貧乏人は、近所の神社でオミクジでも引いてなさいってこった。
高島易断について■part3
http://hobby8.2ch.net/test/read.cgi/uranai/1155287091/l50 風邪のため作業が捗らず、遅くなりましたが、
東風荘代打プログラムのソースコードです。
http://kasamatu.o0o0.jp/pochi/src/hajime7610.zip.html
受信パス:hebo_vip
解凍パス:hebohebo_vip すいません、バグがあったので、修正をお願いします。
strategy.cppの176行目、SelectDiscardTile_SevenPairsOriented関数の
最初の変数宣言部で、max_effective_tile_number = DBL_MAX; と
なっているところを、 max_effective_tile_number = DBL_MIN; に修正して下さい。
なお、本プログラムの成績は下図をご参照下さい。
http://kasamatusan.sakura.ne.jp/cgi-bin2/src/ichi67644.jpg >>121
難しい分野だから仕方ないね。
俺も面白そうと思ってやろうとしたけど、すぐに(数学的な?)壁にあたってしまった。
面白そうではあるけど、敷居が高いねえ。 >>123
現時点の僕のプログラムは安定Rが1600程度ですが、
まだ高校数学以上の数学は一切用いてないです。
数学よりも、バックトラッキングや再帰関数といった
プログラミングの知識の方がはるかに重要じゃないかと思います。
もちろん、強いプログラムにしていく過程で数学の壁にあたることに
なるとは思いますが、ひとまず動かしてみて、思考ルーチン部分の
パラメータをいじるなどして感覚をつかめばソースコードの理解も
早まるんじゃないかと思います。
ちなみに、前からの課題であった役認識・点数計算プログラムを実装しました。
次はこのプログラムをいかに思考ルーチンに組み込むかが課題です。
このプログラムによって期待値の概念を思考ルーチンに導入することが
可能になるので、上手に組み込めば飛躍的に強くなるんじゃないかと期待してます。 >>123
高校数学すらおぼつかないので・・・
また、うぷしてもらったソースを理解して改造していくのは難しそうだし、悪いけどそれはあまり楽しそうでない。
まずは、もっと単純なところから、
例えば、1人麻雀でテンパイに向かうだけのプログラムとかからはじめようかと思う。
車輪の再発明って言われるかもしれないが、この場合はプログラミング自体が「遊び」なので。
みんながスーパーマリオの1面をプレイするように、みんなが通っていいかなと。
その後で、参考にさせてもらうとおもう。 今日初めてここ着たけど、とりあえずソース読ませてもらったよー
別の麻雀ソフトでも対応できるようにデータ取得部分と思考部分が分離されてると思ってたから、
あんまり分離されてなさそうなのが意外だったかも。
ぶっちゃけデータ取得部を流用させてもらおうと思ってたから残念
ちなみに、正直Cで変数いじりしかまともにできない俺にはいまいちわからんw
もうしばらくしたらAI作りはじめられると思うからその時はよろしくっ やっと修論を書き終えることができました!
三徹の影響で頭がぼーっとしているため、日本語が変かもしれませんが、ご容赦くださいw
>>124
確かに趣味で行う以上は「楽しさ」が最優先ですもんね。
僕も作る作業自体が楽しいので、車輪の再発明だらけです。
実際、MJexeIO.exeで提供されている機能以外は全部一から実装しましたし。
>>117でソースを公開した後、シャンテン数計算のルーチンを改良したのですが、
その結果、今までの5倍くらい計算時間を短縮することができ、
あらのHPやcomjong.comで紹介されているアルゴリズムよりも高速化することができました。
こういう些細なことでも進歩が見られると楽しいものです。
>>125
こちらこそよろしくです!
データ取得部は関数単位で分けてあるので、ある程度分離されてはいると思うのですが・・・
少なくとも、データ取得部と思考部がごちゃまぜになっているということはないはずです。
まあ正直な話、僕自身も変数いじりくらいしかできないので、そこら辺のことはよく分からないんですけどね(笑)
もう少し具体的に意見を頂ければ、修正もできるかと思います。 ■ このスレッドは過去ログ倉庫に格納されています