空の文字列の重要性


7

null参照文字列とは異なる文字列の意味で、CS(および特に正式な言語)での空の文字列の重要性は何ですか?

独自のギリシャ文字(ε)さえ持っている「空の文字列」という別の概念が必要なのはなぜですか?

EOLキャラクターだけで置き換えることはできませんか?


1
コンセプトの「正しい」定義は1つしかないと思われるのはなぜですか。
ラファエル

1
@ラファエル:私がそう思うのはなぜだと思いますか?
Quora Feansは2014年

1
行間を読んでいました。より良いコメントがあったかもしれません:あなたは正式な言語をそのように定義して、いくつかの基本的な定理を証明してみましたか?
ラファエル

1
「null reference string」とはどういう意味ですか?それはプログラミング言語の概念ですか?「別のコンセプト」とはどういう意味ですか?何とは別に?ギリシャ文字εとEOL文字の違いは、テキストの表現に異なる用途があることを除いて、どのような違いがありますか?最後に、「必要」とはどういう意味ですか。特定の概念や表記法がなくても実行でき、物事を成し遂げることができるからです。高水準のプログラミング言語が必要ですか?まあ、それらは多くの点でプログラミングを容易にしますが、必須ではありません。また、構文とセマンティクスを混同しているようです。
バブー2014年

null参照文字列:nullを指す文字列変数になります(つまり、存在しない値を意味します)。別の概念:長さ44の文字列の用語はありませんが、長さ0の文字列に名前を付けるのは面倒です。同じ考えに従って、それは重要でなければなりません、さもなければ、それを繰り返し使用することを計画していない限り、用語やギリシャ文字を与えないでしょう。EOLについて:EOLがεが持つすべての機能をカバーできる場合、後者は冗長になります。
Quora Feansは2014年

回答:


12

空の文字列には数学的な意味があります。実際、単語の連結積は連想操作です。しかし、この操作には中立的な要素、つまり空の単語もあります。このため、空の単語もで表されることが多く、これにより、各単語に対して 1u

1u=u=u1

もちろん、アルファベットが場合、空の単語を表すことはお勧めできません。これが、表記(または場合によって)が導入された理由であろう。しかし、Yuval Filmusが指摘したように、空の単語は長さが単語ですつまり、空の単語には文字が含まれていません。{0,1}1ελ0

空の単語を(またはギリシャ文字のまたは)で表すのは確かにですが、空のセットを表すのと同じ方法で、従来の表記法でそれをます。1ελ


1
がモノイドであることは注目に値します。形式言語の代数的特性を調査すると、半リング解析などの興味深い結果が得られます。(Σ,)
ラファエル

8

空の文字列はゼロのようなものです。それは「何もない」を表しますが、基本的な概念です。非常に単純な例として、単語の単語の接頭辞である場合いくつかの単語。空の文字列を許可しない場合、単語はそれ自体の接頭辞にはなりません。abb=aww

EOL文字は、特定の文字セットの文字です。超える文字列に関心がある場合、EOLはありません。また、EOLは文字であるため、EOLで構成される文字列は空ではありません。{0,1}


単語がそれ自体の接頭辞であるかどうかは、定義の問題です。空の文字列を考慮しない場合は、それに応じていくつかの定義を変更して、文字列の理論の一貫したバリアントを有効にする必要があります。--文字EOLは確かに空の文字列を表すことができます。表現は、適切に構造化された任意のデバイスを使用できます。z、e、r、o、およびnの文字を使用して上の文字列を表すことができます。たとえば、「onezeroone」を使用して、通常空の文字列の「101」と「none」と表記されるものを表します。私がそれを勧めるわけではありません。{0,1}
14

やりたいことは何でもできますが、一部の定義は他の定義より「優れています」。そして、理由があります。私はそのような理由の1つを挙げています。
Yuval Filmus 14年

どのポイントに答えているかわからない。初めてのようです。空の文字列を許可しない場合は、プレフィックスの定義がおそらく不適切です。それとも、それがより良いはずである理由を教えてもらえますか?空の文字列が根本的であることを正当化するためにあなたが与えるべき本当の理由は、空の文字列なしで理論を開発することはより難しい(しかし可能性が高い)ことです。たとえば、文字列が別の文字の接頭辞になることの意味をより複雑に定義する必要があります。より微妙なポイントです。ゼロなしで算術を行うギリシャ人について考えてみてください。
バブー2014年

接頭辞と自分の接頭辞の通常の定義を正当化することもできます。これは通常、適切な接頭辞と呼ばれます。しかし、ゼロに関するあなたの例はそれをすべて与えます-人生はそれでとても簡単です。
Yuval Filmus 14年

空の文字列が許可されていない場合は、私の適切な接頭辞の定義は、接頭辞の通常の定義(空の文字列が許可されているとき)である、と私の接頭辞の定義は、 uはuがVまたは同等の適切な接頭辞である場合に限っVの接頭辞であるということですto v。ポイントは、空の文字列を許可する理論と意味的に一貫性を保つことです。はい、空の文字列を使用すると人生は簡単になります...しかし、それがなくても、単語のプレフィックスではなくなった単語についての発言で示唆しているように、状況は変わりません。それは重要なポイントだと思います。
バブー2014年

6

行末(EOL)文字を使用することは、表現力の点では同等です。空の単語で実行できることは何でも、代わりにEOLで再定義することができます–しかし、それを使用すると、お尻の途方もない苦痛になります。従来の定義は次のとおりです。ε

アルファベットは有限集合である記号の。文字列アルファベットを超える  A有限シーケンスであるそれぞれ、。と書きます 以下のための長さのと、。長さがゼロの一意の単語はで表され  ます。ストリングの任意の文字列である、。文字列の連結Σ sΣs1ssiΣ|s|s|s1s|=εs1ssisj1ijs1sそして、は、長さの文字列です。t1tms1st1tm+m

これと比較してください:

してみましょう区別することが行の最後のシンボル。アルファベットの有限集合である シンボルのよう。ストリングアルファベット上 有限シーケンスここためのと。と書きます 以下のための長さのと、。ストリングの任意の文字列でありますΣΣ sΣs1ssiΣ{}i<s=|s|s|s1s|=1s1ssisj、ここで。連結ストリングのとされる文字列の長さの。1ij<s1st1tms1s1t1tm+m2

特に連結の定義では、余分な手間と、off-by-oneエラーの可能性に注意してください。また、これらの終了文字列に対してオートマトンを定義することを検討してください。入力に言語が必要とするプロパティがあるかどうかをチェックすることに加えて、オートマトンは入力の最後の文字が、これは(私が思うに)すべてのオートマトンに2つの状態を追加します。

空の文字列 ε自然数のゼロと同じ役割を持っています。これは、最も基本的な操作(文字列の連結、ナチュラルの追加)のIDです。これは、グループモノイドなど、あらゆる種類の代数的構造を構築する場合に重要です。これにより、潜在的に有用な数学的結果の広い領域にアクセスできます。より簡単に言えば、仮説は空の文字列に対しては取るに足らないものであることが多いため、これは帰納法の優れた基本ケースになります。実際、文字列に帰納を行う場合、次の帰納的な定義を暗黙的に使用しています。Σ-文字列:

  • εΣ-ストリング;
  • もし sΣ-文字列と σΣ、その後 sσΣ-ストリング。

それはまた、終了した文字列でより面倒になります:

  • Σ-ストリング;
  • もし sΣ-文字列と σΣ{}、その後 sσΣ-ストリング。

もちろん、逆にそれを行うことができ、 s 文字列なので、そうです σs。その時点では、終了文字列と非終了文字列のどちらを選択するかはほとんどありませんが、誘導は、最初よりも最後に文字を追加する方が適している場合があります。

終了文字列はでのプログラミングには適していますが、数学にはあまり適していません。あなたがプログラミングしているとき、あなたは文字列がいつかを知る何らかの方法が必要ですs1s終わり; あなたが数学をしているとき、それは明らかですs 文字列の記述方法の最後の文字です。


null参照と空の文字列の違いについて尋ねていることに気づきました。null参照は文字列ではありません。空の文字列は文字列ですが、文字は含まれていません。必要に応じて、空白の紙(空の文字列)と紙をまったく使用しない(nullリファレンス)の違いです。


IMO、あなたの答えの最初の部分は見当違いです。従来の定義は、文字列の表現方法とは関係なく、文字列が何であるかを抽象的に定義することを目的としています。2番目の定義は、1つの可能な表記を定義する正式な方法ですが、文字列について推論するために必要なものではありません。OPのやや厄介な質問によって示唆された構文とセマンティクスの間の混乱を強化しています。残りの回答にも同じ問題があります。
14

最後の段落では、構文とセマンティクスの間の混乱を繰り返します。空の文字列は抽象的な概念であり、空の文字列は便利と思われるものによって表される一方で、空の文字列はコンピュータでnull参照によって表すことができます。唯一の要件は、文字列の数学的セマンティクスが適切に尊重されるように、文字列操作関数がそれに応じて記述されていることです。紙も文字列を表すためだけのものであることに注意してください。抽象的な数学的実体はこの世界のものではありません。
14

@babou私が述べたように(「あなたが空の言葉でできることは何でも ε、代わりにEOLで行うことができます。)、2つのオプションは意味的に同等であり、この意味上の役割(たとえば、連結演算子のID)について説明します。別に、EOLが構文的に不便である方法について説明します。これはどのようにして構文とセマンティクスを混同していませんか?
David Richerby 2014年

最初の定義は、抽象的な概念の標準的な定義です。文字列が実際にどのように表現されるかについては、何も述べていません(必要はありません)。OPは表現に関係しており、2番目の定義では、提案された表現を概念の抽象的な定義であるかのように模倣しています。シンボル 中にはいけません Σ、ただし、文字列表現を終了するために使用される表記デバイスのみである可能性があり(おそらく非常に小さな不便さ)、そのため、表記は空の文字列に対して統一されます。構文とセマンティクスを混同しました。
14

すでに述べたように、EOLの構文上の不便さについてのあなたの声明は不当です。不適切な定義(文字列の2番目の定義)を使用して問題を作成しました。私の(書き換えられた)回答の最後に、これらの問題が存在しないことを示す、使用していたはずの定義を示します。⊣は表記された文字列の記号ではなく、表記法の一部である必要があります。
バブー

5

短い答え:空のセット(つまり、文字列を含まない文字列のセット)はゼロのようですが、空の文字列(つまり、長さがゼロの文字列を1つ含む文字列のセット)は1のようです。

形式言語を公理化する1つの方法は、べき等半リングとしてです。セミリングは、2つの2項演算を持つ構造です+ そして 、および2つの区別される要素 0 そして 1、および以下の公理に従います。最初に、+ アイデンティティを持つ可換モノイドです 0

(A+B)+C=A+(B+C)
0+A=A+0=A
A+B=B+A

第二に、 アイデンティティを持つモノイドです 1

(AB)C=A(BC)
1A=A1=A
乗算の左と右は加算に分配されます:
A(B+C)=(AB)+(AC)
(A+B)C=(AC)+(BC)
0による乗算は消滅します。
0A=A0=0
そして最後に、加算はべき等です:
A+A=A

「加算」は集合和集合として解釈でき、「乗算」は文字列連結として解釈できます。

ああ、そしてリンクは非常に深くなります。次のように直感的に定義されるクリーネ閉鎖演算子:

A=1+A+A2+A3+

指数のように動作します。のパワーシリーズについて考えますexさらに、加算はべき等であるという事実。

端末文字は変数のように動作します。特に、評価をゼロで定義できます。

a(0)=0
(AB)(0)=A(0)B(0)
(A+B)(0)=A(0)+B(0)
A(0)=1

正規表現を考える EE(0) どちらかです 0 または 1。です1 空の文字列がメンバーである場合 E、および 0 さもないと。

Brzozowski導関数と呼ばれる導関数を定義することもできます。

aa=1
ba=0
(A+B)a=Aa+Ba
ABa=A(0)Ba+AaB
Aa=AaA

ここで唯一奇妙なルールは、乗算のルールです。これはおなじみの製品ルールとほとんど同じです。違いは、連結が非可換であるためです。

導関数が直感的に意味することは、 Ea は文字列のセットです E 記号で始まる a、しかしそれで a削除されました。そうaEa は文字列のセットです E で始まる a

少し考えてみます az はアルファベットです。

E=E(0)+aEa+bEb++zEz

これは通常の言語のみのテイラーの定理です。さらに、正規表現から直接DFAを作成するためのルールでもあります。E(0) です 1 初期状態が最終状態であり、その他の項が遷移である場合に限ります。

これについての注目すべき点の1つは、よく知られた正規表現演算子(さらに、集合交差や集合差などのあまり知られていないもの)がそれらの導関数とゼロでの評価によって完全に決定されることです。これは、微積分の基本的な定理から私たちが期待することですが、ここでもそれを見るのは興味深いです。

ちなみに、この理論は文脈自由で再帰的な言語にも拡張できますが、ここでは説明しませんが、もう少し機械が必要です。


4

数学に関する基本的な質問

この回答は、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番目の定義は、実際には次のようになっていました。

アルファベットは有限集合でありますΣシンボルの。  s アルファベット以上 Σ の有限シーケンスです シンボル si、 どこ 01i そして siΣ すべての値 i。注目されるs1s どこ 記号を示さない特殊文字です Σ。私たちは書く|s|以下のための長さs、 によって定義されます |s1s|=ストリングs1s 任意の文字列です sisj、 どこ 1ij。文字列の連結s1s そして t1tm 文字列です s1st1tm 長さの +m
結果として、長さがゼロの一意の文字列が示されることに注意してください  

この定義は、David Richerbyによる従来の定義の表記法の変形にすぎません。それは複雑さや「余分な面倒さ」を導入せず、単純な理由でオートマトン理論に何も変更しません文字列の記号ではなく、表記の一部です。そして、それは空の文字列を含むすべての文字列に統一表記を与えます。

Yuval Filmusは彼の2番目の発言で同様のエラーを発生させます。{0,1} 意味的に文字列を構成できるシンボルのリストに関係します。

回答をまとめる

J.-E. ピンの答えはまったく正しいですが、空の文字列の重要性に関する質問の一部のみを取り上げています。統一表記の可能性については触れていません。

Yuval FilmusDavid Richerbyの回答は構文とセマンティクスを混同しているため、EOLを使用するというOPś質問の提案を誤って拒否しました。また、空の文字列のセマンティックな重要性を主張するYuval Filmusの主張には、非常に異議があります。ある程度の意味はありますが、null参照の使用に関するDavid Richerbyの発言も多少不当です。コードが適切に記述されていれば、空の文字列を表すために使用することもできます。

ペンネームによって答えは、形式言語に空の文字列の重要性についての理論的な過剰ですが、実際に疑問が提起した問題については説明しません。

私自身の答え、私はそれが適切に問題に対処し、エラーが含まれていない願っています唯一のことができますが、それはこれまであまりにも長いです。


ちなみに、空の文字列は「ゼロのようだ」というのはそうではないので、ユヴァルフィルマスの発言に異議を唱えたかったので、できるだけ詳細に調べました。でも、最後の質問には触れなかったのはあなたの言うとおりです。私の弁護では、これはCSであり、stackoverflowではありません。
仮名2014年

@Pseud Yuval Filmusはもっと弱い意味でそれを意味していたと思います。いずれにしても、ゼロとは(大雑把に言えば)何であるか(そうではないか)は、どのような数学的構造を見るかによって異なり、空の文字列についても同じです。その点では彼の答えは公平だった、imho。あなたのポイントは興味深いものでしたが、OPにとっては少し重いかもしれません。ところで、私は、より単純な読者のためにどこかにそれを通知したり、答えが私のものである場合は修正したりせずに、誤ったまたは疑わしい答えで質問を残さないようにしています。私の答えが長すぎることは知っていますが、読んだ内容に誤りや異議のある発言を見つけましたか。
バブー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.