web-dev-qa-db-ja.com

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

mostプログラミング言語には_!>_演算子と_!<_演算子がないため、何らかの理由があるのか​​、それとも単なる歴史の偶然なのかと思います。 ？

_a >= b_（a greater OR equals b）は!(a < b)（aより小さいb）、_a !< b_と等しい。

この質問は、自分の式ツリービルダーをコーディングしている最中に、私を驚かせました。ほとんどのプログラミング言語には、!(a=b)の_a != b_演算子があるので、なぜ_!>_および_!<_がないのですか？

更新：

  • _!<_（より小さくない）は読みやすい _>=_よりも大きい（またはより大きい）
  • _!<_（より小さくない）はタイプより短い _>=_よりも大きい（または等しい）
  • _!<_（より小さくない）は理解しやすい*よりも_>=_（より大きいまたは等しい）

* ORは2つのオペランド（grater、equals）を演算する必要がある2項演算子なので、NOTは単項演算子であり、1つのオペランド（少ない）のみを演算する必要があるためです。

syntaxcomparisonoperators
28
Alex Burtsev

CおよびC++への Dプログラミング言語 および DMCの拡張 はこれらの演算子（それらの14の組み合わせすべて）をサポートしていましたが、興味深いことに、D これらは非推奨になる予定です）演算子 、主に

  1. 正確には_a !< b_とは何ですか？ a>=b || isNaN(a) || isNaN(b)です。 _!<_はtrueであるのに対して_>=_はfalseであるため、_NaN !< NaN_は_NaN >= NaN_と同じではありません。 IEEE 754はマスターするのにhardなので、_a !< b_を使用してNaN処理で混乱を招くだけです。Phobos（Dの標準ライブラリ）でそのような演算子を検索できます。 NaNが関係していることを読者に思い出させるために、かなり多くの使用法の横にコメントがあります。
  2. したがって、このような演算子がDのように存在していても、それを使用する人はほとんどいません。
  3. これらのめったに使用されない演算子に対して8つのトークンをさらに定義する必要があり、コンパイラーを複雑にしてほとんど利点がありません。
  4. これらの演算子がなくても、同等の!(a < b)を使用するか、明示的にしたい場合はa >= b || isNaN(a) || isNaN(b)を使用できます。

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

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

84
kennytm

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

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

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

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

47
svick

!<は>=と同義です。その後は、明確に定義された数学記号≥を入力する方法にすぎません。 「以上」が話されている言語で使用されているのは正しいですが、口語的であいまいな場合があります（≥と解釈できるか、 >）と誤って解釈されます。一方、プログラミングと数学では、明確に定義された明確な用語を使用します。

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

10
vartec

Transact-SQLには ！>（以下） および ！<（以上） 演算子があります。

だから、あなた以外の誰か Sybase マイクロソフトもそれが良いアイデアだと思った。 Microsoft Bobのように！ :)

8
yannis

答えは単に!<演算子。あなたの質問で指摘したように、すでに>=および<=既存の式を無効にする可能性があるので、なぜ別の演算子を追加するのですか？

4
Bryan Oakley

から RFC 1925

追加するものが残っていないときではなく、削除するものが残っていないときに完全に達しています。

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

演算子のオーバーロードが可能な言語では、さらに別の演算子をオーバーロードする必要があります。 bool operator<=およびbool operator!>は異なるものを返す可能性があります（そうです、私はすでに矛盾した比較を行うことができることを知っています）。

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

4
user40980

！<は> =に等しい> =すべての言語が最初に正の演算子を実装し、次に負の演算子にアプローチするため、最初ではなく2番目のものがあるので、> =の実装は！<および<=をカバーするため、！>そして、それらは冗長であり、それらをスキップすると思いました。

常にポジティブケースを最初に実装してから、ネガティブケース（:)ポジティブシンキングに進んでください。

3
Notepad

その理由は、プログラミング言語の演算子は数学の伝統から借用し、数学では「小さいか等しい」と「大きいか等しい」は同じように機能するため、実際には「大きくない」と「小さくない」を使用しないためです。

したがって、プログラミング言語では通常、等しくない（!=または/=、誰かが<>またはテキスト演算子）

≤や≥（<=および>=）

ところで、私はあなたの主張に同意しません。数学では、多くの否定を含む証明（ばかげたことへの削減など）は、より直接的な代替手段が利用可能であれば、通常は嫌われます。また、注文の場合、私たちが持っている基本的な知識（そして何かを考えたり証明したりするときに使用されます）は<、=と>の間の三分法であるため、必要な場合は！<ステートメントを> =に変換する必要がありますそれで便利なもの。

2
hugomg

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

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

...たぶん。

2
Ed Marty

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

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

1
Radu Murzea