Slashdot Mirror
Symbolic vs. Mnemonic Relational Operators: Is "GT" Greater Than ">"?
theodp writes: "Mnemonic operators," writes SAS's Rick Wicklin as he weighs the pros-and-cons of Symbolic Versus Mnemonic Logical Operators, "tend to appear in older languages like FORTRAN, whereas symbolic operators are common in more recent languages like C/C++, although some relatively recent scripting languages like Perl, PHP, and Windows PowerShell also support mnemonic operators. SAS software has supported both operators in the DATA step since the very earliest days, but the SAS/IML language, which is more mathematically oriented, supports only the symbolic operators. Functionally, the operators are equivalent, so which ones you use is largely a matter of personal preference. Since consistency and standards are essential when writing computer programming, which operators should you choose?"
Guess he had spare time on his hands
Only LUDDITES use LUDDITE operators when writing LUDDITE software! Modern app appers use APPerators when apping modern apps!
Apps!
Of course a Gin & Tonic is greater than some symbol
Don't blame me, I voted for Kodos
I think he's right about the mnemonics being easier to type. They're generally on dominant fingers and you use letters constantly (not so much with pipe, ampersand, great and less than). That being said, I do think the capitalization should be saved for constants, and scanning code with your eyes proves the symbology easier to pick out. Symbols are better.
Stick to simple mathematical symbols for the basic comparators we've use since elementary school. Shame about the fucking mess with = and ==.
Languages are best served when there is one way to express a statement, rather than two (or three, or four, etc.) By making expressions consistent, it is easier to learn and read.
Perl is a classic example of punctuation gone awry, although it is not alone in this regard.
Someone you trust is one of us.
Are there any non-English languages or anyone using the language for whom English is a challenge? If there are, the use of symbols would seem to be preferred over remembering what the first letters of "plus que" are in English. (FTW.)
I tend to use "GREAT THAN", "LESS THAN" and "EQUAL TO", but only if I have enough space on the line.
Minne-snow-da: Winter is comming...
Really? This guy wasted time and electrons on this?
This post marks the new low mark of sharkjumping for /.. Good for the /advertisement for the expensively bloated carcass that is SAS.
But really though, fuck you.
">" is universally understood in mathematics
"GT" relies on a knowledge of English, and what it stands for, and thus what it means.
But the bigger question - WHY does any language created nowadays have hard-coded operator names? If you prefer >, why not just use that and make it equivalent to GT in whatever default settings you provide? Why are you constrained to the choice of operators given to you and the mnemonics they choose to use?
However, arguing over it is pointless. Change if it you can, otherwise it doesn't matter. If you can change it, or overload it, or rename it, or macro-ise it as you like, than it doesn't matter either.
And how do you play >A?
“He’s not deformed, he’s just drunk!”
What about Lesser Turismo?
They unfortunately used perl as an example. While yes Perl does have both gt and > one is a string comparison and the other is a numerical comparison.
Your hair look like poop, Bob! - Wanker.
To me it a logical operation is part of an equation and symbols make much more sense than abbreviations. Mixing symbols and mnemonics just confuses things.
The problem with is it could be a forwards arrow or 'greater than or equal to'
It means different things amongst the languages most people use most of the time.
Overloaded terms suck. Let's not do that.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
I never learned APL, but I do prefer > over GT
You use the symbolic. They are concise, they help with the processing in the meat brain (if writing words was better for humans parsing formula, then mathematicians would never have resorted to formula), and they don't need to be translated when going to a language where Greater Than doesn't abbreviate to GT.
It's one thing to use ">" for "less than". It's a whole nuther thing to use it for things like bit shift ">>" or dereference "->" And then there's the various uses of "+" and worst of all "=" vs "==".
I'm firmly convinced someone will write a paper on "C Syntax Considered Harmful," and symbol misuse is one aspect of C that causes bugs.
It is ironic that theodp spends all of his time complaining about H1B's, yet people waste time on stuff like this. If you actually did meaningful work, maybe the H1B's wouldn't be taking your jerb.
Mnemonics like GT or LT make no sense unless you program in assembly.
If you can enhance languages like C++ to accept them, then use 'greater' etc.
I'm working on my own language, too. Close to programming languages but easy to read and easy to type on tablets. Sure, I could craft a full IDE and habe a custom keyboard.
However the constraints that are the reason that some languages use -eq or .eq. as comparission operators are long gone.
What I don't get e.g. why people insist to use def for both variables and functions ... other languages use func, var, val, let.
Sorry: all that makes teaching languages just complicated. Why is it so hard to either use a mnemonic that indeed tells what it is: const instead of val in Scala or let in Swift or just write it out? On top of that I'm still a fan of the Pascal way. Just have a label introducing a section ... the C# and Java way where you have to write "(static) (final) public Type var" for every line of code just causes me eye cancer.
I basically only switched to Groovy and a bit of Scala (and disabled syntax colouring) to type less (and read less!) and be not slain by a wall of what looks like random colours to me. I for fuck sake know that a final variable can not be assigned to, and why for fuck sake is anybody expecting that I'm so dumb that I overwrite such a variable, and if I would who cares, the compiler would flag it: so why must it be displayed in an eye cancer causing colour? On top of that: I would never memorize those colours ... a waste of brain power.
So if you plan for new languages, make them please less C/Java/C# like, we have to many of those already.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
A reasonable mixture of both conventions should be used, and it's a bad idea to have synonyms for primitive operations. Readability is more important than being able to type code fast.
A good language defines a minimal set of primitive operations and allows the user to define the rest, including infix, postfix, and prefix operators, so it's not clear to me what the problem is.
GT can be greater than >, after all how much less than can > be LT ?
"Functionally, the operators are equivalent, so which ones you use is largely a matter of personal preference"
That's it!
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
When the symbols are in common use and are being used in the conventional sense (such as >), then go with the symbol.
Examples:
C: a > b, common use and used by convention. Should be used.
LISP: (> a b), common use but not common convention. Probably should not have been used.
ASM: J>, not common use nor common convention. Thankfully it wasn't.
It should also be noted that mnemonics aren't an ideal solution either. Mnemonics relies upon the reader understanding the context since any given mnemonic may have several meanings. While useful in print, people also have a nasty tendency to say the mnemonic as the mnmonic while talking (that is to say GT as gee-tee rather than as greater than). This obscures the meaning, which should be frowned upon.
On a related note I've wondered if > and < and + and -, are really the best symbols for their use. Clearly addition as "adding to", and subtraction is "taking away", os the natural symbols for those would be arrows. 5 <- 4 is 9 and 5 -> 4 is 1. Hence > and < seem like better symbols for addition and subtraction.
It's all squiggles on the screen that I have to learn to interpret in the correct context.
“Common sense is not so common.” — Voltaire
I started off programming in Algol in the sixties. I have used symbols and abbreviations.
Abbreviations can give you clashes with variable names. You normally learn what to avoid, but it is easy to have integers i, j, k, and floats if, jf, and kf, and not notice what you have.
That being said, it is a shame we don't have the right symbols on your keyboards. I would like... - Separate single symbols for assignment (:=) equality (==) and perhaps identity, or deep equality - The set cup and cap symbols for logical operations and tests (how many people evaluate CATS and DOGS as CATS and/or DOGS when they write. - A separate decimal and period.
Instead we have all sorts of weird junk, such as the '' symbol on the top right, which only appears in the correct spelling of Lord Xenu's full name. Or something.
Heigh-ho, ain't gonna happen. But we can dream.
Most languages have used roughly the same operators for at least 40 years. Generations of programmers know > is greater-than. Leave it alone.
Back when Fortran came out, keyboards weren't standardized yet. Also, some systems used variations of 7-bit or even non-ASCII encodings like EBCDIC. The > symbol wasn't guaranteed to be present on a given keyboard or even in the codepage. Using GT was out of necessity, no other reason, because letters were guaranteed to be on every keyboard and in every codepage.
Later languages (such as C and BASIC) were criticized for their lack of portability, but eventually because of them, ASCII became a standard.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
I'm actually designing a new language, syntactically based on python but adds rule based programming and many operators for tensor calculus and constructive solid geometry.
My question is how do people feel about typing non-ASCII characters.
For example, the union of two spatial domains, should it be "c = union(a, b)" or "c = a \{insert big U symbol here\} b", or how about lambdas, or better yet, circle plus for tensor operations.
I realize most people here probably don't do much involving many mathematical operations, but what do you guys think about non-ascii characters in programming languages. What I'm thinking about is having an operator system such that you could type in the statement "c = union (a, b)" in a plain text editor, but the operators would be define such that they would include some sort of pretty print or symbolic form, so that when viewed in a special editor, they could be viewed as full unicode glyphs.
Shame about the fucking mess with = and ==.
When I did a "desk language" (a notation for writing code on paper notes, which might have had a compiler written for it later), about the time C was being developed (but before I had access to it), one of the things I did was carefully avoid items like that. One thing I did was ban the bare equal sign.
":=" Replacement (also: like C, unary ops had before and after replacement forms - by adding : the same way C adds =, i.e. ":+" and "+:"
"==" Equality
"===" Equivalence (Two variables are aliases for the same storage. Think "union" but as a separate "put these two things in the same storage / use this symbol (perhaps as a different type) for the same bits as that one" declaration.)
I also had the logical and bitwise operators swapped from the way C did it - because "||", "&&", etc. are mnemonic for a string of bits. (This proved to be the biggest stumbling block when I started coding in C.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
gt ge lt le eq ne or xor and mul div add sub
That's fine. But what's the mnemonic for a bitwise or?
What a waste of time.
You mean Forza, right?
> In bad cases, it can take a couple weeks to write ten lines of code
Absolutely agreed. And my ten (or 100) lines do the same task that someone else's 3,500 lines did, and do it more elegantly, because I'm using meta-programming.
On the other hand, at the shell, it's helpful if the typing is fast enough that it doesn't effect my train of thought, which can be fast for tasks I know. You mentioned hunt and peck. That ends up being think, stop, hunt, peck, stop, think, stop, hunt, peck, think, stop - breaking one's train of thought. There's a qualitative difference when you're just thinking and the typing takes place automatically, in another mental "thread".
He includes Perl as a language that has both symbolic and mnemonic operators, and says that functionally they are equivalent, but this isn't really correct. In Perl, for example, "==" is not the same as "eq": one is a numeric comparison, the other is a string comparison and for consistent results the correct operator must be used.
The real "Libtards" are the Libertarians!
Certainly the statement:
add a to b giving c
is vastly superior to the statement:
c = a + b;
How could anyone have thought otherwise?!?
Next on the todo list -- the quadratic equation ... COBOL style ;)
I've seen that sort of operator overloading. For some reason it made sense at the time, though I can't remember why.
Best Slashdot Co
COBOL doesn't have GT, but it does have GREATER. Is that sufficiently symbolic?
[nt]
File under 'M' for 'Manic ranting'
I did too, but I was thinking the car, not the video game.
"GT" is in fact a mnemonic for "we don't fucking have the fucking > symbol on the fucking IBM 026".
This is weapons grade stupid. This ranks up there with "let's talk about the best editor". People who write articles like this aren't actually attempting to make a point we should care about. They're talking for the sake of hearing themselves talk.
BeauHD. Worst editor since kdawson.
In C I've been a fan of iso646(.h) ever since its proposal: it replaces ||, && and other boolean operators by 'or', 'and' and more readable things like xor.
Non-Linux Penguins ?
A computer language, at least so far, is a means for a human to write something in a structured manner that can be turned, eventually, into sequences of instruction execution that do what the human intended.
Clarity -- particularly for the newcomer to a language, but also for creation, debugging and maintainance purposes by those who are relatively expert -- trumps conciseness up to a point. This, I think, is why languages with syntax of similar densities to APL are not popular.
We could say ">", "GT" or "gt", or perhaps even "greater than." I'd be quite pleased with a language that understood all three to be the same thing, with similar broad expression capabilities for everything else as well. It would be useful, I think, to be able to run source code through a translator that made it concise for expert use, and explicit and English-like for the newcomer.
My outlook on this matter has always led me to write in a less visually compact, airy form, and to avoid (or reformat) coding style based on K&R bracing, which I consider obfuscatory. Writing code in a manner that uses the formatting of the code to cue the action of the code is my intent; that fits in very well with the idea of having the ability to expand or collapse code at various levels of terseness. Thinking about it now, it strikes me to on a par with the ability to collapse and expand a function to and from its declaration in a source code editing tool.
I write in a number of languages, so the syntax I'm working with changes a lot. When a language uses "&" differently than "and", for instance, I often become disoriented. It think it would be useful to me to have the code expandable to "binary and", "logical and" or whatever the particular distinction is.
My argument isn't so much for conciseness over wordiness, but more for clarity. For some experts, clarity may be a concise representation. For others, it may not. Perhaps in designing computer languages, we should consider accommodating more types of expertise than that which is found in the APL programmer.
I've fallen off your lawn, and I can't get up.
Just as an example, I personally prefer mnemonic (as in Pascal's begin ... end or more precisely Ada's if ... end if) to C/C++/Java's symbolic {... }, particularly when the block markers are optional. Don't get me started on Python's indentation blocks; while I like the notion of required indentation it adds its own little problems for readability/writability.
As for relations operators, I have no real preference of symbols or mnemonics except that the language should clearly delineate symbolic operators. We are all quite aware of the curse that is C-style operators (= vs. ==, & vs. &&, | vs. ||, etc.) when they are combined with the C-style "anything can go anywhere" mentality. Ask yourself how many egregious security bugs have their roots in things like an accidental = instead of ==.
Just remember, there are only so many reasonable symbols available for a programming language. Mathematical operations are some of the more consistent symbols used across programming languages (as they are inherited from mathematics) and are also some of the most well understood. That is until you start looking at some of the lesser used ones like ** for power (FORTRAN) or was that ^ -- no that's a pointer (Pascal) -- or was that -> -- or was that &-* notation ... and the list goes on and on.
#define gt >
DindinX
Have gnu, will travel.
Nobody who has written shell script where > is already -gt as far as the test command is concerned.
Ever since I started doing a lot of shell, "greater than" has become gt in my head. When i type > I think "gt", unless I am using "less" where its actually a command, and then I am thinking "end"
So really, I am unsurprised by this question, but at the same time > never stopped being "gt" or "greater than", its a symbol for that. When I see $ I think "dollar" as well, but one does not mean it more than the other, they are the same thing.
"I opened my eyes, and everything went dark again"
I tend to use mnemonic operators (such as GT) for every second operation and symbolic operators (such as >) for every other operator. ...wait, I think I got that backwards.
https://xkcd.com/927/
Depends. I was a supporter of all-symbolic languages, but I changed my mind. Languages like Python, were *logical* operators (and, or, not) are spelled in English, while mathematical expressions are in symbolic form, are the easiest to read.
Overusing english words, or overusing symbols, is equally bad.
Writing code: It does not matter at all. Reading code, symbols are hugely superior as they provide visual separation. And none of this is research-worthy, as it is obvious. There is a reason mathematics has been using symbols for a long, long time.
That said, symbol sets available on a computer are limited dues to input limitations (PC Keyboards). So logical operators will often be written out. That is inferior to symbols, but as they are full words, it is less of a problem. Human beings are great at recognizing full words. (No, "gt" does not qualify as a full word.)
Incidentally, it also depends on what people are used to. For example, when I use set operators in code, I use that LaTeX names.That works reasonably well.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
relatively recent scripting languages like Perl ... Functionally, the operators are equivalent, so which ones you use is largely a matter of personal preference
That is not the case in Perl at all! In Perl, operators like gt and lt are for string comparisons, and operators like are for numeric comparisons. Since in Perl you can conveniently transmute numbers intro strings and vice versa, which operator you use can make a whole lot of difference!
Secession is the right of all sentient beings.
Damn, some people are lucky to have jobs where they can ponder such trivia.
SAS has at least five different ways to express "not equals" in the data step, one of which ("") means something completely different in a different part of the software (SQL). So the case for using NE is pretty good.
Why not replacing all mathematical operators?
if( 5 gt 3 plus 8 times 2 )
Twice as many characters and only makes sense to English speakers. The > and symbols are universal and unambiguous. What the fuck provlem is this meant to solve? How about GTOET for greater-than-or-equal-to? P for plus?
Mnemonics are worse. The reason is that they are less consistent. Everyone can tell what > means, but there are just too many ways to represent 'greater than' mnemonically (even if you assume English is the only language that matters). Doing so is also inconsistent with the other mathematical operators. I don't know about you, but I'd hate to see code like this:
if bgn bgn 5 pls 9 end div 3 end eqls val then doMyCode()
to represent something like
if ((5 + 9) / 3 == val {do my code()}
Excessive use of acronyms is also not that great of a practice. They are lossy by definition and therefore can mean more than one thing.
The problem isn't the assignment operator =. The problem is the equality operator ==. Everyone should know that <> is the inequality operator from BASIC. Thus for equality they should have used !<>. Makes perfect sense to me.
Better known as 318230.
The state of set operators is terrible. In a lot of languages, you have to do crap like MyHaystack.Contains(MyNeedle). SQL has set operators, but not much better. I have always hated SQL predicates of this sort:
SELECT *
FROM ORDERS
WHERE Orders.OrderNumber >= 6 AND Orders.OrderNumber < 56;
It's just so much to type. Wouldn't it be much nicer if we could just use the set operators we learned in algebra?
SELECT *
FROM Orders
WHERE OrderNumber [6,56);
-- Argh! Slashdot... there should be an "element of" operator (epsilon) there after OrderNumber...
-- but alas, you have filtered out the ∈ entity.
See here for what should really display above.
I do most of my SQL in the Watcom dialect (SAP SQL Anywhere) . You can do:
SELECT *
FROM Orders
WHERE OrderNumber BETWEEN 5 AND 10;
which is nice... but I like the idea of being able to express (shortly) both open and closed intervals.
You can also say:
SELECT *
FROM Orders
WHERE OrderNumber IN (5,10);
but that means in the set {5,10}, not the open interval (5,10), which I find to be confusing.
Part of the issue is that the set operators (e.g. epsilon) are not on 101-key standard US keyboards and are hard to type. The other issue is that the set and interval delimiters (, ), {, }, [, and ] have been misappropriated as code block delimiters. My first commercial-grade high-level language was PASCAL, and I thought BEGIN and END were just fine (they persist in Transact and Watcom SQL today). I also like Python's group-by-indent approach.
You can have both! We should all change our computer languages to use this: >
Math uses ">" instead of "GT" and when we use that operator, we're doing math.
End of discussion.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I suspect some people do not remember using 5 hole paper tape or CDC punched card code.
Sent from my ASR33 using ASCII
Back in kindergarten or first grade, my class did a worksheet on < and >. Each problem was a pair of numbers with a circle between them. We were to put either < or > in the circle. After we completed the assignment, the teacher had us correct our own papers; she would call out "less than" or "greater than" for each problem. I was baffled. I had no idea what she was talking about. Even though I answered every problem correctly, it hadn't occurred to me that these two symbols had names.
And even if I had know the names of the symbols, I didn't see a reason that the expressions should be read from left to right. I just put the big end of the symbol near the bigger number and the small end of the symbol near the smaller number.
This begs the question: are they really different operators, or are you just writing the same operator in a different orientation? The fact that we type them differently is perhaps an artifact of the way we encode text on computers. We don't represent characters as a codepoint+rotation duple; instead, we can only record different characters, with a different glyph for every orientation.
"=" is the only relational operator which is commutative. a = b implies b = a.
= (Slashdot filters out the single glyph representation of this operator, U+2264) is not commutative. a = b does not imply (or preclude) b = a.
Is there a name for the property of "" which is that a b implies !(b a)? You could call that operator "anti-commutative", perhaps?
For completeness sake := is a blocking assignment. Meaning that the next instruction is not executed until the assignment is completed.
You also want a non-blocking assignment. The actual assignment is delayed (and may be overridden in following non-blocking assignments). Instructions following a non-blocking assignment will be executed before the assignment is executed and thus work as if the variable has not been modified. The actual assignment will execute at the next iteration.
Non-blocking assignments are used in ladder logic, or RTL (register transfer level) languages where electronics is designed in (FPGAs and such). Potentially non-blocking assignments could be used in streaming logic like GPU programming.
Anyway languages like VHDL and Verilog use := for blocking assignments and = for non-blocking assignments. I find = a bit distasteful as it is the same as less than.
Seriously, why choose? Build the operators in mnemonic form, add semi-decent operator overloading/defining, and then overload/define the symbolic to represent the mnemonic. Something like:
bool ge(int a, int b) { blah blah probably inline assembly code or built-in function }
bool operator>=(int a,int b) { return ge(a,b); }
(or just let operator>= be callable as a function or via the overloaded operator. Rather like C++ for user-defined operator overloading, but unlike C++ make it applicable to even simple types so you can explicitly write operator>=(a,b) for integers a and b (last I tried C++ doesn't let you do this, assume it's still true for C++11 or whatever we're up to))
Actually in my dream language that's how *all* symbolic operators would come about, not just the logical ones. Start with a language that is as simple and symbol-free as possible (you'd probably need things like scope operators at base level I guess), properly design a mechanism for defining/overloading operators into the language, then start defining your symbols on top of the underlying language. Let the programmer pick and choose what's appropriate for their code/style.
"==" Equality "===" Equivalence
So you would have moved the confusion up one character. Instead of a confusion between "=" and "==", you'd have it between "==" and "===".
For completeness sake := is a blocking assignment. Meaning that the next instruction is not executed until the assignment is completed.
You also want a non-blocking assignment. The actual assignment is delayed (and may be overridden in following non-blocking assignments).
Had that: "=:", as with "+:" vs. ":+", etc. Like C's equal-sign-concatinated-with-unary-op semantics, the side the colon is on tells you whether the store occurs before or after the whatever.
Equal sign in my language COULD have been considered a unary do-nothing/"make a local copy" operator (i.e. "foo", "= foo", "= = foo" etc. are all the same thing - except that all but the first might not be acceptable as the target of an assignment, or might result in the store being discarded) - except that, as a special case, a single equal sign was explicitly forbidden to stand alone in an expression.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Arg! Edit failure: (Previewed it too and missed it anyhow.)
Correction:
Equal sign in my language COULD have been considered a unary do-nothing reference-to-the-thing operator (i.e. "foo", "= foo", "= = foo" etc. are all the same thing) and stop there. If thinking that way, "= foo" IS "foo". Otherwise ":=" and "=:" wouldn't store anything. B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Mnemonic operators are coming back in REST and other URL-based APIs. For example in OData v4: http://docs.oasis-open.org/oda...
==, !=, are used for string comparison inBash.
In fact you can use '=' for string comparison in Bash according to POSIX. For this reason I think bash would be a great first scripting language >;)
-eq, -ne, -lt, and -gt are used for integer comparison in bash.
... they just don't exist for all operators. https://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B
Logical and/or exist, etc.
I didn't expect that to be an issue.
Equivalnce is rare and stand-alone, unlike equality comparison, so triple equal would rarely be emitted and, when it was, it would be in a storage declaration, where double-equal would be a syntax error - as triple equal would be in an expression. It would normally only be emitted as a typo, rather than a brain-o, and the compiler would typically catch it.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I use vim for editing code. I set defined some aliases so I type (or typo) what I want and vim generates the proper code.
I didn't expect that to be an issue.
I expect that the person who came up with "==" for equality didn't think it would be an issue.
Equivalnce is rare and stand-alone, unlike equality comparison,
I don't know what you mean by "stand alone". All of these operators are part of programs. IIRC, the introductory texts for Python put a great deal of emphasis on figuring out if your variables are stored in the same memory location, since IIRC Python does that a lot.
it would be in a storage declaration,
How do you test for "equivalence" between two things if they haven't been defined yet?
as triple equal would be in an expression.
So you would not allow a "triple equal" conditional expression? "If these two things are stored in the same memory location do this..." would be illegal?
How do you test for "equivalence" between two things ...
You misunderstand "equivalence" in this context.
It is not a test, not a kind of comparison. It does not direct the program to do anything,
It is a declaration of storage allocation. It tells the compiler that two symbols refer to the same storage.
In c, for instance:
union {
long int i;
float f;
} intflloat;
Lets you say:
intfloat.i = 0xfedcba89;
some_float = intfloat.f;
and some_float gets a floating point value whose bits are 0xfedcba89.; In SAN you'd say:
int32 i
float f
i === f
Then:
i = 0xfedcba89
some_float = f
does the same thing.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Anything that is used as often as a comparator doesn't really matter, because you will quickly learn to recognize and recall it. Call "greater than" "susan" and after a few days you will know what "A susan B" means without even thinking.
However, if anyone found a better way to memorize things that you use once in a while (say, once a week or once a month); things like obscure class names in Java or particularities of certain R statistical packages (which parameter changes the direction of labels, was it "las" or "lus"? Does 1 mean "bottom" or "left" in the "pos" parameter? What was the name of that package that did this little thingy and had this nice function to produce such great plots...) then I would find the discussion not a complete waste of time.
If only there was something to help us with that... like, if there were environments or editors that would enable us to quickly search available libraries, autocomplete, look up manuals...
Oh wait.