ほとんどのプログラミング言語に '！>'（より大きくない）および '！<'（より小さくない）演算子がない理由はありますか？

何か理由があるのか​​、それとも単なる歴史の偶然なのか、ほとんどのプログラミング言語には演算子!>と!<演算子がないのだろうか？

a >= b （大きいOR Bに等しい）のように書くことができた!(a < b) （より少ないNOT b）に等しくなります、a !< b。

この質問は、私が自分の式ツリービルダーをコーディングしている最中に思いつきました。ほとんどのプログラミング言語は持っていないa != bためにオペレータを!(a=b)、なぜ何!>と!<？

更新：

• !<（ないより少ない）で発音しやすくより>=（大きいまたは等しいです）
• !<（ないより少ない）で入力するより短いより>=（大きいまたは等しいです）
• !<（以上ではない）理解するのが簡単です>=（以上）

* OR2つのオペランド（grater、equals）を操作するために必要なバイナリ演算子であるのに対しNOT、単項演算子であり、1つのオペランド（より小さい）でのみ操作する必要があるためです。

Dプログラミング言語とDMCの拡張 CおよびC ++には、これらの事業者は（それらのすべての14の組み合わせ）をサポートしていましたが、興味深いことに、Dは、これらの演算子を廃止しようとしている主な理由は、

1. 正確にはa !< b何ですか？ですa>=b || isNaN(a) || isNaN(b)。!<ではないと同じ>=ので、NaN !< NaN真しばらくはNaN >= NaNfalseです。IEEE 754 を習得するのは難しいので、a !< btoを使用するとNaNの処理に混乱が生じるだけです。Phobos（Dの標準ライブラリ）でそのような演算子を検索できます。
2. したがって、たとえDのような演算子が存在していても、それを使用する人はほとんどいません。
3. また、これらのめったに使用されない演算子に対してさらに8個のトークンを定義する必要があります。
4. そして、これらの演算子がなくても、同等のを使用することもでき!(a < b)ます。明示的a >= b || isNaN(a) || isNaN(b)にしたい場合は、読みやすくします。

また、関係（≮、≯、≰、≱）は、!=（≠）や>=（≥）とは異なり、基本的な数学ではめったに見られないため、多くの人々にとって理解するのは困難です。

これらはおそらく、ほとんどの言語がそれらをサポートしない理由でもあります。

まったく同じ意味を持つ2つの異なる演算子を持つことはあまり意味がないためです。

• 「大きくない」（!>）は「以下」とまったく同じです（<=）
• 「小さくない」（!<）は「より大きいか等しい」（>=）とまったく同じ

これは「等しくない」（!=）には適用されません。同じ意味の演算子はありません。

したがって、変更を加えると、言語はより複雑になり、メリットはありません。

!<はと同義>=です。後は、明確に定義された数学記号を入力する方法です≥。話されている言語で「より小さくない」が使用されていることは正しいですが、口語的であいまいな場合があります（解釈≥または誤解される可能性があります>）。一方、プログラミングと数学では、明確に定義された明確な用語を使用します。

ANSI SQLなどの3値ロジックでも、not x < yはどちらかまたはである場合x >= yに両方とも与えられるため、と同等です。ただし、ANSIに準拠していないSQL方言がありますが、同等ではありません。NULLxyNULL!<

Transact-SQLには！>（より大きくない）および！<（より小さくない）演算子があります。

それで、あなた以外で、Sybase Microsoftの誰かもそれが良い考えだと思いました。Microsoft Bobのように！:)

答えは、単に!<オペレーターは必要ないということだと思います。あなたは、あなたの質問に指摘したようにそこに既にある>=と<=既存の式を否定する可能性とともに、なぜ別のオペレータを追加しますか？

RFC 1925から

追加するものが何も残っていないときではなく、奪うものが残っていないとき、完璧に達しました。

既存の機能を複製する追加の演算子を追加しても、言語（およびトークナイザーとパーサー）に（不必要な）複雑さを追加する以外は何もしません。

また、演算子のオーバーロードが可能な言語では、さらに別の演算子をオーバーロードする必要があります。際の混乱を考えてみましょうbool operator<=とbool operator!>（はい、私は1つが既に矛盾比較を行うことができます知っている）異なるものを返すことができます。

最後に、メソッドまたは演算子が複数定義されている言語（Ruby-私はあなたを見ている）を考えてみてください。あるプログラマが<=を使用し、別のプログラマが！>を使用し、同じ式に対して複数のコードスタイルがあります。

すべての言語が最初に正の演算子を実装し、次に負の演算子にアプローチするため、2番目のものが最初ではないのはなぜですか？そして、それらは冗長であると思い、それらをスキップします。

常にポジティブなケースを最初に実装してから、ネガティブなケースに進んでください（:)ポジティブ思考、私個人の見解のみ）

理由は、プログラミング言語の演算子は数学の伝統から借用し、数学では「小さくない」と「小さくない」が同じように働くので、誰も「大きくない」と「小さくない」を使用するからです。

したがって、プログラミング言語では通常、等しくないために≠のように見えるシンボルを取得します（!=または/=、誰かが空想<>またはテキスト演算子でない限り）

および≤および≥（<=および>=）のように見えるもの

ところで、私はあなたの主張に同意しません。それは理解するのがより簡単であり、ORについては推論するということです。数学では、多くの否定（不合理な還元など）を伴う証明は、より直接的な代替手段がある場合、通常は眉をひそめます。また、順序付けの場合、私たちが持っている（そして何かを考えたり証明するときに使われる）基本的な知識は、<、=、>の間の三分法なので、！<ステートメントは、おそらく> =それに役立つもの。

アセンブリ命令セットを部分的に非難します。jge「以上の場合はジャンプ」などの指示があります。「より小さくない場合はジャンプ」とは対照的。

コンパイラライターは、アセンブリライターが思いついたものから脱却した可能性があります。これは、おそらくチップ上で設計されたときにラベルが付けられた方法に基づいていました。

...おそらく。

数年前に、!=演算子（等しくない）の代わりに、次のようなもの<>が使用されていた言語を見たと思います。しかし、彼らの名前を思い出せません...

私はそれを読むのが困難だと思います!(a < b)かa !< bよりもa >= b。おそらく!<それが使用されない理由です（私の意見では見苦しいです）。