Existe alguma razão pela qual a maioria das linguagens de programação não possui operadores '!>' (Não maiores que) e '! <' (Não menos que)?


28

Gostaria de saber se existe alguma razão - ou se é apenas um acidente da história - que não existem operadores !>e !<na maioria das linguagens de programação?

a >= b (um OR maior igual a b) pode ser escrito como !(a < b) (a NÃO menor b) , igual a a !< b.

Essa pergunta me ocorreu quando eu estava no meio da codificação do meu próprio construtor de árvores de expressão. A maioria das linguagens de programação tem a != boperador para !(a=b), então por que não !>e !<?

ATUALIZAR:

  • !<(não menor) é mais fácil de pronunciar do que >=(maior ou igual)
  • !<(não menor) é mais curto para digitar do que >=(maior ou igual)
  • !<(não menor) é mais fácil de entender * do que >=(maior ou igual)

* porque ORé um operador binário, seu cérebro precisa operar dois operandos (ralador, iguais), enquanto NOTé um operador unário e seu cérebro precisa operar apenas com um operando (menor).


3
É não necessariamente mais fácil de pronunciar em todas as línguas. Em alemão, por exemplo, dizemos "größer / gleich", nunca ouvi falar "nicht kleiner".
Ingo

11
O argumento mais fácil de entender também não retém a água. Você deve operar 2 operandos em ambos os casos, pois isso é normal com operadores relacionais. Além disso, você simplesmente supõe que o cérebro pode operar mais facilmente em 1 operando em vez de 2. Você tem alguma evidência disso no campo da neurociência?
Ingo

Respostas:


84

A linguagem de programação D e a extensão do DMC para C e C ++ deram suporte a esses operadores (todas as 14 combinações), mas, curiosamente, D vai depreciar esses operadores , principalmente porque

  1. o que exatamente é a !< b? É a>=b || isNaN(a) || isNaN(b). não!< é o mesmo que , porque é verdadeiro enquanto é falso. O IEEE 754 é difícil de dominar, portanto, usar o para causar confusão no manuseio do NaN - você pode procurar por esses operadores na Phobos (biblioteca padrão do D), e vários usos têm comentários ao lado para lembrar aos leitores que o NaN está envolvido,>=NaN !< NaNNaN >= NaNa !< b
  2. portanto, poucas pessoas o usarão, mesmo que esses operadores existam como em D,
  3. e é preciso definir mais 8 tokens para esses operadores raramente usados, o que complica o compilador por pouco benefício,
  4. e sem esses operadores, ainda é possível usar o equivalente !(a < b), ou se alguém quiser ser explícito a >= b || isNaN(a) || isNaN(b), e eles são mais fáceis de ler.

Além disso, as relações (≮, ≯, ≰, ≱) raramente são vistas na matemática básica, ao contrário de !=(≠) ou >=(≥), por isso é difícil de entender para muitas pessoas.

Provavelmente, esses também são os motivos pelos quais a maioria dos idiomas não os suporta.


seldomly seen in basic math- mais como, nunca vi. Nós aprendemos volta na álgebra apenas para lançá-lo ao que matematicamente equivalente (especialmente desde que NaNnão aparece em matemática básica)
Izkata

O que é realmente necessário O IMHO é um meio de declarar variáveis ​​que se comportam como uma double exceção para seus NaNcomportamentos. Em muitos casos, o código que pode executar qualquer tipo de comparação NaNdeseja NaNcomparar maior que tudo, comparar menor que tudo ou lançar uma exceção na tentativa de comparação. Permitir que o código especifique declarativamente como NaNdeve ser considerado reduziria a necessidade de usar código imperativo para obter o comportamento correto.
Supercat

@ supercat: Você pode fazer operações NaN para lançar exceção usando <fenv.h>funções como fesetexceptflag.
Kennytm

@KennyTM: ter que definir a bandeira antes de executar uma operação e desmarcá-la depois parece nojento e propenso a problemas, e não trata da possibilidade de querer impor uma ordem total. O IEEE, pelo que entendi, acabou de introduzir alguns novos métodos de comparação que imporiam uma ordem total, que eu consideraria uma mudança bem-vinda se vencida; será interessante ver como os idiomas reagem.
22714

47

Porque não faz muito sentido ter dois operadores diferentes com exatamente o mesmo significado.

  • “Não maior” ( !>) é exatamente o mesmo que “menor ou igual” ( <=)
  • “Não menor” ( !<) é exatamente o mesmo que “maior ou igual” ( >=)

Isso não se aplica a "não é igual a" ( !=), não há operador com o mesmo significado.

Portanto, sua modificação tornaria o idioma mais complicado sem nenhum benefício.


5
Que tal x = x + 1, x += 1e x++?

33
@unsmoreb: Nada disso é a mesma coisa. Apenas um serve ao propósito de "incremento". O fato de você ter aproveitado as outras duas expressões para servir ao mesmo propósito é irrelevante - elas são muito mais gerais.
23413 DeadMG

11
<>é um operador com o mesmo significado que o !=Python 2 possui os dois.
krlmlr

9
@ user946850 E tendo ambos agora é amplamente considerado um erro, o uso de <>foi preterido por um longo tempo e foi removido desde o 3.0 (e lembre-se, a última versão 2.x de sempre , 2.7, foi lançada no verão de 2010).

3
@svick O que torna o operador ++ ainda mais brilhante, impedirá que os programadores de C # venham para cá, fazendo suposições racionais sobre o comportamento do programa e roubando meu trabalho de programador em C ++!

10

!<é sinônimo de >=. Mais tarde, é apenas uma maneira de digitar um símbolo matemático bem definido . Você está certo de que "não menos que" é usado na linguagem falada, no entanto, é coloquial e pode ser ambíguo (pode ser interpretado ou mal interpretado como >). Por outro lado, programação e matemática usam terminologia claramente definida e inequívoca.

Mesmo na lógica de 3 valores, como ANSI SQL, not x < yé equivalente a x >= y, pois ambos fornecem NULLse é xou yé NULL. No entanto, existem dialetos SQL não compatíveis com ANSI, onde não são equivalentes, e eles possuem!< .


10
No entanto, eles geralmente não são equivalentes ao usar números de ponto flutuante. Por exemplo, comparar qualquer coisa com NaNé falso, então !(2 < NaN) == true, enquanto (2 >= NaN) == false.
hammar 04/02

@hammar: É verdade, mas isso é verdade para todas as relações aritméticas em torno de NaNs. Todos eles param de se comportar normalmente.
Nicol Bolas

@hammar - isso é falha de ponto flutuante, mas não está implementando corretamente o Ord, por assim dizer. No entanto, esse não é um grande problema, já que ninguém nos obriga a implementar a !< b = not (a < b), poderíamos apenas dizer (! <) = (> =).
Ingo

8

O Transact-SQL possui operadores !> (Não maiores que) e ! <(Não menores que) .

Então, além de você, alguém da Sybase Microsoft também achou que seria uma boa ideia. Assim como o Microsoft Bob! :)


Isso não foi adicionado na v 2005?
JeffO 04/02/12

5
Existem muitas pessoas loucas e mal aconselhadas neste mundo que não estão sozinhas em concordar, consenso! = correção.

@ Jeffff Então devemos culpar a Microsoft, não a Sybase?
yannis

Interessante. Estou curioso da história por trás disso.
Surfasb

@surfasb Sim, eu também. Meu palpite seria que é apenas açúcar sintático, nada de especial nisso.
yannis

4

Eu acho que a resposta é simplesmente que não há necessidade de um !<operador. Como você apontou na sua pergunta, já existe >=e <=com a possibilidade de negar uma expressão existente, então por que adicionar outro operador?


Concordo que não faz sentido adicionar operador que faça a mesma coisa, mas por que "eles" escolheram> = em vez de! <, É muito mais fácil pronunciar NÃO MENOS, então MAIOR OU IGUAL, mais curto para digitar, mais fácil para digitar cérebro para entender.
22812 Alex Burtsev

!<não é mais curto para digitar do que >=, ou estou faltando alguma coisa?
Bryan Oakley

Eu quis dizer que é representação de texto (texto pronunciado).
22812 Alex Burtsev

4

From RFC 1925

a perfeição foi alcançada não quando não há mais nada a acrescentar, mas quando não há mais nada a ser removido.

A adição de operadores adicionais que duplicam a funcionalidade existente não faz nada além de adicionar complexidade (desnecessária) ao idioma (e, portanto, tokenizer e analisador).

Considere também nos idiomas em que a sobrecarga do operador é possível, você teria outro operador para sobrecarregar. Considere a confusão quando bool operator<=e bool operator!>pode retornar coisas diferentes (sim, eu sei que já é possível fazer comparações inconsistentes).

Por fim, pense nas linguagens em que os métodos ou operadores são multiplamente definidos (Ruby - estou olhando para você ) e você tem um programador que usa <= enquanto outro usa!> E você tem vários estilos de código para a mesma expressão.


Sim! É o princípio da parcimônia científica.
Luser droog

3

! <é igual a> = Agora, porque temos o segundo, não o primeiro, porque toda a linguagem implementa o operador positivo primeiro e depois a abordagem ao operador negativo, Como a implementação> = também abrange! <e <= abrange!>. e pensei que eles seriam redundantes e os ignorariam.

Sempre tente implementar o caso positivo primeiro e depois o caso negativo (:) pensamento positivo, apenas minha visão pessoal)


2

A razão é que os operadores de linguagens de programação tomam emprestado da tradição matemática e, na matemática, ninguém realmente usa "não maior" e "não menor", pois "menor ou igual" e "maior ou igual" fazem o mesmo trabalho.

Portanto, nas linguagens de programação, geralmente obtemos um símbolo parecido com ≠ para não igual ( !=ou /=, a menos que alguém se interesse por <>um operador textual)

e coisas que se parecem com ≤ e ≥ ( <=e >=)


Btw, eu não concordo com a sua afirmação de que NÃO é mais simples de entender e raciocinar sobre então OU. Em matemática, as provas que envolvem muitas negações (como a redução ao absurdo) geralmente são desaprovadas, se houver uma alternativa mais direta disponível. Além disso, no caso de pedidos, o conhecimento básico que temos (e que é usado ao pensar ou provar algo) é a tricotomia entre <, = e> para que qualquer declaração! <Provavelmente tenha que ser convertida em> = se você quiser fazer qualquer coisa útil com isso.


2

Eu culparia parcialmente o conjunto de instruções de montagem. Você tem instruções como jge"pular se for maior ou igual". Ao contrário de "pular se não for menor que".

Os criadores de compiladores podem ter optado pelo que os criadores de montagem criaram, o que presumivelmente se baseou em como ele foi rotulado ao ser projetado no chip.

...possivelmente.


1

Eu acho que vi algumas línguas há alguns anos atrás, onde, em vez do !=operador (não é igual a), algo como <>foi usado. Mas não consigo lembrar os nomes deles ...

Eu acho que é mais difícil de ler !(a < b)ou do a !< bque a >= b. Provavelmente, essa é a razão pela qual !<não é usado (parece feio na minha opinião).


11
<>é (foi?) usado principalmente pelos dialetos BASIC, SQL e Pascal.
yannis

@ Yannis Rizos obrigado pelo lembrete. Eles nos ensinaram Pascal no ensino médio e foi lá que eu vi :).
Radu Murzea

2
O Python 2 também possui <>, embora tenha sido removido em 3. #
Daniel Lubarov

Do ponto de vista lógico, !=é mais geral do que <>, uma vez que você pode ter coisas (como números complexos) em que a igualdade é bem definida, mas realmente não existe uma ordem útil.
David Thornley
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.