HN Explorer

Programming Question: When X != X?

4 points by malkia ↗ HN
Just curious about it:

Q1: In what situations X != X? Please, explain it in your language of choosing. Also consider different implementations, or run-time/compile-time versions of said language, system.

Q2: What are the common pitfalls associated with if such behavior exists?

12 comments

[ 5.1 ms ] story [ 43.1 ms ] thread
[deleted]
(comment deleted)
ww520
Can you elaborate on what X is? Is it a literal? A variable? An expression? A function call? A declaration? A constant? A pointer? etc?

Asking the right question provides half of the solution already.

malkia
Originally for floating-point, and being NaN (not a number).

For example a sorting routine might never finish, if it has to sort such numbers/values.

lurker14
Generally, X != X if evaluating X has side effects, or relies on any non-constant global state that might change (for example, in a multi-threaded program or in the presence of volatile data in C)
CastItUp
X could be .999... .9 repeating is a numerical number that technically does not equal itself, although I'm sure most compilers would round the number to 1; so I'm not sure if it's what your looking for. But as for a boolean, or an integer that would fit that solution, I cant think of any time that it could occur.

x = .999... 10x = 9.999... 10x-x = 9.999... - .999... 9x = 9 x = 1 .999... != 1

mooism2
0.9 recurring equals itself.

You prove above that 0.9 recurring equals 1 (the final step does not follow from what you write before), not that 0.9 recurring does not equal itself.

bartonfink
Given how floating point works, I'm not sure that the floating point representation closest to 1 would ever round to 1 (which is neatly representable). That proof works because you're working with real numbers, which have no encoding restrictions.
CastItUp
I think you are on the right track of where I am getting... Before running through all the code, x = .9999999, but at the end of all the operations, x = 1, so; if placed in a "for loop", with a condition outside of the loop, its possible that the compiler would return "false" for x = x.
bmm6o
The equality relation on the reals obeys reflexivity (as well as transitivity, etc). You're barking up the wrong tree. For a mathematical example, you'll need something much more exotic than R.
personalcompute
Some behaviour that trips up new programmers in C:

  "test" != "test"
Edit: To be specific, it results in undefined behaviour. The compiler may in fact allocate only a single block of memory for two literals if they are the same, which would allow this to evaluate to true.
DCoder
SQL NULL. Javascript NaN.

Their behaviour is defined by the standards and special checks are required to identify these values properly. In SQL, it's

  X IS (NOT) NULL
, in Javascript it'd be

  isNaN(X)
.

rand() (well, most of the time[1]). This you just have to know :)

Improperly expanding C macros:

  #define isupper(c) ((c) >= 'A' && (c) <= 'Z')
  #define X isupper(getchar())
  printf("X == X = %d\n", X == X);
And like lurker14 said, anything in general that has side-effects.

[1] It is possible rand() will return the same value twice in a row, just not very likely. Also the original author might have been twisted enough to memoize it. Thank you, "Higher order Perl", for that idea.

jitendra_
In R programming, you wouldn't get a TRUE or FALSE if you perform X != X when X is NA (Not Applicable). The result would be NA itself as it can't be determined.

You will have to use is.na(X) to find is X is NA.

So you don't just handle TRUE and FALSE cases but take NA into consideration as well.