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

2
  • 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, 2012 at 0: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, 2012 at 0:37

10 Answers 10

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.

4
  • 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, 2012 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, 2014 at 23:35
  • @supercat: You could make NaN operations to throw exception using <fenv.h> functions like fesetexceptflag.
    – kennytm
    Feb 15, 2014 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, 2014 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.

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

3
  • 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, 2012 at 16:16
  • @hammar: True, but that's true of all arithmetic relations around NaNs. All of them stop behaving normally. Feb 4, 2012 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, 2012 at 0: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! :)

6
  • Wasn't this added in v 2005?
    – JeffO
    Feb 4, 2012 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, 2012 at 20:07
  • @JeffO Then we should blame Microsoft, not Sybase?
    – yannis
    Feb 4, 2012 at 21:16
  • Interesting. I'm curious of the story behind this.
    – surfasb
    Feb 4, 2012 at 23:42
  • @surfasb Yeap, me too. My guess would be that it's just syntactic sugar, nothing special about it.
    – yannis
    Feb 4, 2012 at 23:51
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?

3
  • 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. Feb 4, 2012 at 13:32
  • !< is no shorter to type than >=, or am I missing something? Feb 4, 2012 at 13:42
  • I meant it's text representation (pronounced text). Feb 4, 2012 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.

1
  • Yes! It's the principle of Scientific Parsimony. Feb 5, 2012 at 4:46
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)

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.

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.

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

4
  • 1
    <> is (was?) mainly used by BASIC dialects, SQL, and Pascal dialects.
    – yannis
    Feb 4, 2012 at 13:52
  • @Yannis Rizos thanks for the reminder. They taught us Pascal in high-school and that's where I saw it :) . Feb 4, 2012 at 13:55
  • 2
    Python 2 also has <>, although it was removed in 3. Feb 4, 2012 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. Feb 16, 2012 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.