通常のVS文脈自由文法


96

私は自分のコンピューティング言語テストのために勉強しています。頭を回すのに問題があるという考えがあります。

通常の文法はより単純で曖昧さを含むことはできないが、プログラミング言語に必要な多くのタスクを実行することはできないことを理解しました。また、文脈自由文法は曖昧さを許容しますが、プログラミング言語に必要ないくつかのもの(パリンドロームなど)を許容することも理解しました。

私が問題を抱えているのは、通常の文法の非端末が端末または非端末の後に端末が続くか、コンテキストフリーの非端末が端末と非端末の任意の組み合わせにマッピングできることを知ることで、上記のすべてをどのように導出できるかを理解することです。。

誰かが私がこれをすべてまとめるのを手伝ってくれる?

回答:


70

通常の文法は右または左の線形ですが、文脈自由文法は基本的に終端と非終端の任意の組み合わせです。したがって、通常の文法は文脈自由文法のサブセットであることがわかります。

たとえば回文の場合、形式は次のとおりです。

S->ABA
A->something
B->something

パリンドロームは通常の文法では表現できないことを明確に見ることができます。これは、パリンドロームが右または左の線形である必要があるため、両側に非終端記号を付けることができないためです。

通常の文法はあいまいではないため、特定の非終端記号に対して生成規則は1つしかありませんが、文脈自由文法の場合は複数存在する可能性があります。


13
まず、通常の文法があいまいになる可能性があります(Kai Kuchenbeckerの例:S-> aA | aB、B-> a、A-> a)。唯一のことは、構文ツリー内のノードを配置できる方法が1つしかないことです(たとえば、通常の文法が使用されている場合、結合性のあいまいさは存在しません)。2番目:非端末の右側に複数の右側がある可能性があります(A-> a、A-> aA;ウィキペディアには3番目の代替としてイプシロンも含まれています:en.wikipedia.org/wiki/Regular_grammar
user764754

1
あいまいさは、文が複数の派生パスで文法から派生できる場合に発生します。非ターミナルに対して複数のプロダクションルールがあるだけでは、文法は曖昧になりません
Sujoy

11
この例は実際には間違っています。完全なルールがあるA-> a | cと想像するとB->b、この文法は非パリンドロームを許可します。たとえば、以下を作成できますS->ABA->aBA->abA->abc。問題は、最初のルールで2つの変数を生成するのではなく、2つの端子を生成することです。回文を可能に文法の可能性がある:S -> aSa | bSb | a | b
gdiazc

その回文があります 通常の文法で表現できる。単一の文字で構成されるパリンドロームです。たとえば、S -> aSa | ea(aa)*aの両方が正規言語を記述します。これは、CFGが左または右の直線性に違反している場合でも、通常の言語を記述できることを示しています。確かに、これはそれほど明白ではない回文です..
マルチン

考えてみると、この答えは実際には間違っています。それは、「文脈自由」の文法は基本的に端末と非終端の任意の組み合わせであると言い、「しかし、TU ^ ^ NVW MXY ^ KZは、文脈自由端子と非終端の組み合わせではなく、。。
チャーリー・マーティン

58

あなたが考えたいのは、さまざまなポンピング補題です。通常の言語は有限オートマトンで認識できます。文脈自由言語にはスタックが必要であり、文脈依存言語には2つのスタックが必要です(これは、完全なチューリングマシンが必要であると言うのと同じです)。

したがって、通常の言語のポンプ補題について考えると、基本的に、通常の言語はxyzの 3つの部分に分解でき、言語のすべてのインスタンスはxy * zにあります。(*はKleeneの繰り返し、つまりyの 0以上のコピーです。)基本的に、展開できる「非終端」が1つあります。

では、文脈自由言語についてはどうでしょうか?言語の文字列をuvxyzの 5つの部分に分割し、言語のすべてのインスタンスが存在するコンテキストフリー言語には、類似したポンプレンマがあります。 uv i xy i zにある。これで、2つの「非終端「同じ数を持っている限り、複製またはポンピングできます。


10
文脈依存言語では、完全なチューリングマシンは必要ありません。線形有界オートマトンで十分です。これはテープが有限であるチューリングマシンで、サイズは入力文字列の線形関数によって制限されます。
Dave Clarke

16

通常の文法と文脈自由文法の違い: (N、Σ、P、S):端末、非端末、生成、開始状態端末記号

●正式な文法で定義された言語の基本記号

●abc

非終端記号(または構文変数)

●プロダクションルールに従って端子シンボルのグループに置き換えられます

●ABC

通常の文法:右または左の通常の文法右の通常の文法、すべてのルールはフォームに従います

  1. B→aここで、BはNの非終端であり、aはΣの終端です。
  2. B→aCここで、BとCはNにあり、aはΣにあります
  3. B→εここで、BはNにあり、εは空の文字列、つまり長さが0の文字列を示します

通常の文法を残し、すべてのルールはフォームに従います

  1. A→aここで、AはNの非終端、aはΣの終端です。
  2. A→Baここで、AとBはNにあり、aはΣにあります
  3. A→ε(AはNにあり、εは空の文字列)

文脈自由文法(CFG)

○すべてのプロダクションルールがV→wの形式である正式な文法

○Vは単一の非終端記号です

○wはターミナルおよび/または非ターミナルの文字列です(wは空でもかまいません)。


5

通常の文法:-次のようにプロダクションを含む文法はRGです。

V->TV or VT
V->T

ここで、V =変数、T =端子

RGは、Left Linear GrammarまたはRight Liner Grammarですが、Middle linear Grammarではありません。

RGはすべて線形文法ですが、RGは左線形または右線形文法のみです。

通常の文法があいまいな場合があります。

S->aA|aB
A->a
B->a

あいまいな文法:-文字列xに対して、それらは複数のLMDまたは複数のRMDまたは複数の解析ツリーまたは1つのLMDと1つのRMDが存在しますが、両方が異なる解析ツリーを生成します。

                S                   S

              /   \               /   \
             a     A             a     B
                    \                   \
                     a                   a

2つの構文解析木があるため、この文法は曖昧な文法です。

CFG:- プロダクションが次の形式の場合、CFGと呼ばれる文法:

   V->@   where @ belongs to (V+T)*

DCFL: -すべてのDCFLはLL(1)文法であり、すべてのLL(1)はLR(1)であるため、あいまいになることはありません。したがって、DCFGがあいまいになることはありません。

また、すべてのRLはDCFLであるため、RLがあいまいになることはありません。RGがあいまいかもしれませんが、RLはあいまいでないことに注意してください。

CFL: CFlがあいまいかもしれません。

注: RLは本質的に曖昧になることはありません。



3

すべてのプロダクションルールの形式がAの場合、文法はコンテキストフリーです(つまり、ルールの左側は単一の変数のみで、右側は無制限で、ターミナルと変数の任意のシーケンスにできます)。文法を4タプルとして定義できます。ここで、Vは有限集合(変数)、_は有限集合(終端)、Sは開始変数、Rは有限集合の規則であり、それぞれがマッピングです。 Vの
通常の文法は右または左の線形ですが、文脈自由文法は基本的に終端と非終端の任意の組み合わせです。したがって、通常の文法は文脈自由文法のサブセットであると言えます。これらのプロパティの後、Context Free Languagesセットには通常の言語セットも含まれていると言えます


-1

基本的に通常の文法は文脈自由文法のサブセットですが、すべての文脈自由文法が通常の文法であるとは言えません。主に文脈自由文法はあいまいであり、通常の文法はあいまいである場合があります。


-4

通常の文法は、左線形または右線形のいずれかであるため、あいまいになることはありません。通常の文法では2つの決定木を作成できないため、常に明確です。


4
@dinesh通常の文法はあいまいな場合があります。2つの異なる構文ツリーが存在する場合、文法があいまいであり、構文ツリーにラベルが付けられていることを思い出してください。したがって、同形ツリーは異なるツリーです。つまり、S-> aAのような単純な文法です。aB、B-> a、A-> aは、同型であるが異なる単語「aa」の2つの構文ツリーが存在するため、あいまいです。
Kai Kuchenbecker
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.