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 !< ?


  • !< (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).

  • 3
    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 0:29
  • 1
    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 0:37

10 Answers 10


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.

| improve this answer | |
  • 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 <fenv.h> functions like fesetexceptflag. – kennytm Feb 15 '14 at 8: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

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.

| improve this answer | |
  • 5
    What about x = x + 1, x += 1, and x++? – user20891 Feb 4 '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 4 '12 at 14:55
  • 1
    <> is an operator with the same meaning as !=, and Python 2 has both. – krlmlr Feb 4 '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). – user7043 Feb 4 '12 at 19:15
  • 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! – user29079 Feb 7 '12 at 12:58

!< 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 !<.

| improve this answer | |
  • 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 4 '12 at 16:16
  • @hammar: True, but that's true of all arithmetic relations around NaNs. All of them stop behaving normally. – Nicol Bolas Feb 4 '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 0:26

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! :)

| improve this answer | |
  • Wasn't this added in v 2005? – JeffO Feb 4 '12 at 16:33
  • 5
    there are lots of crazy ill-advised people in this world that are not alone in agreeing with each other, consensus != correctness. – user7519 Feb 4 '12 at 20:07
  • @JeffO Then we should blame Microsoft, not Sybase? – yannis Feb 4 '12 at 21:16
  • Interesting. I'm curious of the story behind this. – surfasb Feb 4 '12 at 23:42
  • @surfasb Yeap, me too. My guess would be that it's just syntactic sugar, nothing special about it. – yannis Feb 4 '12 at 23:51

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?

| improve this answer | |
  • 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 4 '12 at 13:32
  • !< is no shorter to type than >=, or am I missing something? – Bryan Oakley Feb 4 '12 at 13:42
  • I meant it's text representation (pronounced text). – Alex Burtsev Feb 4 '12 at 13:56

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.

| improve this answer | |
  • Yes! It's the principle of Scientific Parsimony. – luser droog Feb 5 '12 at 4:46

!< 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)

| improve this answer | |

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.

| improve this answer | |

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.


| improve this answer | |

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).

| improve this answer | |
  • 1
    <> is (was?) mainly used by BASIC dialects, SQL, and Pascal dialects. – yannis Feb 4 '12 at 13:52
  • @Yannis Rizos thanks for the reminder. They taught us Pascal in high-school and that's where I saw it :) . – Radu Murzea Feb 4 '12 at 13:55
  • 2
    Python 2 also has <>, although it was removed in 3. – Daniel Lubarov Feb 4 '12 at 13:55
  • From a logical point of view, != is more general than <>, since you can have things (like complex numbers) where equality is well-defined but there really isn't a useful ordering. – David Thornley Feb 16 '12 at 18:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.