null参照文字列とは異なる文字列の意味で、CS(および特に正式な言語)での空の文字列の重要性は何ですか?
独自のギリシャ文字(ε)さえ持っている「空の文字列」という別の概念が必要なのはなぜですか?
EOLキャラクターだけで置き換えることはできませんか?
null参照文字列とは異なる文字列の意味で、CS(および特に正式な言語)での空の文字列の重要性は何ですか?
独自のギリシャ文字(ε)さえ持っている「空の文字列」という別の概念が必要なのはなぜですか?
EOLキャラクターだけで置き換えることはできませんか?
回答:
空の文字列には数学的な意味があります。実際、単語の連結積は連想操作です。しかし、この操作には中立的な要素、つまり空の単語もあります。このため、空の単語もで表されることが多く、これにより、各単語に対して
もちろん、アルファベットが場合、空の単語を表すことはお勧めできません。これが、表記(または場合によって)が導入された理由であろう。しかし、Yuval Filmusが指摘したように、空の単語は長さが単語ですつまり、空の単語には文字が含まれていません。
空の単語を(またはギリシャ文字のまたは)で表すのは確かにですが、空のセットを表すのと同じ方法で、従来の表記法でそれをます。
空の文字列はゼロのようなものです。それは「何もない」を表しますが、基本的な概念です。非常に単純な例として、単語の単語の接頭辞である場合いくつかの単語。空の文字列を許可しない場合、単語はそれ自体の接頭辞にはなりません。
EOL文字は、特定の文字セットの文字です。超える文字列に関心がある場合、EOLはありません。また、EOLは文字であるため、EOLで構成される文字列は空ではありません。
行末(EOL)文字を使用することは、表現力の点では同等です。空の単語で実行できることは何でも、代わりにEOLで再定義することができます–しかし、それを使用すると、お尻の途方もない苦痛になります。従来の定義は次のとおりです。
アルファベットは有限集合である記号の。文字列アルファベットを超える A有限シーケンスであるそれぞれ、。と書きます 以下のための長さのと、。長さがゼロの一意の単語はで表され ます。ストリングの任意の文字列である、。文字列の連結 そして、は、長さの文字列です。
これと比較してください:
してみましょう区別することが行の最後のシンボル。アルファベットの有限集合である シンボルのよう。ストリングアルファベット上 有限シーケンスここためのと。と書きます 以下のための長さのと、。ストリングの任意の文字列であります 、ここで。連結ストリングのとされる文字列の長さの。
特に連結の定義では、余分な手間と、off-by-oneエラーの可能性に注意してください。また、これらの終了文字列に対してオートマトンを定義することを検討してください。入力に言語が必要とするプロパティがあるかどうかをチェックすることに加えて、オートマトンは入力の最後の文字が、これは(私が思うに)すべてのオートマトンに2つの状態を追加します。
空の文字列 自然数のゼロと同じ役割を持っています。これは、最も基本的な操作(文字列の連結、ナチュラルの追加)のIDです。これは、グループやモノイドなど、あらゆる種類の代数的構造を構築する場合に重要です。これにより、潜在的に有用な数学的結果の広い領域にアクセスできます。より簡単に言えば、仮説は空の文字列に対しては取るに足らないものであることが多いため、これは帰納法の優れた基本ケースになります。実際、文字列に帰納を行う場合、次の帰納的な定義を暗黙的に使用しています。-文字列:
それはまた、終了した文字列でより面倒になります:
もちろん、逆にそれを行うことができ、 文字列なので、そうです 。その時点では、終了文字列と非終了文字列のどちらを選択するかはほとんどありませんが、誘導は、最初よりも最後に文字を追加する方が適している場合があります。
終了文字列はでのプログラミングには適していますが、数学にはあまり適していません。あなたがプログラミングしているとき、あなたは文字列がいつかを知る何らかの方法が必要です終わり; あなたが数学をしているとき、それは明らかです 文字列の記述方法の最後の文字です。
null参照と空の文字列の違いについて尋ねていることに気づきました。null参照は文字列ではありません。空の文字列は文字列ですが、文字は含まれていません。必要に応じて、空白の紙(空の文字列)と紙をまったく使用しない(nullリファレンス)の違いです。
短い答え:空のセット(つまり、文字列を含まない文字列のセット)はゼロのようですが、空の文字列(つまり、長さがゼロの文字列を1つ含む文字列のセット)は1のようです。
形式言語を公理化する1つの方法は、べき等半リングとしてです。セミリングは、2つの2項演算を持つ構造です そして 、および2つの区別される要素 そして 、および以下の公理に従います。最初に、 アイデンティティを持つ可換モノイドです :
第二に、 アイデンティティを持つモノイドです :
「加算」は集合和集合として解釈でき、「乗算」は文字列連結として解釈できます。
ああ、そしてリンクは非常に深くなります。次のように直感的に定義されるクリーネ閉鎖演算子:
指数のように動作します。のパワーシリーズについて考えますさらに、加算はべき等であるという事実。
端末文字は変数のように動作します。特に、評価をゼロで定義できます。
正規表現を考える 、 どちらかです または 。です 空の文字列がメンバーである場合 、および さもないと。
Brzozowski導関数と呼ばれる導関数を定義することもできます。
ここで唯一奇妙なルールは、乗算のルールです。これはおなじみの製品ルールとほとんど同じです。違いは、連結が非可換であるためです。
導関数が直感的に意味することは、 は文字列のセットです 記号で始まる 、しかしそれで 削除されました。そう は文字列のセットです で始まる 。
少し考えてみます はアルファベットです。
これは通常の言語のみのテイラーの定理です。さらに、正規表現から直接DFAを作成するためのルールでもあります。 です 初期状態が最終状態であり、その他の項が遷移である場合に限ります。
これについての注目すべき点の1つは、よく知られた正規表現演算子(さらに、集合交差や集合差などのあまり知られていないもの)がそれらの導関数とゼロでの評価によって完全に決定されることです。これは、微積分の基本的な定理から私たちが期待することですが、ここでもそれを見るのは興味深いです。
ちなみに、この理論は文脈自由で再帰的な言語にも拡張できますが、ここでは説明しませんが、もう少し機械が必要です。
この回答は、OPが彼の質問の意味と意図についてより正確な情報を提供した後に再編成されました。通常のコメント形式でコメントするのは面倒なので、ここでは他の回答にもコメントします。それらにコメントを付けると、関連する問題についてさらに洞察が得られます。
空の文字列が文字列と形式言語の研究で特別な役割を果たすというのはあなたの直感です。それが、特別な名前や表記が与えられることが多い理由です。与えられたシンボルのセット上の文字列は、モノイドと呼ばれる代数的構造を形成します。連結演算には、中立的な要素である空の文字列が含まれます。J.-Eの回答を参照してください。ピン。
また、他にも多くの表記法や表記法がある可能性があることは間違いありません。表現の選択は、利便性、目立ちやすさ、談話、推論、計算の簡素化によって決まります。
当然のことながら、そのような便利さの1つは、空の文字列を含むすべての文字列に統一された表記があることです。これは、紙でもコンピュータでも、いくつかの方法で実現できます。文字列に含まれるシンボルのセットに属していないはずの特別なシンボルで文字列を終了することは、その方法の1つです。これはあなたがEOLで提案するものだと思います。これは、45年前にプログラミング言語Cのデニス・リッチーによって行われたが、EOLではなくバイト0を使用し、NULまたは^ @も使用した点が異なっていた。
テキストでは、引用符で囲むか、最後のターンスタイルで行うことができます 。ただし、単独で空の文字列を表し、それによってすべての文字列が終了します。これは、文字εの使用には当てはまりません。それらは、まったく同じ構文上の役割を果たすわけではありません。
原則として、EOL、^ @、または より複雑な表現メカニズムを追加しない限り、文字列に属するシンボルにすることはできません。
コンピューターでは、空の文字列を表すためにnull参照文字列を使用できます。それ以外の場合は、文字列の抽象的な概念とは何の関係もないプログラミングの概念のみです。
しかし、あなたの質問は少しわかりにくく、あまりよく述べられていませんでした。「個別の概念」について話すことは、構文の再提示ではなく、意味上の問題を示唆しています。そして、EOLではなくεを使用するテキストの印刷された表現と、その逆を行うコンピュータ表現を混ぜていました。
これは奇妙な質問です。そのように、それはまた、数学に関する1つまたは2つの基本的な問題を提起します。
そのような問題を理解することは明白ではありません。明らかに有能なユーザーによって与えられたいくつかの回答の不十分さと、質問自体の不十分によって見られます。これがこの質問に私を惹きつけたものです。
これらの2つの問題は、次の問題に関係しています。
数学とプログラミングにおける構文とセマンティクスのそれぞれの役割と使用法の適切な理解。
「既存の理論から概念を取り除く」ことの効果の適切な理解。
セマンティクスに関係する2番目の問題は、おそらく論理学者によって、そしておそらく科学の歴史家によって対処されています。しかし、私はそれが正式に対処されたのを見た覚えはありません(またはおそらくそれを認識しませんでした)。
構文とセマンティクスの混同は、OPが「個別の概念」について語っていて、むしろ「個別の表記」について語るべきであるという事実から生じたものと思われます。彼が問題を理解しようとしているので、そのような間違いはおそらく彼の場合には公正です。しかし、それが何を意味するのかについて「概念」という言葉を採用したため、回答した一部のユーザー、明らかにユヴァルフィルムスと私自身をさらに混乱させました。
次の段落はあなたが意図した質問についてではないことに気づきました。しかし、それはあなたが書いた質問であり、これはセマンティクスとして理解されるべきであり、あなたが構文を意味する一方で、何人かの人々によって行われたものです(以下の構文の部分で扱われる)
レッツあなたの質問で開始「なぜ、あなたは『空の文字列』のことを、別の考え方が必要なのか、私はとして理解」:「?私たちが今まで空の文字列を考慮せずに、理論的にはプログラミングでは、文字列を使用することができます」、明らかにYuval Filmusと同じように。
実際、空の文字列は必要ないことがよくありますが、通常は空の文字列を使用する方が便利です。理論のほとんどは、おそらく空の文字列を考慮せずに開発できるでしょう。結局のところ、多くの 算術はゼロを数として考慮せずにギリシャ人によって開発されました。ゼロは、数世紀後にインドで構文的および意味的に導入されました。数体系の拡張は、新しい概念を導入するだけでなく、古い概念の理解と使用を簡素化する方法でもあります。ゼロと負の数を導入すると、自然な正の数などの特性を理解しやすくなります。実数上の関数の一部のプロパティ(系列の収束など)は、複素数への拡張を検討すると、分析と理解がはるかに容易になります。
そのため、数学に新しい概念と拡張機能を導入することは、理論を単純化するための良い方法であることがよくあります(通常、問題を表現するためにより強力です)。
空の文字列を「自然な文字列」とともに導入すると、文字列に基づいて構築された理論が簡素化されますが、それは十分な理由です。通常、他の回答で述べたように、空の文字列を使用すると、文字列を既知の代数構造(モノイド)の代表(モデル)と見なし、そのような構造に関するすべての既知の結果を直接適用できます。確かに、J.-E。ピン、空の文字列は文字列の連結演算に直接関連しています(そして、ゼロが整数の追加に関連しているのと同じ方法で追加します)。
空の文字列は必要ない場合と必要ない場合がありますが、それを使用しない場合よりも使用する場合のほうが数学を実行する方がはるかに便利です。また、これはプログラミングにも当てはまります(これは、建設的な証明を生成することを目的とした数学の一種です)。
一貫性の問題
しかし、ギリシャ人が数字のゼロを考慮しないのと同じように、空の文字列の概念を許可しないことの影響に関するユヴァルフィルムスの答えには同意しません。新しい数値としてゼロを導入しても、既知の算術演算の結果が変更された場合は受け入れられませんでした。せいぜい、それはそれ自身の目的を持つ別の理論と考えられていただろう。
同様に、文字列の理論では、空の文字列を許可するかどうかに関係なく、一貫した結果が得られるはずです。しかし、どちらのアプローチも、それを明確かつ意味のあるものにするために一貫した定義を使用する必要があり、Yuval Filmusはそうしませんでした。
空の文字列が許可されている場合、通常の接頭辞の定義は次のとおりです。
文字列uは、文字列vの接頭辞です。ただし、文字列wがあり、uw = v
ここで、ドットは文字列の連結を示します。これにより、w =ε(空の文字列)を取ることにより、文字列がそれ自体の接頭辞になることができます。次に、以下を定義できます。
文字列uは、文字列vの適切なプレフィックスであり、それがvのプレフィックスであり、vと等しくない場合に限ります。
ただし、空の文字列が許可されていない場合は、これらの定義を一貫して異なる方法で記述する必要があります。例えば:
文字列uは、文字列vの適切な接頭辞です。ただし、文字列wがあり、uw = v
wには少なくとも1つの記号が必要であることに注意してください。次に、以下を定義できます。
文字列uは、文字列vの接頭辞です。ただし、uがvまたはu = vの適切な接頭辞です。
このような一貫した定義により、理論で空の文字列が許可されていない場合でも、単語はそれ自体の接頭辞のままです。
したがって、Yuval Filmusによって主張されているように、空の文字列を許可しないことで文字列のプロパティが(少なくともそれほど簡単な方法で)変更されないことが重要です。重要な点は、文字列の研究がより複雑になることであり、ゼロについて話すことができないときに算術がより複雑になるのと同じように。
2番目の問題は構文です。文字列を紙またはコンピュータでどのように表現するか。特に、空の文字列の概念を持つことが有用であると私たちが同意した場合、それを構文的に表現して、それについて話したり書いたりできるようにする必要があります。
実際、すべての数学的概念について疑問が生じます。それらをどのように表現すれば、私たちがそれらについて話したり書いたりできるか、そして可能な限り便利に表現できるようになるでしょう。数学の進化の多くは、構文の改善、概念の表現にも関連しています。ささいな例は、古代ローマの整数表現で算術を実行することのぎこちなさです。
空の文字列に関する最初の答えは、それを他の文字列の表現と一致させたい場合があるということです。通常、文字列の表現には、文字列内の一連の記号と、引用符などの追加の表記法が含まれます。たとえば、" gattaca "。その後、空の文字列を ""として表すのは非常に自然になります。
上記の例をガッタカとして表す場合、空の文字列の自然な表現は (David Richerbyが暗示するように)。
したがって、 (実際に書かれているように、別個の概念ではなく)別個の表記法を導入する必要性についての質問は、否定的な答えを持っています。いいえ、必要ありません。空の文字列を含むすべての文字列で、統一表記、統一表現が可能です。
ただし、文字列をgattacaなどの一連の記号で表すだけで、他の文字は含まない場合、空の文字列は構文的に見えなくなり、かなり不便になります。次に、ギリシャ文字のεやその他の名前など、特定の表記法を導入する必要があります。
同様に、文字列を抽象的に研究する場合、科学者がお互いに話し合うときに、「」を使用して空の文字列を表すのは少し面倒です。時々。したがって、名前を付けた方がいいでしょう。言って、空の文字列をやるかもしれませんが、書面で厄介です。したがって、数学でよく行われているように、特定の関連性のあるエンティティを示すために1文字の記号を使用する習慣は、
EOLで空の単語を表すという提案は、本質的にそれを表すことと同じです。 。これは、特別な終了文字を持つ文字列の表現です。EOLは、「コンピュータでなんとかして利用できる」特殊文字です。
ローマ整数演算について上記で述べたように、表現の選択は、特にアルゴリズム環境では、利便性によって指示されるべきです。コンピュータで文字列を表現する方法は多く、特に空の文字列を表現する方法はたくさんあります。理論的な観点から見ると、どちらを選択してもかまいません。実用的な観点から、文字列の操作と操作をより効率的にするものを選択することが不可欠です。これは、アルゴリズムとデータ構造に関するあらゆるクラスの基本的な問題です。
デビッド・リチャービーの答えは、構文と意味論の混乱のために興味深いものです。
彼は質問で提案されたEOLの構文使用法を紹介しようとします。 、しかし彼は奇妙にそれを文字列のセマンティックドメインの定義と混合し、そのセマンティックドメインの表記法の一部のみであると想定されるものを作成します。
彼の2番目の定義は、実際には次のようになっていました。
アルファベットは有限集合でありますシンボルの。 弦 アルファベット以上 の有限シーケンスです シンボル 、 どこ 、 そして すべての値 。注目される どこ 記号を示さない特殊文字です 。私たちは書く以下のための長さの 、 によって定義されます 。ストリングの 任意の文字列です 、 どこ 。文字列の連結 そして 文字列です 長さの 。
結果として、長さがゼロの一意の文字列が示されることに注意してください 。
この定義は、David Richerbyによる従来の定義の表記法の変形にすぎません。それは複雑さや「余分な面倒さ」を導入せず、単純な理由でオートマトン理論に何も変更しません文字列の記号ではなく、表記の一部です。そして、それは空の文字列を含むすべての文字列に統一表記を与えます。
Yuval Filmusは彼の2番目の発言で同様のエラーを発生させます。 意味的に文字列を構成できるシンボルのリストに関係します。
J.-E. ピンの答えはまったく正しいですが、空の文字列の重要性に関する質問の一部のみを取り上げています。統一表記の可能性については触れていません。
Yuval FilmusとDavid Richerbyの回答は構文とセマンティクスを混同しているため、EOLを使用するというOPś質問の提案を誤って拒否しました。また、空の文字列のセマンティックな重要性を主張するYuval Filmusの主張には、非常に異議があります。ある程度の意味はありますが、null参照の使用に関するDavid Richerbyの発言も多少不当です。コードが適切に記述されていれば、空の文字列を表すために使用することもできます。
ペンネームによって答えは、形式言語に空の文字列の重要性についての理論的な過剰ですが、実際に疑問が提起した問題については説明しません。
私自身の答え、私はそれが適切に問題に対処し、エラーが含まれていない願っています唯一のことができますが、それはこれまであまりにも長いです。