Có bất kỳ lý do tại sao hầu hết các ngôn ngữ lập trình không có toán tử '!>' (Không lớn hơn) và '! <' (Không ít hơn)?


28

Tôi tự hỏi liệu có bất kỳ lý do - hoặc nếu đó chỉ là một tai nạn của lịch sử - rằng không có !>và các !<nhà khai thác trong hầu hết các ngôn ngữ lập trình?

a >= b (một OR lớn hơn bằng b) có thể được viết là !(a < b) (a KHÔNG nhỏ hơn b) , bằng a !< b.

Câu hỏi này đánh tôi khi tôi đang viết mã cho người xây dựng cây biểu hiện của riêng tôi. Hầu hết các ngôn ngữ lập trình đều có a != btoán tử cho !(a=b), vậy tại sao không !>!<?

CẬP NHẬT:

  • !<(không nhỏ hơn) dễ phát âm hơn >=(lớn hơn hoặc bằng)
  • !<(không nhỏ hơn) ngắn hơn để gõ hơn >=(lớn hơn hoặc bằng)
  • !<(không ít hơn) dễ hiểu * hơn >=(lớn hơn hoặc bằng)

* bởi vì ORlà toán tử nhị phân mà não bạn cần để vận hành hai toán hạng (vắt, bằng), trong khi đó NOTlà toán tử đơn nguyên và não bạn chỉ cần hoạt động với một toán hạng (nhỏ hơn).


3
không nhất thiết phải dễ phát âm hơn trong mọi ngôn ngữ. Ví dụ, trong tiếng Đức, chúng tôi nói "größer / gleich", tôi chưa bao giờ nghe "nicht kleiner".
Ingo

1
Đối số dễ hiểu hơn cũng không giữ nước. Bạn phải vận hành 2 toán hạng trong cả hai trường hợp, vì điều này là bình thường với các toán tử quan hệ. Hơn nữa, bạn chỉ đơn giản cho rằng bộ não có thể hoạt động dễ dàng hơn trên 1 toán hạng thay vì 2. Đỗ bạn có bất kỳ bằng chứng cho điều đó từ các lĩnh vực khoa học thần kinh?
Ingo

Câu trả lời:


84

Các ngôn ngữ lập trình Dmở rộng DMC của C và C ++ đã hỗ trợ các nhà khai thác (tất cả 14 kết hợp của chúng), nhưng điều thú vị, D sẽ không chấp các nhà khai thác , chủ yếu là do

  1. chính xác là a !< bgì Đó là a>=b || isNaN(a) || isNaN(b). !<không giống như >=, bởi vì NaN !< NaNlà trong khi sự thật NaN >= NaNlà sai. IEEE 754 khó thành thạo, do đó, việc sử dụng a !< bsẽ gây nhầm lẫn cho việc xử lý NaN - bạn có thể tìm kiếm các toán tử như vậy trong Phobos (thư viện chuẩn của D) và khá nhiều sử dụng có bình luận bên cạnh để nhắc nhở độc giả có liên quan đến NaN,
  2. do đó, ít người sẽ sử dụng nó, ngay cả khi các toán tử như vậy tồn tại như trong D,
  3. và người ta phải xác định thêm 8 mã thông báo cho các toán tử ít được sử dụng này, điều này làm phức tạp trình biên dịch vì lợi ích rất ít,
  4. và không có các toán tử đó, người ta vẫn có thể sử dụng tương đương !(a < b)hoặc nếu một người thích rõ ràng a >= b || isNaN(a) || isNaN(b)và họ dễ đọc hơn.

Bên cạnh đó, các mối quan hệ (≮, ≯,,) hiếm khi được nhìn thấy trong toán học cơ bản, không giống như !=(≠) hoặc >=(), vì vậy rất khó hiểu đối với nhiều người.

Đây có lẽ cũng là lý do tại sao hầu hết các ngôn ngữ không hỗ trợ chúng.


seldomly seen in basic math- thích hơn, chưa từng thấy. Chúng ta học lại môn đại số để chỉ lật nó sang một phép toán tương đương (đặc biệt là từ khi NaNkhông xuất hiện trong toán học cơ bản)
Izkata

IMHO thực sự cần thiết là một phương tiện khai báo các biến hoạt động như double ngoại trừNaN hành vi của chúng . Trong nhiều trường hợp, mã có thể thực hiện bất kỳ loại so sánh nào NaNsẽ muốn NaNso sánh lớn hơn mọi thứ, so sánh nó nhỏ hơn mọi thứ hoặc đưa ra một ngoại lệ đối với nỗ lực so sánh. Cho phép mã để chỉ định khai báo như thế nào NaNsẽ được xem xét sẽ làm giảm nhu cầu sử dụng mã bắt buộc để đạt được hành vi chính xác.
supercat

@supercat: Bạn có thể thực hiện các thao tác NaN để ném ngoại lệ bằng các <fenv.h>hàm như fesetexceptflag.
kennytm

@KennyTM: Phải đặt cờ trước khi thực hiện một thao tác và bỏ đặt nó sau khi có vẻ khó hiểu và dễ gặp rắc rối, và nó không giải quyết được khả năng muốn áp đặt toàn bộ đơn hàng. IEEE từ những gì tôi hiểu vừa giới thiệu một số phương pháp so sánh mới sẽ áp đặt tổng đơn hàng, tôi sẽ xem xét việc chào đón nếu thay đổi quá hạn; Sẽ rất thú vị để xem các ngôn ngữ phản ứng như thế nào.
supercat

47

Bởi vì nó không có ý nghĩa gì khi có hai toán tử khác nhau có cùng một nghĩa.

  • Càng không lớn thì càng tốt !>( <=)
  • “Không ít” ( !<) là chính xác giống như “lớn hơn hoặc bằng” ( >=)

Điều này không áp dụng cho những người khác không bằng cách dùng ( !=), không có toán tử nào có cùng ý nghĩa.

Vì vậy, sửa đổi của bạn sẽ làm cho ngôn ngữ phức tạp hơn mà không có lợi ích.


5
Thế còn x = x + 1, x += 1x++?

33
@dunsmoreb: Không ai trong số đó là điều tương tự. Chỉ có một phục vụ cho mục đích "gia tăng". Việc bạn đã tận dụng hai biểu thức kia để phục vụ cho cùng một mục đích là không liên quan - cả hai đều chung chung hơn nhiều.
DeadMG

1
<>là một toán tử có cùng ý nghĩa !=và Python 2 có cả hai.
krlmlr

9
@ user946850 Và khi cả hai hiện đang coi một sai lầm, sử dụng <>đã bị phản đối trong một thời gian dài và nó lấy ra từ 3,0 (và tâm trí bạn, các 2.x cuối cùng phát hành bao giờ , 2.7, được phát hành vào mùa hè năm 2010).

3
@svick Điều này làm cho toán tử ++ trở nên tuyệt vời hơn nữa, nó sẽ ngăn những lập trình viên C # đến đây, đưa ra các giả định hợp lý về hành vi của chương trình, sau đó đánh cắp công việc lập trình viên C ++ của tôi!

10

!<đồng nghĩa với >=. Sau đó chỉ là một cách gõ biểu tượng toán học được xác định rõ . Bạn đúng rằng "không ít hơn" được sử dụng trong ngôn ngữ nói, tuy nhiên nó thông tục và có thể mơ hồ (có thể được hiểu hoặc hiểu sai là >). Mặt khác, lập trình và sử dụng toán học được xác định rõ ràng, thuật ngữ rõ ràng.

Ngay cả trong logic 3 giá trị, như ANSI SQL, not x < ycũng tương đương x >= y, vì cả hai đều đưa ra NULLnếu một trong hai xhoặc yNULL. Tuy nhiên, có các phương ngữ SQL không tuân thủ ANSI, trong đó nó không tương đương và chúng !< .


10
Tuy nhiên, chúng thường không tương đương khi sử dụng số dấu phẩy động. Ví dụ, so sánh bất cứ điều gì với NaNlà sai, vì vậy !(2 < NaN) == true, trong khi (2 >= NaN) == false.
hammar

@hammar: Đúng, nhưng điều đó đúng với tất cả các mối quan hệ số học xung quanh NaNs. Tất cả đều ngừng cư xử bình thường.
Nicol Bolas

@hammar - đây là lỗi dấu phẩy động, nó chỉ không thực hiện đúng Ord, có thể nói như vậy. Tuy nhiên, đây không phải là một vấn đề lớn vì không ai bắt chúng tôi phải thực hiện a !< b = not (a < b), chúng tôi chỉ có thể nói (! <) = (> =).
Ingo

8

Transact-SQL có các toán tử !> (Không lớn hơn)! <(Không nhỏ hơn) .

Vì vậy, ngoài bạn, một người nào đó tại Sybase Microsoft cũng nghĩ rằng đó sẽ là một ý tưởng tốt. Giống như Microsoft Bob! :)


Điều này không được thêm vào năm 2005 sao?
JeffO

5
Có rất nhiều người điên khuyên trong thế giới này không đơn độc trong việc đồng ý với nhau, đồng thuận! = chính xác.

@JeffO Vậy thì chúng ta nên đổ lỗi cho Microsoft chứ không phải Sybase?
yannis

Hấp dẫn. Tôi tò mò về câu chuyện đằng sau này.
Surfasb

@surfasb Yeap, tôi cũng vậy. Tôi đoán là nó chỉ là đường cú pháp, không có gì đặc biệt về nó.
yannis

4

Tôi nghĩ rằng câu trả lời đơn giản là không cần người !<vận hành. Như bạn đã chỉ ra trong câu hỏi của mình, đã có >=<=cùng với khả năng phủ định một biểu thức hiện có, vậy tại sao lại thêm một toán tử khác?


Tôi đồng ý rằng không có điểm nào trong việc thêm toán tử làm điều tương tự, nhưng tại sao "họ" lại chọn> = thay vì! <, Việc phát âm KHÔNG BẮT ĐẦU, sau đó là TUYỆT VỜI HOẶC THIẾT BỊ, việc gõ ngắn hơn, dễ dàng hơn não để hiểu.
Alex Burtsev

!<không ngắn hơn để gõ hơn >=, hoặc tôi đang thiếu một cái gì đó?
Bryan Oakley

Tôi có nghĩa là nó đại diện văn bản (văn bản phát âm).
Alex Burtsev

4

Từ RFC 1925

sự hoàn hảo đã đạt được không phải khi không còn gì để thêm, mà là khi không còn gì để lấy đi.

Thêm các toán tử bổ sung sao chép chức năng hiện có sẽ không làm gì khác ngoài việc thêm độ phức tạp (không cần thiết) vào ngôn ngữ (và do đó là mã thông báo và trình phân tích cú pháp).

Cũng xem xét trong các ngôn ngữ có thể quá tải toán tử, bạn sẽ có một toán tử khác để quá tải. Hãy xem xét sự nhầm lẫn khi bool operator<=bool operator!>có thể trả lại những thứ khác nhau (vâng, tôi biết người ta đã có thể so sánh không nhất quán).

Cuối cùng, hãy nghĩ về các ngôn ngữ nơi các phương thức hoặc toán tử được xác định nhân (Ruby - tôi đang nhìn bạn ) và bạn có một lập trình viên sử dụng <= trong khi một cách sử dụng khác!> Và bạn có nhiều kiểu mã cho cùng một biểu thức.


Vâng! Đó là nguyên tắc của Parsimony khoa học.
luser droog

3

! <bằng với> = Bây giờ tại sao chúng ta có cái thứ hai chứ không phải đầu tiên bởi vì tất cả ngôn ngữ triển khai toán tử dương trước rồi tiếp cận với toán tử phủ định, Khi triển khai> = cũng bao gồm! <và <= cover!>. Vì vậy, người tạo ngôn ngữ đi đến những thứ này và nghĩ rằng họ sẽ dư thừa và bỏ qua chúng.

Luôn cố gắng thực hiện trường hợp tích cực trước rồi đến trường hợp tiêu cực (:) suy nghĩ tích cực, tôi chỉ xem cá nhân)


2

Lý do là các toán tử trong các ngôn ngữ lập trình mượn từ truyền thống toán học và trong toán học thực sự không sử dụng "không lớn hơn" và "không nhỏ hơn" vì "nhỏ hơn hoặc bằng" và "lớn hơn hoặc bằng" làm tốt như một công việc.

Vì vậy, trong các ngôn ngữ lập trình, chúng ta thường có một biểu tượng trông giống như ≠ vì không bằng ( !=hoặc /=, trừ khi có ai đó nếu thích với <>hoặc một toán tử văn bản)

và những thứ trông giống như và ( <=>=)


Btw, tôi không đồng ý với khẳng định của bạn rằng KHÔNG đơn giản hơn để hiểu và lý do về sau đó HOẶC. Trong toán học, các bằng chứng liên quan đến rất nhiều phủ định (như giảm đến vô lý) thường được tán thành nếu có một giải pháp thay thế trực tiếp hơn. Ngoài ra, trong trường hợp đặt hàng, kiến ​​thức cơ bản mà chúng ta có (và được sử dụng khi suy nghĩ hoặc chứng minh điều gì đó) là cách phân chia giữa <, = và> vì vậy bất kỳ câu lệnh nào <có thể phải được chuyển đổi thành> = nếu bạn muốn làm bất cứ điều gì hữu ích với nó.


2

Tôi đã đổ lỗi một phần cho bộ hướng dẫn lắp ráp. Bạn đã có các hướng dẫn như jge"nhảy nếu lớn hơn hoặc bằng". Trái ngược với "nhảy nếu không ít hơn".

Các nhà văn biên dịch có thể đã bỏ qua những gì các nhà văn lắp ráp đã đưa ra, có lẽ dựa trên cách nó được dán nhãn khi được thiết kế trên chip.

... Có thể.


1

Tôi nghĩ rằng tôi đã thấy một số ngôn ngữ một vài năm trước đây, thay vì !=toán tử (không bằng), một cái gì đó giống như <>đã được sử dụng. Không thể nhớ tên của họ, mặc dù ...

Tôi nghĩ rằng nó khó đọc hơn !(a < b)hoặc a !< bhơn a >= b. Có lẽ đó là lý do tại sao !<nó không được sử dụng (theo quan điểm của tôi nó trông xấu xí).


1
<>là (was?) chủ yếu được sử dụng bởi các phương ngữ BASIC, SQL và Pascal.
yannis

@Yannis Rizos cảm ơn đã nhắc nhở. Họ dạy chúng tôi Pascal ở trường trung học và đó là nơi tôi thấy nó :).
Radu Murzea

2
Python 2 cũng có <>, mặc dù nó đã bị xóa trong 3.
Daniel Lubarov

Từ quan điểm logic, !=tổng quát hơn <>, vì bạn có thể có những thứ (như số phức) trong đó đẳng thức được xác định rõ nhưng thực sự không có thứ tự hữu ích.
David Thornley
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.