¿Hay alguna razón por la cual la mayoría de los lenguajes de programación no tienen operadores '!>' (No mayores que) y '! <' (No menores que)?

28

Me pregunto si hay alguna razón - o si es sólo un accidente de la historia - que no existen !>y !<los operadores en la mayoría de los lenguajes de programación?

a >= b (un OR mayor es igual a b) podría escribirse como !(a < b) (a NO menor b) , que es igual a !< b.

Esta pregunta me llamó la atención cuando estaba en medio de la codificación de mi propio generador de árboles de expresión. La mayoría de los lenguajes de programación tienen a != boperador para !(a=b), ¿por qué no !>y !<?

ACTUALIZAR:

  • !<(no menor) es más fácil de pronunciar que >=(mayor o igual)
  • !<(no menor) es más corto de escribir que >=(mayor o igual)
  • !<(no menor) es más fácil de entender * que >=(mayor o igual)

* debido a que ORes un operador binario, su cerebro necesita operar dos operandos (rallador, igual), mientras que NOTes un operador unario y su cerebro necesita operar solo con un operando (menor).

syntax comparison operators Alex Burtsev
fuente
3
Es no necesariamente más fácil de pronunciar en cualquier idioma. En alemán, por ejemplo, decimos "größer / gleich", nunca he escuchado "nicht kleiner".
Ingo
1
El argumento más fácil de entender tampoco retiene el agua. Debe operar 2 operandos en cualquier caso, ya que esto es normal con operadores relacionales. Además, simplemente asume que el cerebro puede operar más fácilmente en 1 operando en lugar de 2. ¿Tiene alguna evidencia de eso desde el campo de la neurociencia?
Ingo

Respuestas:

84

El lenguaje de programación D y la extensión de DMC a C y C ++ admitieron estos operadores (las 14 combinaciones de ellos), pero curiosamente, D va a desaprobar estos operadores , principalmente porque

  1. ¿qué es exactamente a !< b? Es a>=b || isNaN(a) || isNaN(b). no!< es lo mismo que >=, porque NaN !< NaNes verdadero mientras que NaN >= NaNes falso. IEEE 754 es difícil de dominar, por lo que usarlo a !< bsolo causará confusión sobre el manejo de NaN: puede buscar dichos operadores en Phobos (biblioteca estándar de D), y una gran cantidad de uso tiene comentarios al lado para recordar a los lectores que NaN está involucrado,
  2. por lo tanto, pocas personas lo usarán, incluso si tales operadores existen como en D,
  3. y uno tiene que definir 8 tokens más para estos operadores poco utilizados, lo que complica el compilador por poco beneficio,
  4. y sin esos operadores, uno podría usar el equivalente !(a < b), o si le gusta ser explícito a >= b || isNaN(a) || isNaN(b), y son más fáciles de leer.

Además, las relaciones (≮, ≯, ≰, ≱) rara vez se ven en matemáticas básicas, a diferencia de !=(≠) o >=(≥), por lo que es difícil de entender para muchas personas.

Estas son probablemente también las razones por las cuales la mayoría de los idiomas no las admiten.

kennytm
fuente
seldomly seen in basic math- Más bien, nunca visto. Aprendemos de nuevo en álgebra a cambiarlo al equivalente matemáticamente (especialmente porque NaNno aparece en matemáticas básicas)
Izkata
Lo que realmente se necesita en mi humilde opinión es un medio de declarar variables que se comportan como una double excepción a sus NaNcomportamientos. En muchos casos, el código que podría realizar cualquier tipo de comparación NaNquerrá tener una NaNcomparación más grande que todo, hacer que se compare más pequeño que todo o lanzar una excepción en el intento de comparación. Permitir que el código especifique de manera declarativa cómo NaNdebe considerarse reduciría la necesidad de usar un código imperativo para lograr un comportamiento correcto.
supercat
@supercat: podría realizar operaciones NaN para lanzar excepciones utilizando <fenv.h>funciones como fesetexceptflag.
kennytm
@KennyTM: Tener que configurar la bandera antes de realizar una operación y desarmarla después parece desagradable y propenso a problemas, y no aborda la posibilidad de querer imponer un pedido total. IEEE, por lo que entiendo, acaba de introducir algunos nuevos métodos de comparación que impondrían un orden total, lo que consideraría bienvenido si el cambio vencido; Será interesante ver cómo reaccionan los idiomas.
supercat
47

Porque no tiene mucho sentido tener dos operadores diferentes con exactamente el mismo significado.

  • "No mayor" ( !>) es exactamente lo mismo que "menor o igual" ( <=)
  • "No menor" ( !<) es exactamente lo mismo que "mayor o igual" ( >=)

Esto no se aplica a "no es igual" ( !=), no hay operador con el mismo significado.

Por lo tanto, su modificación complicaría el lenguaje sin ningún beneficio.

svick
fuente
55
¿Qué pasa con x = x + 1, x += 1y x++?
33
@dunsmoreb: Ninguno de esos es lo mismo. Solo uno tiene el propósito de "incremento". El hecho de que haya aprovechado las otras dos expresiones para servir al mismo propósito es irrelevante: ambas son mucho más generales.
DeadMG
1
<>es un operador con el mismo significado que !=, y Python 2 tiene ambos.
krlmlr
99
@ user946850 y que tengan la actualidad se considera un error, el uso de <>está en desuso desde hace mucho tiempo y es removido desde el 3.0 (y que importa, la última versión 2.x vez , 2.7, fue lanzado en el verano de 2010).
3
@svick Lo que hace que el operador ++ sea aún más brillante, evitará que esos programadores de C # vengan aquí, hagan suposiciones racionales sobre el comportamiento del programa, ¡y luego robarán mi trabajo de programador de C ++!
10

!<es sinónimo >=. Más adelante es solo una forma de escribir símbolos matemáticos bien definidos ≥. Tiene razón en que se utiliza "no menos que" en el lenguaje hablado, sin embargo, es coloquial y puede ser ambiguo (puede interpretarse ≥o malinterpretarse como >). Por otro lado, la programación y las matemáticas utilizan una terminología claramente definida y sin ambigüedades.

Incluso en la lógica de 3 valores, como ANSI SQL, not x < yes equivalente a x >= y, ya que ambos dan NULLsi uno xo yes NULL. Sin embargo, hay dialectos de SQL que no cumplen con ANSI, donde no es equivalente, y lo tienen!< .

vartec
fuente
10
Sin embargo, generalmente no son equivalentes cuando se usan números de punto flotante. Por ejemplo, comparar cualquier cosa con NaNes falso, entonces !(2 < NaN) == true, mientras (2 >= NaN) == false.
hammar
@hammar: Cierto, pero eso es cierto para todas las relaciones aritméticas en torno a NaNs. Todos dejan de comportarse normalmente.
Nicol Bolas
@hammar: esto es un error de punto flotante, simplemente no está implementando correctamente Ord, por así decirlo. Sin embargo, este no es un gran problema, ya que nadie nos obliga a implementar a !< b = not (a < b), simplemente podríamos decir (! <) = (> =).
Ingo
8

Transact-SQL tiene operadores !> (No mayor que) y ! <(No menor que) .

Entonces, además de usted, alguien en Sybase Microsoft también pensó que sería una buena idea. ¡Al igual que Microsoft Bob! :)

Yannis
fuente
¿No se agregó esto en v 2005?
JeffO
55
Hay muchas personas locas mal aconsejadas en este mundo que no están solas en ponerse de acuerdo, consenso! = corrección.
@JeffO ¿Entonces deberíamos culpar a Microsoft, no a Sybase?
Yannis
Interesante. Tengo curiosidad por la historia detrás de esto.
surfasb
@surfasb Yeap, yo también. Supongo que es solo azúcar sintáctico, no tiene nada de especial.
Yannis
4

Creo que la respuesta es simplemente que no hay necesidad de un !<operador. Como señaló en su pregunta, ya existe >=y <=junto con la posibilidad de negar una expresión existente, entonces, ¿por qué agregar otro operador?

Bryan Oakley
fuente
Estoy de acuerdo en que no tiene sentido agregar operadores que hagan lo mismo, pero por qué "ellos" eligieron> = en lugar de! <, Es mucho más fácil pronunciar NO MENOS, luego MAYOR O IGUAL, es más corto de escribir, es más fácil para cerebro para entender
Alex Burtsev
!<no es más corto de escribir que >=, o me falta algo?
Bryan Oakley
Quise decir que es representación de texto (texto pronunciado).
Alex Burtsev
4

De RFC 1925

La perfección se ha alcanzado no cuando no hay nada más que agregar, sino cuando no hay nada más que quitar.

Agregar operadores adicionales que duplican la funcionalidad existente no hace nada más que agregar complejidad (innecesaria) al lenguaje (y, por lo tanto, tokenizer y parser).

Considere también en idiomas en los que es posible la sobrecarga del operador, tendría que sobrecargar otro operador. Considere la confusión cuando bool operator<=y bool operator!>podría devolver cosas diferentes (sí, sé que uno ya puede hacer comparaciones inconsistentes).

Por último, pensar en lenguas donde se definen los métodos multiplican u operadores (Ruby - Yo estoy mirando a usted ) y usted tiene OMS utiliza un programador <=, mientras que otros usos!> Y que tienen múltiples estilos de código para la misma expresión.


fuente
¡Sí! Es el principio del parsimonia científica.
luser droog
3

! <es igual a> = Ahora, ¿por qué tenemos el segundo no primero porque todo el lenguaje implementa el operador positivo primero y luego se acerca al operador negativo, ya que la implementación> = también cubre! <y <= cubre!>. y pensé que serían redundantes y los omitirían.

Siempre trate de implementar el caso positivo primero y luego vaya al caso negativo (:) pensamiento positivo, solo mi opinión personal)

Bloc
fuente
2

La razón es que los operadores en lenguajes de programación toman prestado de la tradición matemática y en matemáticas nadie usa "no mayor" y "no menor" ya que "menor o igual" y "mayor o igual" hacen un trabajo igual de bueno.

Entonces, en los lenguajes de programación, generalmente obtenemos un símbolo que parece ≠ para no es igual ( !=o /=, a menos que alguien sea sofisticado <>o un operador textual)

y cosas que parecen ≤ y ≥ ( <=y >=)

Por cierto, no estoy de acuerdo con su afirmación de que NO es más fácil de entender y razonar sobre entonces O. En matemáticas, las pruebas que involucran muchas negaciones (como la reducción a lo absurdo) generalmente están mal vistas si hay una alternativa más directa disponible. Además, en el caso de ordenar, el conocimiento básico que tenemos (y que se usa al pensar o probar algo) es la tricotomía entre <, = y>, ​​por lo que cualquier declaración! <Probablemente deba convertirse a> = si desea hacerlo algo útil con eso.

hugomg
fuente
2

Culparía parcialmente al conjunto de instrucciones de montaje. Tienes instrucciones como jge"saltar si es mayor o igual que". A diferencia de "saltar si no menos de".

Los escritores de compiladores pueden haberse equivocado de lo que se les ocurrió a los escritores de ensamblajes, lo que probablemente se basó en cómo se etiquetó cuando se diseñó en el chip.

...posiblemente.

Ed Marty
fuente
1

Creo que vi algunos idiomas hace unos años donde, en lugar del !=operador (no igual), <>se usaba algo así . Aunque no puedo recordar sus nombres ...

Creo que es más difícil de leer !(a < b)o a !< bque a >= b. Probablemente esa sea la razón por la !<que no se usa (en mi opinión, se ve feo).

Radu Murzea
fuente
1
<>se usa (was?) principalmente en dialectos BASIC, SQL y dialectos Pascal.
Yannis
@ Yannis Rizos gracias por el recordatorio. Nos enseñaron a Pascal en la escuela secundaria y ahí es donde lo vi :).
Radu Murzea
2
Python 2 también tiene <>, aunque fue eliminado en 3.
Daniel Lubarov
Desde un punto de vista lógico, !=es más general que <>, ya que puede tener cosas (como números complejos) donde la igualdad está bien definida pero realmente no hay un orden útil.
David Thornley