凪瀬 Blog
Programming SHOT BAR

目次

Blog 利用状況
  • 投稿数 - 260
  • 記事 - 0
  • コメント - 46605
  • トラックバック - 192
ニュース
広告
  • Java開発者募集中
  • 経歴不問
  • 腕に自信のある方
  • 富山市内
  • (株)凪瀬アーキテクツ
アクセサリ
  • あわせて読みたい
凪瀬悠輝(なぎせ ゆうき)
  • Java技術者
  • お茶好き。カクテル好き。
  • 所属は(株)凪瀬アーキテクツ
  • Twitter:@nagise

書庫

日記カテゴリ

 

最近、プログラミング言語の構文解析とかがマイブームです。 私の場合、発想法は主に抽象化による同一視や、あるパラダイムをジャンルを跨いで適用できないか と考えるという、オーソドックスな手法を使っています。

そして、この間の東京勉強会のライブを見ていて、電卓の状態遷移をプログラム言語の構文解析の手法で扱えないかな、と考えたのでした。

電卓をプログラムする際に状態遷移図を用いて状態の遷移を捉えようという趣旨のことが取り上げられています。

一連の操作の流れを構文として捉える

私が思い浮かべたのは、時系列をいったん置いておいたとして、電卓のボタンの押下順序を並べると、 ひとつのプログラミング言語的なものになるのではないか、という考えです。

たとえば1+1を計算する際のボタンの一連の操作は

[1] [+] [1] [=]

というものですが、これを解析して演算ロジックを生成するコンパイラ、あるいは、 これを解析して演算を行うインタープリタを想定します。

そうすることで、通常の演算のほかに、逆ポーランド記法といった記法へも切り替えることが出来る、 一段抽象的な作りの電卓が作れるのではないか…

応用

連続操作を解析して何かを行うという類のものには適用できるように思えます。たとえば

  • 格闘ゲームなどのコマンド入力判定
  • マウスジェスチャーの入力判定

といったもの。

とりあえず、今日は妄想だけ放出ということで。

投稿日時 : 2008年3月17日 22:19
コメント
  • # re: 電卓の話で妄想したこと
    melt
    Posted @ 2008/03/18 1:15
    格ゲーは状態遷移の管理さえ出来ればほとんど終わりという話を聞いたことがあります。
    状態遷移をまともに考えられない人は、多分あちこちフラグ立てまくって管理できなくなるんじゃないかと。
    というか最近そんなプログラムを眺めてます。フラグテクノロジー恐るべしです。
  • # re: 電卓の話で妄想したこと
    myugaru
    Posted @ 2008/03/18 2:19
    学ぶところが多いです。
    myugaruよメモだメモるのだ!
    φ(´・ω・`)メモメモ 、.,φ(´・ω・`)ポキッ 、.,φ(´・ω・`)・・・。
  • # re: 電卓の話で妄想したこと
    よねけん
    Posted @ 2008/03/18 10:43
    こんにちは。妄想します。

    >一連の操作

    この説明部分を読んで、NetworkStream(.NETです)っぽいなと思いました。つまり、SeekできないStreamとして入力を実装すると面白そう。(ここでの例なら別にSeekできていいですね)

  • # re: 電卓の話で妄想したこと
    凪瀬
    Posted @ 2008/03/18 11:32
    立ち・しゃがみ・ジャンプ・ダウンなどの状態や、必殺技の状態をどのように遷移させるか、
    そして、硬直を飛ばして遷移させていわゆる「キャンセル」を行わせるか、といったところでしょうか。

    一連の操作を扱うためにはキューに操作情報を格納する必要があります。
    NetworkStreamクラスの挙動は知らないのですが、一般的にStreamと呼ばれるものは
    同じ部分のデータを繰り返し読み込むことはできないような…?

    なお、キューに格納する情報はGoFのCommandパターンを用いるとよいかもしれません。
  • # re: 電卓の話で妄想したこと
    スーパーあんどちん
    Posted @ 2008/03/18 19:48
    ローマ字入力解析なんかも入りますよね。

    格闘ゲームのコマンド入力なんて場合は、対応する入力データをツリーで事前に持っておけば、キューにためなくてもいけそうな気がします。
    # ツリーは勿論入力可能なキー・方向の枝を持つ

    コマンド確定、入力ミス共にツリーの終端まで行くわけで、そこで判定可能と思います。
  • # re: 電卓の話で妄想したこと
    凪瀬
    Posted @ 2008/03/19 11:18
    それって構文解析木をあらかじめ想定できる分だけ用意しておくという事では。
    メモリ消費量も考慮しないといけないけど、ケースが少ないなら速いと思いますよ。
  • # re: 電卓の話で妄想したこと
    スーパーあんどちん
    Posted @ 2008/03/19 15:35
    ご指摘のとおり、想定しうるケース分ツリーデータが必要になります。とは言えコマンド末端以降は枝が増えることも無い木ですけどね。
    # つまり安定した木にはならない。
    でも、キューでも同様に想定しうるだけの判定処理or判定データは必要になりませんか?
    僕は速度よりもコード量が少なく済むので木構造ってのを出してみました。
    また、木構造であればコマンドを変えたときにコードの修正が不要になります。(理想ですが)

    格闘ゲームの場合コマンド判定開始時の状態で木が決定し、コマンド入力完了(含失敗&キャンセル)までの間で状態が変わることも無いでしょうし。
  • # 状態遷移と動作遷移
    いや、まだだから
    Posted @ 2008/03/20 15:16
    状態遷移と動作遷移
  • # re: 電卓の話で妄想したこと
    凪瀬
    Posted @ 2008/03/20 20:18
    キューということがポイントなのではなくて、キューにたまった一連の操作を
    解釈するインタープリタがポイントなので。

    でも、木構造でやるなら気を作るFactoryの実装を切り替えれば処理を変えれるし
    インタープリタを挿しかえるのも変更耐性は変わらないか。
    ある程度の規模までは木の方が小さくて済みそう。
タイトル
名前
Url
コメント