Çoğu programlama dilinin '!>' (Daha büyük değil) ve '! <' (En az değil) operatörlerinin olmamasının herhangi bir nedeni var mı?

Herhangi bir sebep olup olmadığını merak ediyorum - ya da sadece bir tarih kazasıysa - çoğu programlama dilinde hiç kimse !>ve !<operatör yok mu?

a >= b (daha büyük VEYA b eşittir) olarak yazılmış olabilir !(a < b) (bir DEĞİLDİR az b) , yani eşittir a !< b.

Bu soru bana kendi ifade ağacı kurucumu kodlamanın ortasındayken çarptı. Çoğu programlama dilinin a != boperatörü var !(a=b), öyleyse neden hayır !>ve !<?

GÜNCELLEŞTİRME:

• !<(daha az değil) telaffuz etmekten daha kolay>= (daha büyük veya eşittir)
• !<(daha az değil) tipinden daha kısadır>= (daha büyük veya eşittir)
• !<(değil az) 'dir * anlamak daha kolay daha >=(büyük veya eşittir)

* çünkü ORikili operatör beynin iki operand kullanması gerekir (rende, eşittir), NOTunary operatör iken beynin sadece bir operandla (daha küçük) çalışması gerekir.

D programlama dili ve DMC'nin uzatma C ve C ++ için bu operatörlere (hepsi 14 kombinasyonların) desteklemek, ama ilginçtir, D bu operatörleri kaldırmayı gidiyor başlıca nedeni,

1. tam olarak nedir a !< b? Öyle a>=b || isNaN(a) || isNaN(b). !<olduğu değil aynı >=çünkü NaN !< NaNgerçek varken NaN >= NaNyanlıştır. IEEE 754'ün ustalaşması zordur , bu yüzden a !< bkullanımı sadece NaN kullanımıyla ilgili karışıklığa neden olacaktır - Phobos'da (D'nin standart kütüphanesi) bu tür operatörleri arayabilirsiniz ve NaN'ın okuyucuna katıldığı okuyucuları hatırlatmak için bir çok kullanımın yanında yorum bulunmaktadır.
2. bu nedenle, bu tür operatörler D'deki gibi olsa bile, birkaç kişi onu kullanacak,
3. ve bu nadiren kullanılan operatörler için derleyiciyi çok az fayda sağlayacak şekilde karmaşıklaştıran 8 belirteç daha tanımlamak zorundadır.
4. ve bu operatörler olmadan kişi yine de eşdeğerini kullanabilir !(a < b)veya biri açık olmayı seviyorsa a >= b || isNaN(a) || isNaN(b)ve okunması daha kolaydır.

Ayrıca, ilişkiler (≮, ≯, ≰, ≱), !=(≠) veya >=(≥) aksine, temel matematikte nadiren görülür , bu yüzden birçok insan için anlaşılması zordur .

Bunlar muhtemelen çoğu dilin onları desteklememesinin sebepleridir.

Çünkü aynı anlamı taşıyan iki farklı operatöre sahip olmak pek mantıklı değil.

• “Daha büyük değil” ( !>) “daha ​​az ya da eşit” ile aynıdır ( <=)
• “Daha az değil” ( !<) “büyük ya da eşit” ( >=) ile tamamen aynıdır.

Bu “eşit değil” ( !=) için geçerli değildir , aynı anlama sahip bir operatör yoktur.

Bu yüzden, modifikasyonunuz dili hiçbir faydası olmadan daha karmaşık hale getirecek.

!<ile eşanlamlıdır >=. Daha sonra sadece iyi tanımlanmış bir matematik sembolünü yazmanın bir yoludur ≥. Konuşulan dilde "az olmamakla birlikte " haklısın , ancak konuşmacı ve belirsiz olabiliyor (olarak yorumlanabilir ≥veya yanlış yorumlanabilir >). Öte yandan, programlama ve matematik açıkça tanımlanmış, açık olmayan bir terminoloji kullanır.

Hatta örneğin ANSI SQL gibi 3 değerli mantık, içinde, not x < yeşdeğer x >= yoldukları gibi hem vermek, NULLeğer ikisinden biri xya da ybir NULL. Bununla birlikte, ANSI uyumlu olmayan SQL lehçeleri vardır, burada eşdeğer değildir ve ellerinde vardır!< .

Transact-SQL, !> (Büyük değil) ve ! <(Küçük değil) operatörlerine sahiptir.

Bu yüzden, sizden başka, Sybase Microsoft'taki bir kişi de bunun iyi bir fikir olacağını düşündü. Tıpkı Microsoft Bob gibi! :)

Bence cevap basitçe bir !<operatöre gerek yok . Sorunuzda belirttiğiniz gibi, mevcut bir ifadeyi reddetme olasılığı zaten var >=ve <=neden başka bir operatör eklesin?

RFC 1925'ten itibaren

mükemmelliğe, eklenecek bir şey kalmadığında değil, alınacak bir şey kalmadığında ulaşıldı.

Var olan işlevselliği çoğaltan ek operatörler eklemek, diline (gereksiz) karmaşıklık eklemekten başka bir şey yapmaz (ve böylece belirteç ve ayrıştırıcı).

Operatör aşırı yüklenmesinin mümkün olduğu dillerde de düşünün, aşırı yüklenecek başka bir operatörünüz daha olacaktı. Farklı şeylerin ne zaman bool operator<=ve ne zaman ortaya bool operator!>çıkabileceği konusundaki karışıklığı düşünün (evet, birinin zaten karşılaştırmalı karşılaştırmalar yapabileceğini biliyorum).

Son olarak, yöntemler veya operatörler çarpın tanımlanan dillerin düşünüyorum (Yakut - Ben bakıyorum senin ) ile bir programcı kim kullanımları vardır <= Başka kullanır iken!> Ve aynı ifadesi için birden fazla kod stilleri var.

. ve gereksiz olduğunu düşündüm ve onları atlamak.

Daima önce pozitif durumu uygulamaya çalışın, sonra negatif duruma gidin (:) pozitif düşünme, sadece kişisel görüşüm)

Bunun nedeni, programlama dillerindeki operatörlerin matematik geleneğinden ödünç aldıkları ve matematikteki hiç kimsenin, "küçük veya eşit" ve "büyük veya eşit" olmalarının, bir iş kadar iyi olmaları nedeniyle "büyük değil" ve "küçük değil" kullanmalarıdır.

Yani dilleri Programlama biz genellikle (eşittir değil ≠ sembolü gibi bakıyor olsun !=ya /=, sürece birileri ile fantezi olmaktan eğer <>veya metinsel operatör)

ve ≤ ve ≥ ( <=ve >=) gibi görünen şeyler

BTW, OR'dan daha kolay anlaşılması ve sebep olmadığını iddia ettiğine katılıyorum. Matematikte, eğer daha doğrudan bir alternatif varsa, çok fazla olumsuzlama içeren deliller (saçma azalması gibi) genellikle kaşlarını çattı. Ayrıca, sipariş durumunda, sahip olduğumuz (ve bir şeyi düşünürken ya da kanıtlarken kullanılan) temel bilgi, <, = ve> arasındaki traktomidir, yani herhangi bir! onunla faydalı bir şey.

Montaj talimat setini kısmen suçluyordum. jge"Eğer büyük veya eşit ise zıpla" gibi talimatlara sahipsiniz . "En az değilse atla" nın aksine.

Derleyici yazarlar, hangi çipte tasarlanırken nasıl etiketlendiğine dayanarak hangi montaj yazarlarının ortaya çıktığından kurtulmuş olabilir.

... Olabilir.

Sanırım birkaç yıl önce, !=operatör yerine (eşit değil), bunun gibi bir <>şeyin kullanıldığı bazı dilleri gördüm . İsimlerini hatırlayamıyorum ama ...

Ben okumak zor olduğunu düşünüyorum !(a < b)ya a !< bdaha a >= b. Muhtemelen !<kullanılmamasının nedeni budur (bence çirkin görünüyor).