Y a-t-il une raison pour laquelle la plupart des langages de programmation n'ont pas d'opérateurs '!>' (Pas plus grand que) et '! <' (Pas moins de)?

28

Je me demande s'il y a une raison - ou si c'est juste un accident de l'histoire - qu'il n'y a pas d' opérateurs !>et !<dans la plupart des langages de programmation?

a >= b (un plus grand OU est égal à b) pourrait être écrit comme !(a < b) (un PAS moins b) , qui est égal à a !< b.

Cette question m'a frappé lorsque j'étais en train de coder mon propre constructeur d'arbres d'expression. La plupart des langages de programmation ont un a != bopérateur pour !(a=b), alors pourquoi non !>et !<?

MISE À JOUR:

  • !<(pas moins) est plus facile à prononcer que >=(supérieur ou égal)
  • !<(pas moins) est plus court à taper que >=(supérieur ou égal)
  • !<(pas moins) est plus facile à comprendre * que >=(supérieur ou égal)

* parce que ORc'est un opérateur binaire dont vous avez besoin pour faire fonctionner deux opérandes (râpe, égal), alors que NOTc'est un opérateur unaire et que votre cerveau n'a besoin de fonctionner qu'avec un seul opérande (moins).

syntax comparison operators Alex Burtsev
la source
3
Ce n'est pas nécessairement plus facile à prononcer dans toutes les langues. En allemand, par exemple, nous disons "größer / gleich", je n'ai jamais entendu "nicht kleiner".
Ingo
1
L' argument plus facile à comprendre ne tient pas non plus la route. Vous devez utiliser 2 opérandes dans les deux cas, car cela est normal avec les opérateurs relationnels. De plus, vous supposez simplement que le cerveau peut fonctionner plus facilement sur 1 opérande au lieu de 2. Avez-vous des preuves de cela dans le domaine des neurosciences?
Ingo

Réponses:

84

Le langage de programmation D et l'extension de DMC en C et C ++ ont pris en charge ces opérateurs (les 14 combinaisons d'entre eux), mais il est intéressant de noter que D va déprécier ces opérateurs , principalement parce que

  1. qu'est-ce que c'est exactement a !< b? Ça l'est a>=b || isNaN(a) || isNaN(b). !<n'est pas le même que >=, car NaN !< NaNest vrai tandis que NaN >= NaNest faux. IEEE 754 est difficile à maîtriser, donc l'utilisation de a !< bto causera juste une confusion sur la gestion de NaN - vous pouvez rechercher de tels opérateurs dans Phobos (la bibliothèque standard de D), et un certain nombre d'utilisations ont des commentaires à côté pour rappeler aux lecteurs que NaN est impliqué,
  2. par conséquent, peu de gens l'utiliseront, même si de tels opérateurs existent comme en D,
  3. et il faut définir 8 jetons supplémentaires pour ces opérateurs rarement utilisés, ce qui complique le compilateur pour peu d'avantages,
  4. et sans ces opérateurs, on pourrait toujours utiliser l'équivalent !(a < b), ou si l'on veut être explicite a >= b || isNaN(a) || isNaN(b), et ils sont plus faciles à lire.

De plus, les relations (≮, ≯, ≰, ≱) sont rarement vues en mathématiques de base, contrairement à !=(≠) ou >=(≥), il est donc difficile à comprendre pour beaucoup de gens.

Ce sont probablement aussi les raisons pour lesquelles la plupart des langues ne les prennent pas en charge.

kennytm
la source
seldomly seen in basic math- plus comme, jamais vu. Nous apprenons en algèbre à le retourner à l'équivalent mathématique (d'autant plus qu'il NaNn'apparaît pas dans les mathématiques de base)
Izkata
Ce qui est vraiment nécessaire à mon humble avis est un moyen de déclarer des variables qui se comportent comme un double sauf pour leurs NaNcomportements. Dans de nombreux cas, le code qui pourrait effectuer n'importe quel type de comparaison NaNvoudra avoir une NaNcomparaison plus grande que tout, une comparaison plus petite que tout, ou lever une exception lors de la tentative de comparaison. Le fait de permettre au code de spécifier de manière déclarative la manière dont NaNil convient de considérer réduirait la nécessité d'utiliser du code impératif pour obtenir un comportement correct.
supercat
@supercat: Vous pouvez faire des opérations NaN pour lever des exceptions en utilisant des <fenv.h>fonctions comme fesetexceptflag.
kennytm
@KennyTM: Devoir définir l'indicateur avant d'effectuer une opération et le désactiver après semble icky et sujet à problèmes, et cela n'aborde pas la possibilité de vouloir imposer un ordre total. L'IEEE, d'après ce que je comprends, vient d'introduire de nouvelles méthodes de comparaison qui imposeraient un ordre total, que je considérerais comme un bienvenu en cas de changement en retard; il sera intéressant de voir comment les langues réagissent.
supercat
47

Parce que cela n'a pas beaucoup de sens d'avoir deux opérateurs différents avec exactement la même signification.

  • «Pas plus grand» ( !>) est exactement le même que «inférieur ou égal» ( <=)
  • «Pas moins» ( !<) est exactement le même que «supérieur ou égal» ( >=)

Cela ne s'applique pas à «pas égal» ( !=), il n'y a pas d'opérateur avec la même signification.

Ainsi, votre modification rendrait la langue plus compliquée sans aucun avantage.

svick
la source
5
Qu'en est- il x = x + 1, x += 1et x++?
33
@dunsmoreb: Rien de tout cela n'est la même chose. Un seul sert à «incrémenter». Le fait que vous ayez utilisé les deux autres expressions pour servir le même objectif est sans importance - elles sont toutes les deux beaucoup plus générales.
DeadMG
1
<>est un opérateur ayant la même signification que !=Python 2 et les deux.
krlmlr
9
@ user946850 Et avoir les deux est maintenant largement considéré comme une erreur, l'utilisation de <>est obsolète depuis longtemps et elle est supprimée depuis 3.0 (et rappelez-vous, la dernière version 2.x jamais , 2.7, a été publiée à l'été 2010).
3
@svick Ce qui rend l'opérateur ++ encore plus brillant, il empêchera ces programmeurs C # de venir ici, faisant des hypothèses rationnelles sur le comportement du programme, puis volera mon travail de programmeur C ++!
10

!<est synonyme de >=. Plus tard, ce n'est qu'une façon de taper un symbole mathématique bien défini ≥. Vous avez raison de dire que «pas moins de» est utilisé dans la langue parlée, mais c'est familier et peut être ambigu (peut être interprété ≥ou mal interprété comme >). D'un autre côté, la programmation et les mathématiques utilisent une terminologie clairement définie et sans ambiguïté.

Même dans une logique à 3 valeurs, comme ANSI SQL, not x < yest équivalent à x >= y, car ils donnent tous les deux NULLsi l'un xou l' autre l' yest NULL. Cependant, il existe des dialectes SQL non conformes à ANSI, où ils ne sont!< pas équivalents, et ils en ont .

vartec
la source
10
Cependant, ils ne sont généralement pas équivalents lors de l'utilisation de nombres à virgule flottante. Par exemple, comparer quoi que ce soit avec NaNest faux, alors !(2 < NaN) == true, alors que (2 >= NaN) == false.
hammar
@hammar: C'est vrai, mais c'est vrai pour toutes les relations arithmétiques autour de l' NaNart. Ils arrêtent tous de se comporter normalement.
Nicol Bolas
@hammar - c'est une faute de virgule flottante, ce n'est tout simplement pas correctement implémenter Ord, pour ainsi dire. Ce n'est pourtant pas un gros problème puisque personne ne nous oblige à l'implémenter a !< b = not (a < b), on pourrait juste dire (! <) = (> =).
Ingo
8

Transact-SQL possède les opérateurs !> (Pas plus grand que) et ! <(Pas moins que) .

Donc, à part vous, quelqu'un chez Sybase Microsoft a également pensé que ce serait une bonne idée. Tout comme Microsoft Bob! :)

yannis
la source
N'est-ce pas ajouté dans la v 2005?
JeffO
5
il y a beaucoup de gens fous et mal avisés dans ce monde qui ne sont pas seuls à être d'accord, consensus! = correction.
@JeffO Alors nous devrions blâmer Microsoft, pas Sybase?
yannis
Intéressant. Je suis curieux de l'histoire derrière cela.
surfasb
@surfasb Yeap, moi aussi. Je suppose que c'est juste du sucre syntaxique, rien de spécial à ce sujet.
yannis
4

Je pense que la réponse est simplement qu'il n'y a pas besoin d'un !<opérateur. Comme vous l'avez souligné dans votre question, il existe déjà >=et <=avec la possibilité de nier une expression existante, alors pourquoi ajouter un autre opérateur?

Bryan Oakley
la source
Je suis d'accord qu'il ne sert à rien d'ajouter des opérateurs qui font la même chose, mais pourquoi "ils" ont choisi> = au lieu de! <, Il est beaucoup plus facile de prononcer PAS MOINS, puis PLUS GRAND OU ÉGAL, plus court à taper, c'est plus facile pour cerveau à comprendre.
Alex Burtsev
!<n'est pas plus court à taper que >=, ou manque-t-il quelque chose?
Bryan Oakley
Je voulais dire que c'est une représentation de texte (texte prononcé).
Alex Burtsev
4

De RFC 1925

la perfection a été atteinte non pas quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retirer.

L'ajout d'opérateurs supplémentaires qui dupliquent des fonctionnalités existantes ne fait rien d'autre que d'ajouter de la complexité (inutile) au langage (et donc au tokenizer et à l'analyseur).

Considérez également dans les langues où la surcharge d'opérateur est possible, vous auriez encore un autre opérateur à surcharger. Considérez la confusion quand bool operator<=et bool operator!>pourriez retourner différentes choses (oui, je sais que l'on peut déjà faire des comparaisons incohérentes).

Enfin, pensez des langues où les méthodes ou les opérateurs se multiplient définis (Ruby - Je regarde vous ) et vous avez un programmeur qui utilise <= tout autre utilise!> Et vous avez plusieurs styles de code pour la même expression.


la source
Oui! C'est le principe de la parcimonie scientifique.
luser droog
3

! <est égal à> = Maintenant, pourquoi nous en avons un deuxième pas le premier parce que tout le langage implémente d'abord l'opérateur positif puis l'approche de l'opérateur négatif, comme l'implémentation> = couvre également! <et <= couvre!>. et a pensé qu'ils seraient redondants et les ignorer.

Essayez toujours de mettre en œuvre le cas positif d'abord, puis passez au cas négatif (:) pensée positive, moi uniquement)

Bloc-notes
la source
2

La raison en est que les opérateurs dans les langages de programmation empruntent à la tradition mathématique et en mathématiques personne n'utilise vraiment "pas plus grand" et "pas plus petit" car "plus petit ou égal" et "plus ou moins" font tout aussi bien leur travail.

Donc, dans les langages de programmation, nous obtenons généralement un symbole ressemblant à ≠ pour non égal à ( !=ou /=, à moins que quelqu'un soit fantaisiste <>ou un opérateur textuel)

et des choses qui ressemblent à ≤ et ≥ ( <=et >=)

Btw, je ne suis pas d'accord avec votre affirmation selon laquelle NON est plus simple à comprendre et à raisonner que OU. En mathématiques, les preuves impliquant beaucoup de négations (comme la réduction à l'absurde) sont généralement mal vues s'il existe une alternative plus directe. De plus, dans le cas de la commande, les connaissances de base que nous avons (et qui sont utilisées pour penser ou prouver quelque chose) sont la tricotomie entre <, = et> donc toute!! Instruction doit probablement être convertie en> = si vous voulez faire quoi que ce soit d'utile.

hugomg
la source
2

Je blâmerais partiellement le jeu d'instructions d'assemblage. Vous avez des instructions telles que jge"sauter si supérieur ou égal". Par opposition à "sauter sinon moins que".

Les rédacteurs du compilateur ont peut-être abandonné ce que les rédacteurs d'assemblage ont proposé, qui était probablement basé sur la façon dont il a été étiqueté lors de sa conception sur la puce.

...peut-être.

Ed Marty
la source
1

Je pense que j'ai vu quelques langues il y a quelques années où, au lieu de l' !=opérateur (pas égal), quelque chose comme a <>été utilisé. Je ne me souviens pas de leurs noms, cependant ...

Je pense que c'est plus difficile à lire !(a < b)ou a !< bque a >= b. C'est probablement la raison pour laquelle il !<n'est pas utilisé (il a l'air moche à mon avis).

Radu Murzea
la source
1
<>est (était?) principalement utilisé par les dialectes BASIC, SQL et Pascal.
yannis
@Yannis Rizos merci pour le rappel. Ils nous ont appris Pascal au lycée et c'est là que je l'ai vu :).
Radu Murzea
2
Python 2 aussi <>, bien qu'il ait été supprimé en 3.
Daniel Lubarov
D'un point de vue logique, !=c'est plus général que <>, puisque vous pouvez avoir des choses (comme des nombres complexes) où l'égalité est bien définie mais il n'y a vraiment pas d'ordre utile.
David Thornley