Riddle Time

Question

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

Answer 1

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.

Answer 2

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...

Answer 3

kudos for the extensive research @dplusplus
you are really close

i would suggest you focus on the >= operator documentation and its final steps

Answer 4

Haha! Nice riddle.
So, 0 is not smaller than null.
And because of that >= returns true and > returns false?

Answer 5

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

Answer 6

it's good that you did
made me do my own research which led me to the conclusion of un-initialized value

Answer 7

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? ^^

Answer 8

Ah, I see. A null reference IS a reference ^^

Answer 9

@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 🤗

Answer 10

@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! :)))

Answer 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 :)

Answer 12

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.

Answer 13

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

Answer 14

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.

Answer 15

@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

Answer 16

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

Answer 17

ding ding we have a winner here!
here's a cookie for you 🍪 @Rob Blans

Answer 18

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

Answer 19

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

Answer 20

bingo
you can safely assume the algorithm does not throw an error and continues all the way