正直しんどいのとソートの話

2014年10月1日 TCG全般コメント (2)

日曜日に徳島に行った事は後悔していないが、移動の負荷は考慮するべきだったな。
長時間の電車移動で首と腰へのストレスがマッハ。
今後は移動手段も吟味せねば・・・。

ソートの方は

・カードの出現位置からグループを特定
・後は順番につなげる

って感じのやり方で「別のグループにまたがって出現する」と言うカードが無ければ比較的素直に出来上がらんかなぁとは思うんだけど、環境が旧PCにしかなくってどうしようかなぁと言うところ。
データの並びが知りたいわけだから、データベースに放り込んで「コモンの一番頭にあるカードだけでグループにしろ」とか命令すれば、一番最初のグループ（Aとする）が出来るし、同様にコモンの2番目だけでグループにして、Aのカードを除外すれば2番目のグループ（Bとする）が出来上がる。
今は目算でABCDの4グループがあると思われるわけだけど、仮に組み合わせとしてAを含まないパターンである

BBBBCCCDDD

みたいなパックが存在したとすると、通常は

ABBBCCCDDD
AABBCCCDDD
AAABCCCDDD

みたいな（あくまで例だけど）感じで出現すると思われるのでAのグループが1枚も含まれないBからスタートするパックは確率的に分かる程度には差があるはずなんだ。（Bしか含まれないパック＝Bのカードが先頭になっているパックの数は少なくなる）

逆にBがないパターン

AAAACCCDDD

みたいな奴はもっと分かりやすくて、パックの一番上に来ているグループが頭の4枚までに含まれるかどうかをデータベースに出せと言って出させれば良い。
データの量にもよるけど、この命令で出てこなければAはパックに含まれると思って良いし、そうなればBがパックに含まれるかどうかも分かる。
と言うかこの方法で探してなければ必ずAB共に含まれる事になるのか。
いや。Aだけで前半4枚が構成されているデータはない、かつAが含まれていないパックはないって言う条件がいるから結局はBだけで構成されているパックがないかどうかは調べないかんな。

CDに関しても同様にすれば良い。

この方法の問題は「固有のカードの出現パターンは2つ。同じグループでループする」と言うのが前提になっているのと、特にABのつながりは枚数的に短いから特定するのに大量のパックデータを必要とする事。

仮にABCDでパックが構成されるとすると

ABBBCCCDDD
AABBCCCDDD
AAABCCCDDD

みたいな並びで長くても1枚とか2枚しか分からないわけ。
まぁここら辺は何ともしようが無いんじゃないかなーとは思うんだけど。

・・・としたり顔で書いたけど、こんな単純な話でも抜けとか欠けがあったらご指摘頂ければ幸いだ。

日曜日くらいまでに環境が整えば解析するかも知らん。