So, the rules for the comparison primitives (<, >, ==) say that comparing 0 and null always returns false. (somewhat like the rule that says NaN == NaN is always false). But, >= and <= are not primitives. They are implemented in terms of <, >, and == Subsequently, because (0 < null) is false, the (0 >= null) will be true because '>=' just leverages the result of the '<' primitive.
If I've got this correctly it has something to do with the difference in how rational and equality comparison operators treat null. **For Relational Comparison it says that the operands are first converted to primitives (with hint on ToNumber) , then to the same type, before comparison. So if values are not type String, ToNumber is called on both, which for null coerces to 0 . Therefore: 0>= null; //true => because 0>= 0 is true. Equality comparison only calls ToNumber on Strings, Numbers, and Booleans. Null is considered undefined. null == undefined; // true Therefore 0 == undefined //false Am I making any sense? Thank you for this riddle, I didn't know about this...
kudos for the extensive research @dplusplus you are really close i would suggest you focus on the >= operator documentation and its final steps
Haha! Nice riddle. So, 0 is not smaller than null. And because of that >= returns true and > returns false?
let me focus the riddle: the interesting aspect here is the way the comparison algorithms work i am looking for an explanation of why: ((0 > null) == false) && ((0 == null) == false) but (0 >= null == true) the entire solution can be found by researching the emcascript documentaion in the link above
it's good that you did made me do my own research which led me to the conclusion of un-initialized value
OK, I surrender. ^^ I'm looking now at 9.3: 9.3 ToNumber The operator ToNumber converts its argument to a value of type Number according to the following table: Input Type Result Undefined NaN Null +0 Boolean The result is 1 if the argument is true. The result is +0 if the argument is false. Number The result equals the input argument (no conversion). etc. I've tried it like this... var y= null; var x = y; var a= 0; alert( 0 > x ); //false alert(0 >= x); //true alert (0 == a+x);// true // if I turn null into numeric value, the equation becomes true, isn't that exactly what's happening when ToNumber is called? Why is that not a solution? ^^
Ah, I see. A null reference IS a reference ^^
@dplusplus you posted something earlier that caught my attention regarding the ReferenceError exception it will happen in the following case: var x = y; alert(0 >= x); since y is not defined at all. but if you were to define it as null it would continue to the rest of the evaluation edit grats on platinum @dplusplus 🤗
@Burey Thank you. I wasn't sure about that so I wanted to read it later, it's a bit more complicated than I thought. .. I didn't fully understand getValue and that Reference Error so I didn't want to write some nonsense. edit: Thank you! :)))
With results you don't expect in first place and that will bring you a time of joyful time of table flipping when you've got to debug that :)
Pheeeew... As I understand the == reference, it runs to 11.9.3, calls ToPrimitive there, which can't cast null to a primitive and therefor returns null. Then the algorithm returns 22. -> false.
I just thought: undefined -> false? But shouldn't all the calls of GetValue() on null cause an exception? 'GetValue(V) 1. If Type(V) is not Reference, return V. 2. Call GetBase(V). 3. If Result(2) is null, throw a ReferenceError exception. ...' Tried it out in Java: Compiler says: nope, totally bad idea. Didn't wanna talk to me after that.
ding ding we have a winner here! here's a cookie for you 🍪 @Rob Blans
explanation: the key to this behaviour lies in the final two steps of the >= algorithm step 5 uses the < algorithm and step 6 returns false if step 5 returned either true or undefined otherwise it simply returns true as the < algorithm was used and we already know it returns false for this specific case, step 6 goes into the otherwise case which results in returning true
nope see what i wrote on this very thread: "regarding the ReferenceError exception it will happen in the following case: var x = y; alert(0 >= x); since y is not defined at all." evaluating null as null is ok the exception is thrown when there is no reference like "y" in the example above
bingo you can safely assume the algorithm does not throw an error and continues all the way