+ 21

# Riddle Time

stumbled upon this intriguing case: https://code.sololearn.com/W46kfuYKbs3M/?ref=app run the code and explain the output you can research in the following page: http://interglacial.com/javascript_spec/a-11.html

20th Sep 2017, 7:53 PM
Burey
+ 8
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.
21st Sep 2017, 3:35 AM
Rob Blans
+ 18
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...
10th Sep 2017, 7:01 PM
dρlυѕρlυѕ
+ 14
kudos for the extensive research @dplusplus you are really close i would suggest you focus on the >= operator documentation and its final steps
10th Sep 2017, 11:09 AM
Burey
+ 13
Haha! Nice riddle. So, 0 is not smaller than null. And because of that >= returns true and > returns false?
20th Sep 2017, 8:25 PM
Tashi N
+ 12
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
10th Sep 2017, 10:27 AM
Burey
+ 12
it's good that you did made me do my own research which led me to the conclusion of un-initialized value
10th Sep 2017, 6:22 PM
Burey
+ 12
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? ^^
10th Sep 2017, 7:21 PM
dρlυѕρlυѕ
+ 12
Ah, I see. A null reference IS a reference ^^
20th Sep 2017, 9:13 PM
Tashi N
+ 11
@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 🤗
10th Sep 2017, 5:51 PM
Burey
+ 11
@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! :)))
10th Sep 2017, 7:39 PM
dρlυѕρlυѕ
+ 11
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 :)
20th Sep 2017, 9:19 PM
Tashi N
+ 11
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.
20th Sep 2017, 10:16 PM
Tashi N
+ 10
hint the answer lies in the specs of the following operator http://interglacial.com/javascript_spec/a-11.html#a-11.8.4 and take into consideration that: (0 < null) will also evaluate as false
10th Sep 2017, 5:56 PM
Burey
+ 10
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.
20th Sep 2017, 8:42 PM
Tashi N
+ 9
@Mohit focus on the two final steps of the >= operator the answer is quite simple once you review how the algorithm works http://interglacial.com/javascript_spec/a-11.html#a-11.8.4
11th Sep 2017, 1:00 PM
Burey
+ 9
but what about == returning false as well? big hint: read the specifications of >= carefully the answer is right there, hiding in plain sight ;) specs: http://interglacial.com/javascript_spec/a-11.html#a-11.8.4
20th Sep 2017, 8:29 PM
Burey
+ 9
ding ding we have a winner here! here's a cookie for you 🍪 @Rob Blans
21st Sep 2017, 5:23 AM
Burey
+ 9
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
21st Sep 2017, 6:17 AM
Burey
+ 8
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
20th Sep 2017, 9:12 PM
Burey
+ 8
bingo you can safely assume the algorithm does not throw an error and continues all the way
20th Sep 2017, 9:15 PM
Burey