29

I wonder if there is any reason - or if it is just an accident of history - that there are no !> and !< operators in most programming languages?

a >= b (a greater OR equals b) could be written as !(a < b) (a NOT lesser b), that equals a !< b.

This question struck me when I was in the middle of coding my own expression tree builder. Most programming languages have a != b operator for !(a=b), so why no !> and !< ?

UPDATE:

  • !< (not lesser) is easier to pronounce than >= (greater or equals)
  • !< (not lesser) is shorter to type than >= (greater or equals)
  • !< (not lesser) is easier to understand* than >= (greater or equals)

*because OR is binary operator you brain need to operate two operands (grater, equals), while NOT is unary operator and you brain need to operate only with one operand (lesser).

Alex Burtsev
  • 686
  • 1
  • 7
  • 15
  • 4
    It's **not** necessarily easier to pronounce in every language. In German, for example, we say "größer/gleich", I've never heard "nicht kleiner". – Ingo Feb 18 '12 at 00:29
  • 2
    The *easier to understand* argument does not hold water either. You must operate 2 operands in either case, as this is normal with relational operators. Moreover, you just simply assume that the brain can operate easier on 1 operand instead of 2. Do you have *any* evidence for that from the field of neuroscience? – Ingo Feb 18 '12 at 00:37

10 Answers10

85

The D programming language and DMC's extension to C and C++ did support these operators (all 14 combinations of them), but interestingly, D is going to deprecate these operators, mainly because

  1. what exactly is a !< b? It is a>=b || isNaN(a) || isNaN(b). !< is not the same as >=, because NaN !< NaN is true while NaN >= NaN is false. IEEE 754 is hard to master, so using a !< b to will just cause confusion over NaN handling — you can search for such operators in Phobos (D's standard library), and quite a number of use has comments beside it to remind the readers NaN is involved,
  2. therefore, few people will use it, even if such operators exist like in D,
  3. and one have to define 8 more tokens for these seldomly used operators, which complicates the compiler for little benefit,
  4. and without those operators, one could still use the equivalent !(a < b), or if one likes to be explicit, a >= b || isNaN(a) || isNaN(b), and they are easier to read.

Besides, the relations (≮, ≯, ≰, ≱) are seldomly seen in basic math, unlike != (≠) or >= (≥), so it's hard to understand for many people.

These are probably also the reasons why most languages do not support them.

kennytm
  • 987
  • 6
  • 6
  • `seldomly seen in basic math` - more like, never seen. We learn back in algebra to just flip it to the mathematically equivalent one (especially since `NaN` doesn't appear in basic math) – Izkata Feb 20 '12 at 14:52
  • What's really needed IMHO is a means of declaring variables which behave as a `double` *except* for their `NaN` behaviors. In many cases, code which might perform any kind of comparison with `NaN` will want to have `NaN` compare larger than everything, have it compare smaller than everything, or throw an exception on the comparison attempt. Allowing code to specify *declaratively* how `NaN` should be regarded would reduce the need to use imperative code to achieve correct behavior. – supercat Feb 13 '14 at 23:35
  • @supercat: You could make NaN operations to throw exception using `` functions like `fesetexceptflag`. – kennytm Feb 15 '14 at 08:05
  • @KennyTM: Having to set the flag before performing an operation and unset it after seems icky and trouble-prone, and it doesn't address the possibility of wanting to impose a total order. IEEE from what I understand has just introduced some new comparison methods which would impose a total order, which I would consider a welcome if overdue change; it will be interesting to see how languages react. – supercat Feb 15 '14 at 22:40
47

Because it doesn't make much sense to have two different operators with exactly the same meaning.

  • “not greater” (!>) is exactly the same as “lesser or equal” (<=)
  • “not lesser” (!<) is exactly the same as “greater or equal” (>=)

This does not apply to “not equals” (!=), there is no operator with the same meaning.

So, your modification would make the language more complicated with no no benefit.

svick
  • 9,999
  • 1
  • 37
  • 51
  • 6
    What about `x = x + 1`, `x += 1`, and `x++`? –  Feb 04 '12 at 14:00
  • 33
    @dunsmoreb: None of those are the same thing. Only one serves the purpose of "increment". The fact that you have leveraged the other two expressions to serve the same purpose is irrelevant- they are both far more general. – DeadMG Feb 04 '12 at 14:55
  • What about `<>`? – krlmlr Feb 04 '12 at 17:55
  • @user946850, what about it? Most languages support either `!=` or `<>`. – svick Feb 04 '12 at 18:10
  • 1
    `<>` is an operator with the same meaning as `!=`, and Python 2 has both. – krlmlr Feb 04 '12 at 18:49
  • 9
    @user946850 And having both is now widely considered a mistake, use of `<>` has been deprecated for a long time and it's removed since 3.0 (and mind you, the last 2.x release **ever**, 2.7, was released in summer 2010). –  Feb 04 '12 at 19:15
  • 1
    @FelixDombek: Python. –  Feb 04 '12 at 21:57
  • But isn't `!(a == b)` the same as `a != b`? admittedly the first isn't a single operator. – Jonathan. Feb 04 '12 at 23:06
  • @Jonathan., and `?:` is the same as `if` and `for` is the same as `while`. But those constructs are still useful, because they can make shorter and more readable. The same applies to `!=`, but not to `!>`. – svick Feb 05 '12 at 01:14
  • These only have the same meaning on certain types. I'd expect `!<` to be different from `>=` on floats if they return a `bool`. (personally I think `>=` shouldn't return a `bool?` instead of a `bool`) – CodesInChaos Feb 05 '12 at 11:51
  • Clearly x++, x+=1 and x=x+1 are different! These operators make it possible to write expressions like `x+=x+x++`, an expression that not only yields completely undefined behavior but also blows the mind of the programmer, with just a single line of code! Usually you would need far more complex expression to achieve that, so these operators lead to more compact code. Also consider the astronomic amounts of money that have been invested in writing ++ related bugs and then solving them. If you removed that operator from the language, all that money would have been spent for nothing! –  Feb 07 '12 at 12:32
  • @Lundin, in some languages (like C#), the behavior of that expression is completely defined. – svick Feb 07 '12 at 12:42
  • 3
    @svick Which makes the ++ operator even more brilliant, it will prevent those C# programmers from coming here, making rational assumptions about program behavior, then steal my C++ programmer job! –  Feb 07 '12 at 12:58
  • @Lundin: You do know that C# has the ++ operators as well, right? – John Gietzen Feb 08 '12 at 01:18
  • @CodesInChaos: IEEE-754 NaN behavior is IMHO one of the biggest "unforced design mistakes" in computer science history. Testing whether two values are equivalent should be one of the easiest and cheapest operations. Not only is `x==y || (x!=x) || (y!=y)` absurdly complicated--it doesn't even properly handle situations where e.g. `x` and `y` might be different kinds of `NaN` and code might care about the difference. – supercat Feb 07 '18 at 18:15
10

!< is synonymous with >=. Later is just a way of typing well defined mathematical symbol ≥. You are right that "not less than" is used in spoken language, however it's colloquial and can be ambiguous (can be interpreted ≥ or misinterpreted as >). On the other hand programming and math use clearly defined, unambiguous terminology.

Even in 3-value logic, such as ANSI SQL, not x < y is equivalent of x >= y, as they both give NULL if either x or y is NULL. However, there are non-ANSI compliant SQL dialects, where it's not equivalent, and they do have !<.

vartec
  • 20,760
  • 1
  • 52
  • 98
  • 10
    They are, however, usually not equivalent when using floating-point numbers. For example, comparing anything with `NaN` is false, so `!(2 < NaN) == true`, while `(2 >= NaN) == false`. – hammar Feb 04 '12 at 16:16
  • @hammar: True, but that's true of all arithmetic relations around `NaN`s. All of them stop behaving normally. – Nicol Bolas Feb 04 '12 at 23:03
  • @hammar - this is floating-points fault, it's just not correctly implementing Ord, so to speak. This is nevertheless not a big problem since nobody forces us to implement `a !< b = not (a < b)`, we could just say (!<) = (>=). – Ingo Feb 18 '12 at 00:26
8

Transact-SQL has !> (not greater than) and !< (not less than) operators.

So, other than you, someone at Sybase Microsoft also thought it would be a good idea. Just like Microsoft Bob! :)

mousio
  • 103
  • 3
yannis
  • 39,547
  • 40
  • 183
  • 216
4

I think the answer is simply that there's no need for a !< operator. As you pointed out in your question there is already >= and <= along with the possibility to negate an existing expression, so why add another operator?

Bryan Oakley
  • 25,192
  • 5
  • 64
  • 89
  • I agree that there is no point in adding operator that do the same thing, but why "they" chose >= instead of !<, it's much easier to pronounce NOT LESSER, then GREATER OR EQUALS, it shorter to type, it's easier for brain to understand. – Alex Burtsev Feb 04 '12 at 13:32
  • `!<` is no shorter to type than `>=`, or am I missing something? – Bryan Oakley Feb 04 '12 at 13:42
  • I meant it's text representation (pronounced text). – Alex Burtsev Feb 04 '12 at 13:56
4

From RFC 1925

perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

Adding additional operators that duplicate existing functionality doesn't do anything other than add (unnecessary) complexity to the language (and thus tokenizer and parser).

Consider also in languages where operator overloading is possible, you would have yet another operator to overload. Consider the confusion when bool operator<= and bool operator!> could return different things (yes, I know one can already make inconsistent comparisons).

Lastly, think of languages where methods or operators are multiply defined (Ruby - I'm looking at you) and you have one programmer who uses <= while another uses !> and you have multiple code styles for the same expression.

3

!< is equal to >= Now why we have second one not first because all language implement positive operator first and then approach to negative operator,As implementing >= also covers !< and <= covers !>.So language creator goes to these and thought they would be redundant and skip them.

Always try to implement positive case first then go to negative case (:) positive thinking, me personal view only)

Notepad
  • 131
  • 3
2

The reason is that operators in programming languages borrow from the mathematical tradition and in mathematics noone realy uses "not greater" and "not smaller" since "smaller or equal" and "greater or equal" do just as good of a job.

So in Programming languages we usually get a symbol looking like ≠ for not equals (!= or /=, unless someone if being fancy with <> or a textual operator)

and things that look like ≤ and ≥ (<= and >=)

Btw, I don't agree with your assertion that NOT is simpler to understand and reason about then OR. In mathematics, proofs involving lots of negations (like reduction to absurd) are usually frowned upon if there is a more direct alternative available. Also, in the ordering case, the basic knowledge we have (and that is used when thinking or proving something) is the tricotomy between <, = and > so any !< statement probably has to be converted to >= if you want to do anything useful with it.

hugomg
  • 2,102
  • 13
  • 17
2

I'd partially blame the assembly instruction set. You've got instructions such as jge for "jump if greater than or equal". As opposed to "jump if not less than".

Compiler writers may have gone off of what assembly writers came up with, which was presumably based on how it was labeled when being designed on the chip.

...possibly.

Ed Marty
  • 179
  • 5
1

I think I saw some languages a few years ago where, instead of the != operator (not equals), something like <> was used. Can't remember their names, though...

I think that it's harder to read !(a < b) or a !< b than a >= b . Probably that's the reason why !< is not used (it does look ugly in my opinion).

Radu Murzea
  • 1,810
  • 2
  • 18
  • 24