1

従来の if > then 疑似コードの関係:

if (x>y) {
then print "x is greater than y."

}

リレーショナル データベースもあります。

または単に視覚的な if>then テーブル。視覚的なテーブル表現。

ツリーまたは階層構造の if>then プログラミング支援もあります。

if>then 構造のありとあらゆる代替案とフレーバーを探していますが、できれば実用的なものを探しています。ほとんどの人は、シンボリック構造よりも視覚構造 (表と生のコード) を使用して覚える方が優れているため、if>then ルール エンジンをグラフィカルに理論的に構築する最も直感的な方法を探しています。

注: これを実装しようとしているわけではありません。理論的に何ができるかを理解しようとしているだけです。

4

2 に答える 2

0

質問を正しく解釈したことを願っています。

すべては最終的には比較に帰着します。これらの比較を、人間にとって扱いやすいチャンクに分割するだけの問題です。if-then を減らしたり、少なくとも理解しやすいものに変換したりするテクニックはたくさんあります。

その一例がポリモーフィズムです。これにより、プログラマーは if/then (基本的には switch ステートメント) の 1 つのインスタンスから解放されます。別の例は地図です。マップの実装では if/then を使用しますが、マップにすべてのデータを事前に入力し、if/then を使用する代わりに 1 つの論理コードを使用して区別する場合があります。これは、データ駆動型のアプローチに移行します。もう 1 つの例は SQL です。条件と制約を異なる方法で表現できるようにするのは、単なる言語であり、より高いレベルの構成要素です。これらの条件をどのように表現するかは、問題のドメインによって異なります。従来の手続き型プログラミングでうまくいく問題もあれば、ロジック プログラミングや宣言型プログラミングなどでうまくいく問題もあります。ネストされた if-then のレベルが多数ある場合は、ステート マシン アプローチがうまくいく可能性があります。アスペクト指向プログラミングは、特にどのモジュールにも属さないモジュール内の重複コードの問題を解決しようとします。「クロスカット」の懸念。

Programming Paradigmsを読んでみたいと思います。多くの調査を行い、問題が繰り返し発生する場合は、別のアプローチで if-then の量を減らすことができるかどうかを確認してください。ほとんどの場合、他の誰かが同じ問題に遭遇し、解決策を考え出しています。

于 2013-08-04T23:00:22.067 に答える
0

あなたの質問は少し広範であり、論理ゲートから数学関数までとりとめのないものにすることができます。この特定のビットに焦点を当てます。

「if>thenルールエンジンをグラフィカルに理論的に構築する最も直感的な方法を探しています」.

まず、2 つの注意事項:

  1. 最適な表現は、可能なルールの数によって異なります。3 ~ 4 のルールで機能するものは、おそらく 30 ~ 40 のルールでは機能しません。
  2. else条件が存在しないふりをするつもりです。

「X then Y」が要約される場合: 1 つの条件と、その実行が条件に依存する 1 つの命令。X -> Y「X が true の場合、Y が実行される」という意味にしましょう。2 つのセットを作成しましょう。1 つはC、考えられるすべての条件を含むセットです。もう 1 つはI、可能なすべての命令を含むものです。

これで気になるX ∈ CY ∈ I。あなたの特定のケースでは、Y ∈ C(Yは条件にすることができますか)できますか?もしそうなら、あなたはネストされたifを持っています。

ネストされた if は、and演算子で結合された一連の条件として表すことができます。

if (x > 3) {
  if (y > 5) {
    # do something
  }
}

次のように記述できます。

if (x > 3 and y > 5) {
  # do something
}

コードだけを考えている場合、ネストされた条件が多数ある場合、後者が問題になる可能性がありますが、グラフィカルにすると、ネスト (おそらくツリーのような構造を使用) が雑然と見えますが、チェーンは通常、一連の命令のように見えます (の方が良いと思います)。

ルールでネスト (連鎖) を考慮しない場合、要素 (ボックス、円など) を接続するのX -> Yは簡単な方法です。これの表現は、取得したいグラフィカルな方法によって異なります (いくつかの例については、以下のリンクを参照してください)。

ネストを検討している場合、次の 3 つのランダムなアイデアが頭に浮かびます。

  1. ベン図: 視覚的に魅力的ですが、3 ~ 4 を超える条件では役に立ちません。これらは、データベース表現によく適合します。参照: http://share.mheroin.com/image/3i3l1y0S2F39
  2. フローチャート: 非常に機能的で読みやすく、作成するのも面倒ではありません。10以上の要素で手に負えなくなる可能性があります。参照: http://share.mheroin.com/image/2g071j3U1u29
  3. テーブル: あなたが言及したように、テーブルは、適用可能なルールのセットを制限できる限り、条件を表す適切な方法です。これは iTunes からの例です: http://share.mheroin.com/image/390y2G18123q . 「次のルールの [all/any] に一致」は の代わりとして機能しif/elseます。
于 2013-08-05T00:35:51.430 に答える