In computer science, a relational operator is a programming language construct or operator that tests or defines some kind of relation between two entities. These include numerical equality (e.g., ) and inequalities (e.g., ).
In programming languages that include a distinct boolean data type in their type system, like Pascal, Ada, or Java, these operators usually evaluate to true or false, depending on if the conditional relationship between the two operands holds or not. In languages such as C, relational operators return the integers 0 or 1, where 0 stands for false and any non-zero value stands for true.
An expression created using a relational operator forms what is termed a relational expression or a condition. Relational operators can be seen as special cases of logical predicates.
Equality
Usage
Equality is used in many programming language constructs and data types. It is used to test if an element already exists in a set, or to access to a value through a key. It is used in switch statements to dispatch the control flow to the correct branch, and during the unification process in logic programming.
One possible meaning of equality is that "if a equals b, then either a or b can be used interchangeably in any context without noticing any difference." But this statement does not necessarily hold, particularly when taking into account mutability together with content equality.
Location equality vs. content equality
Sometimes, particularly in object-oriented programming, the comparison raises questions of data types and inheritance, equality, and identity. It is often necessary to distinguish between: two different objects of the same type, e.g., two hands two objects being equal but distinct, e.g., two $10 banknotes two objects being equal but having different representation, e.g., a $1 bill and a $1 coin two different references to the same object, e.g., two nicknames for the same person
In many modern programming languages, objects and data structures are accessed through references. In such languages, there becomes a need to test for two different types of equality: Location equality (identity): if two references (A and B) reference the same object. Interactions with the object through A are indistinguishable from the same interactions through B, and in particular changes to the object through A are reflected through B. Content equality: if the objects referenced by two references (A and B) are equivalent in some sense: Structural equality (that is, their contents are the same). which may be either shallow (testing only immediate subparts), or deep (testing for equality of subparts recursively). A simple way to achieve this is through representational equality: checking that the values have the same representation. Some other tailor-made equality, preserving the external behavior. For example, 1/2 and 2/4 are considered equal when seen as a rational number. A possible requirement would be that "A = B if and only if all operations on objects A and B will have the same result", in addition to reflexivity, symmetry, and transitivity.
The first type of equality usually implies the second (except for things like not a number (NaN) which are unequal to themselves), but the converse is not necessarily true. For example, two string objects may be distinct objects (unequal in the first sense) but contain the same sequence of characters (equal in the second sense). See identity for more of this issue.
Real numbers, including many simple fractions, cannot be represented exactly in floating-point arithmetic, and it may be necessary to test for equality within a given tolerance. Such tolerance, however, can easily break desired properties such as transitivity, whereas reflexivity breaks too: the IEEE floating-point standard requires that NaN ≠ NaN holds. In contrast, the (2022) private standard for posit arithmetic (posit proponents mean to replace IEEE floats) has a similar concept, NaR (Not a Real), where NaR = NaR holds.
Other programming elements such as computable functions, may either have no sense of equality, or an equality that is uncomputable. For these reasons, some languages define an explicit notion of "comparable", in the form of a base class, an interface, a trait or a protocol, which is used either explicitly, by declaration in source code, or implicitly, via the structure of the type involved.