대부분의 프로그래밍 언어에 '!>'(보다 크지 않음) 및 '! <'(보다 작지 않은) 연산자가없는 이유가 있습니까?

또는 역사의 단지 사고없는 경우 - - 더 있다는 것을 나는 어떤 이유가 궁금 !>와 !<에 사업자 대부분의 프로그래밍 언어?

a >= b (a는 OR과 b가 같다) 는 !(a < b) (a NOT b) 와 같이 쓸 수있다 a !< b.

이 질문은 식 트리 빌더를 코딩하는 중이었습니다. 대부분의 프로그래밍 언어에는에 a != b대한 연산자가 !(a=b)있으므로 왜 아니오 !>와 !<?

최신 정보:

• !<( 보다 작거나) 발음하기 가 >=(더 크거나 같음) 보다 쉽습니다.
• !<(보다 작지 않은) 유형 보다 짧>= 거나 (보다 크거나 같음)
• !<(안 적은)가 * 이해하기 쉽고 보다 >=(크거나 같음)

* OR두 개의 연산자 (두 번째 피연산자)를 조작해야하는 이진 연산자 이기 때문에 NOT단항 연산자는 하나의 피연산자 (보다 작음) 만 사용해야합니다.

D 프로그래밍 언어 와 DMC의 확장 C 및 C ++에 이러한 사업자 (모두 14 조합)을 지원했지만 흥미롭게도, D는 이러한 연산자를 중단 한 것입니다 주로하기 때문에,

1. 정확히 무엇 a !< b입니까? 입니다 a>=b || isNaN(a) || isNaN(b). !<와 같지 않습니다 . >=왜냐하면 NaN !< NaNtrue NaN >= NaN는 거짓 이기 때문 입니다 . IEEE 754는 마스터하기 가 어렵 기 때문에를 사용 a !< b하면 NaN 처리에 대한 혼란이 발생할 수 있습니다. Phobos (D의 표준 라이브러리)에서 이러한 연산자를 검색 할 수 있으며 NaN이 관련된 독자를 상기시키기 위해 그 옆에 주석이 많이 사용됩니다.
2. 따라서 D와 같은 연산자가 존재하더라도이를 사용하는 사람은 거의 없습니다.
3. 드물게 사용되는이 연산자들에 대해 8 개의 토큰을 더 정의해야하는데, 이로 인해 컴파일러는 별다른 이점을 얻지 못합니다.
4. 그리고 이러한 연산자가 !(a < b)없다면 , 동등한 연산자를 사용 하거나 명시적인 것을 좋아한다면 a >= b || isNaN(a) || isNaN(b)읽기가 더 쉽습니다.

또한 관계 (≮, ≯, ≰, ≱)는 !=(≠) 또는 >=(≥) 와 달리 기본 수학에서는 거의 보이지 않으므로 많은 사람들이 이해하기 어렵 습니다.

아마도 대부분의 언어가이를 지원하지 않는 이유 일 수도 있습니다.

정확히 동일한 의미를 가진 두 개의 서로 다른 연산자를 갖는 것은 의미가 없기 때문입니다.

• "더 크지 않음"( !>)은 "작거나 같음"( <=) 과 정확히 동일합니다.
• "더 작지 않음"( !<)은 "더 크거나 같음"( >=) 과 정확히 동일합니다.

이는 "같지 않음"( !=) 에는 적용되지 않으며 동일한 의미를 가진 연산자가 없습니다.

따라서 수정하면 아무런 이점없이 언어가 더 복잡해집니다.

!<와 동의어입니다 >=. 나중에 잘 정의 된 수학 기호를 입력하는 방법입니다 ≥. 당신이 바로 점이다 "이하보다" 그러나 그것은 (해석 될 수 구어체이고 모호 할 수 있으며, 음성 언어로 사용 ≥하거나 잘못 해석 >). 반면에 프로그래밍과 수학은 명확하게 정의 된 명확한 용어를 사용합니다.

심지어 ANSI SQL 같은 3 치 논리에서 not x < y의 동등한 x >= y들이 모두 같은 보내기 NULL경우 하나 x또는 y이다 NULL. 그러나, 그것은 동일하지 어디, 비 ANSI 준수 SQL 언어이며, 그들은 해야합니까!< .

Transact-SQL에는 !> (이하) 및 ! <(이하) 연산자가 있습니다.

따라서 Sybase Microsoft 직원 중 누군가는 이것이 좋은 아이디어라고 생각했습니다. Microsoft Bob처럼! :)

답은 단순히 !<운영자 가 필요 없다는 것 입니다. 질문에서 지적했듯이 기존 표현을 부정 할 가능성 이 이미 >=있으며 <=왜 다른 연산자를 추가해야합니까?

에서 RFC 1925

추가 할 항목이 없을 때가 아니라 제거 할 항목이 없을 때 완벽에 도달했습니다.

기존 기능을 복제하는 추가 연산자를 추가해도 언어에 불필요한 (필요하지 않은) 복잡성 (토큰 라이저 및 구문 분석기)을 추가하는 것 외에 다른 작업은 수행하지 않습니다.

연산자 오버로드가 가능한 언어에서도 다른 연산자를 오버로드해야합니다. 때 혼란을 고려 bool operator<=하고 bool operator!>(예, 나는이 아직 일치 비교를 할 수있어) 다른 일을 반환 할 수 있습니다.

마지막으로, 메소드 또는 연산자가 여러 개 정의 된 언어를 생각하고 (Ruby-당신을보고 있습니다 ) <=를 사용하는 반면 다른 사람은!>를 사용하는 한 프로그래머가 있고 동일한 표현식에 대해 여러 코드 스타일이 있습니다.

! <는> =와 같습니다. 이제 모든 언어가 먼저 양수 연산자를 구현 한 다음 음수 연산자에 접근하기 때문에 두 번째가 아닌 이유는 무엇입니까? 중복 될 것이라고 생각하고 건너 뜁니다.

항상 긍정적 인 사례를 먼저 구현 한 다음 부정적인 사례로 이동하십시오 (:) 긍정적 사고, 나만의 견해 만)

그 이유는 프로그래밍 언어의 연산자가 수학적 전통에서 빌려 왔고 수학에서 "더 작거나 같음"과 "더 크거나 같음"이 직업만큼 좋은 것이기 때문에 "실제로 크지 않은"과 "작지 않은"을 사용하는 사람이 없기 때문입니다.

따라서 프로그래밍 언어에서는 일반적으로 같지 않은 ≠ 같은 기호를 얻습니다 ( !=또는 /=누군가 <>가 텍스트 연산자를 사용하지 않는 한 )

≤ 및 ≥ ( <=and >=) 처럼 보이는 것들

Btw, 나는 이해하기가 더 간단하지 않다는 OR의 주장에 동의하지 않습니다. 수학에서, 더 직접적인 대안이 있다면, 많은 부정과 관련된 증거 (부조리로의 축소와 같은)는 대개 눈살을 찌푸리게합니다. 또한 주문의 경우, 우리가 가지고있는 기본적인 지식 (그리고 무언가를 생각하거나 증명할 때 사용되는)은 <, =와> 사이의 3 인법이므로! <문은> =로 변환해야합니다. 유용한 것.

어셈블리 명령 세트를 부분적으로 비난했습니다. jge"크거나 같으면 점프" 와 같은 지침이 있습니다. "보다 작 으면 점프"와 반대로.

컴파일러 라이터는 어셈블리 라이터의 구성 요소를 제거했을 수 있습니다. 이는 아마도 칩에서 설계 될 때 어떻게 레이블이 지정되었는지에 기초한 것입니다.

...혹시.

나는 몇 년 전에 !=연산자 (같지 않음) 대신에 비슷한 <>것이 사용되는 언어를 보았습니다 . 그래도 그들의 이름을 기억할 수 없습니다 ...

!(a < b)또는 a !< b보다 읽기가 어렵다고 생각합니다 a >= b. 아마도 이것이 !<사용되지 않는 이유 일 것입니다 (제 의견으로는 추악하게 보임).