A blog post featured on Hacker News regarding the question of what ‘equals’ means in mathematics by Clare Watson is worth reading. It doesn’t directly address the underlying question for a computer programming language but it sets the field for discussing the problem.
You might think something as simple as ‘equals’ or the ‘=’ sign was clear and understood but in fact, it hasn’t been for some time, and it lies at the heart of some differences between programming languages and what the machine underneath can do for you (or even, against your wishes). This blog post reveals the longstanding and unresolved issue of what ‘equality’ means in mathematics.
The symbol for ‘equals’ originates from the Latin word ‘aequalis‘ and was introduced as the ‘=’ symbol by the Welsh mathematician Robert Recorde in 1557. In modern computer science, you may encounter any of the following four forms:
- ‘:=’ is ‘Assignment’ equals, which is actually passing data or information.
- ‘=’ is simple equals, which usually means either an assignment or a test of equality. But which?
- ‘==’ is a stronger equals, which uniquely tests for equality in some languages.
- ‘===’ is a more robust test for equality in some languages.
Surely these are much the same? Well no.
The first kind, assignment, is really saying ‘copy data from the right side into the left side’; ‘A := B’ says that whatever A is, it should have the same value as what B is. But, does ‘have the same value’ always mean the same thing? Can A be a pointer to B, or does the value inherent in or behind B have to be copied into a different place that A is, or points to? It depends on the language! Some kinds of assignments take one form (copy the values) and other kinds of assignments change the pointers to point to the same thing (copy the reference) in some very arcane languages. The ‘name’ is the key component and may itself be ‘mutable’ depending on what is happening.
The second kind (‘=’) is an ambiguous way of either indicating an assignment or performing an unqualified test that results in a yes or no answer. The problem is that it’s unclear whether it means an assignment or a test. It depends on the structure of the expression being considered if it’s an assignment, a test, or even in some languages (such as C, where an assignment can leave behind a residual test value!), this form of ‘equals’ depends on the computer being able to understand the order of precedence parsing the statements and expressions, to unpack what functional role the ‘=’ sign can take in the context under consideration.
The third kind involves a more rigorous language requirement, distinguishing ‘=’ for assignment from ‘==’ for testing. Additionally, the ‘:=’ notation introduces the concept of ligatures, where we represent single concepts textually using two or more characters side by side. It gets worse when you consider languages with ‘::=’ as a form of assignment!’ In a world of ligatures, a form like ‘==’ may be represented by a longer character, or by the two underlying repeated ‘=’ characters, and if you use ligatures in your programming interface, somebody else may be looking at the same code seeing different characters from you. It isn’t usually a problem but it can introduce misunderstandings.
The last kind, ‘===’, is a rare occurrence, but tries to get to the heart of a problem by comparing types of concepts that are not always directly equivalent. Floating point and integer numbers, for instance, cannot literally be the same value if one is 0.0 and the other is 0 — there is room for ambiguity in their being different ‘types’ of a thing. Languages that simply convert on-the-fly float to integer may use ‘=’ or ‘==’ to mean equivalence under conversion where ‘===’ has a literalism that enforces a stronger test.
Clare’s blog post discusses the more philosophical underpinnings of the distinction of meaning inequality, which I’ve discussed above in a computing language-specific manner. It’s worth reading, because not all equal signs are the same, and mathematicians aren’t sure if they agree on what to do about it!
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.