State の相互変換について

[n4o847]

19 の続き

状態のタプル・集合を文字列操作することについて、

• 文字列操作では一般に結合は簡単で分解は難しい（構造が入れ子になったときパーサを書かなきゃいけない）
• 対応を持っておく方法では分解は簡単（Map で持って文字列で get すればいい）で結合は難しい（一個一個検索するしかない）

という補完的な性質があるので、これらを組み合わせるのが良い気がします。

構想としては

• いま newStateToOldStateSet とかなってるやつを（もうちょいいい名前に変えて）オートマトンに持たせる。
• 今までの getLeftState など split する操作は使わない
• 今までの HogeBuilder.getState など検索する操作は使わない
• Graphviz 出力時に記号も許容するようにし、タプルは (${leftState}, ${rightState})、集合は {${Array.from(stateSet).sort().join(', ')}} みたいにシリアライズする

という感じです。

[yapatta]

良さげです！枝刈りNFA作成時に実験的に作ってみます

[yapatta]

てかこれならばクラスを独自作成したほうがいいのか

[n4o847]

ちょっとすでにやってみちゃってて、見てもらいたさがあります。

yuziroppe さんがアイデアがあるならそれはそれで気になりますが……

[n4o847]

クラスを独自作成とはどういうことでしょう？

[yapatta]

今構想としているのは(擬似コードですが)

class DirectProductState {
private stateList: [State,State];

getState() {
return stateList;
}

toString() {
return `${Array.from(stateSet).sort().join(', ')}`;
}
}

こんなイメージです 既に作っているなら是非見ます！

[yapatta]

これだけじゃだめでオートマトン内での複数状態を表す処理を今書いていないことに気づいた

[n4o847]

今 redefine_state_2 というブランチで 4d4c0a2d5525f5415730dafef85ad3e2198ca4df までやっているのですが、これをやると DFA 構築がかなりシンプルになったので直積でも楽になるんじゃないかという……（急いでてめっちゃ雑になってしまってすみません）

[yapatta]

なるほどここまで書いてたんですね...すごい DFAの状態を具体的に明示できそうなのすごく助かります

[n4o847]

こんな込み入った型パズルやっていいのかという背徳感が……

状態の集合が（今までの Q\d+ から {q\d+, q\d+, ...} に変わったので）デバッグしやすくなってるのと、今までの _ 方式と共存できるのでどうにでもできる感じではありますが、バシバシ変更が加わる事自体が申し訳なく……

[n4o847]

いま masa5555 さんがIDA、 yuziroppe さんが枝刈り、ぼくが攻撃文字列というタスクを急いでいる現状で、無理にこの変更を加えるのはやばいので、いったん放置しておく、あるいはもっと漸進的に移行するようにする、というのがあります。

[n4o847]

25 と同時に取り込まれたため閉じます。