While working in my JS code today, I found the following situation and can not explain myself what should be the correct output ?
'sachin' > 2 // False
'sachin' < 2 // False
'sachin' == 2 // False
I expect result of either of < or > should be true. What am I missing ?
When the runtime attempts to convert 'sachin' to a number, it will fail and end up as NaN. That special constant results in false for any comparison to any other numeric value. The NaN constant ("Not A Number") is not equal to any other value, nor is it less than or greater than any other value.
edit — the ==, <, and > operators all "prefer" numbers to strings. If one operand is a number and the other a string, they'll always try to interpret the string as a number. It doesn't matter what order the operands appear in; what matters is the operand types.
(Strictly speaking, the results of < and > when NaN is involved are supposed to be undefined, according to the spec, but Firefox seems to give false instead.)
Related
This question already has answers here:
Why NaN is greater than any number in JavaScript? [duplicate]
(2 answers)
Closed 4 years ago.
I am trying to make some conditional statements while trying to solve a coding challenge. I have kept track of all the occurrences of letters of two strings in different objects. When I try to compare them by their counts if the count is undefined in the other object it evaluates to false even though the first value is truthy.
However;
1 > Boolean(undefined) evaluates to true. However 1 > undefined evaluates to false. Is there reason why the behavior is so ?
Javascript does a lot of funky casting when you compare things together that usually shouldn't be comparable.
1>undefined casts undefined to a NaN, and you can't compare a number to a Not a Number so any comparison will return false >,<,== etc
When you do 1>Boolean(undefined) undefined is cast to its boolean equivalent false, then when it's compared it will be cast to a 0, you can confirm this by doing Number(Boolean(undefined)) and since 1 is bigger than 0 it returns true.
In order to use the comparison operator >, both operands must be numeric. 1 already is, so Boolean(undefined) (which evaluates to false by the way) must be converted to a number. When it is, you get 0.
// First, convert undefined to a Boolean
let bool = Boolean(undefined)
console.log(bool);
// Then convert that to a number
let num = Number(bool);
console.log(num);
So, 1 > 0 is true.
Things to understand:
JavaScript is a "loosely" or "weakly" typed language. This means that data can, and often is, implicitly converted (coerced) into a different type category.
All data can be classified as "truthy" or "falsy", which means that if converted to a Boolean, would it convert to true or false. Things like null, undefined, "", 0, false, and NaN are all "falsy". And false in JavaScript (and most other languages) converts to the number 0, while true usually converts to 1.
I have compared some strings and numbers to see the result as true and false
"dfdf" > 1
false
"dfdf" > 99
false
"dfdf" > 9999
false
"dfdf" > 99999
false
1> ''
true
1> '545'
false
1> '545d'
false
1> '555'
false
1> 'ddfdf'
false
9999 > 'dfsdfadf'
false
I have tried few different combinations in the code as you can see but got the mixed result and want to know how exactly the comparison works in javascript.
another addition which is even more confusing
"dasfads" > "dasfdsf"
false
"abc" > "a"
true
"abc" > "agf"
false
"abcf" > "agf"
false
Comparing a string to a number will force the string data to evaluate into a number value. If the string data is not convertible to a numerical value it will return a NaN number to the given comparison.
Since NaN is not comparable nor equal to anything at all, not even to another NaN
NaN == NaN > false
The 'greater than' or 'smaller than' NaN comparison will have to return false both ways. Because that's the only correct answer, nothing can be greater nor smaller than the value you don't have. Therefore both claims are false. e.g.: 0 > NaN and 0 < NaN > false.
But keep in mind that comparing two strings of data such as:
"98A" > "999" will return a comparative false,
whereas:
"9A" > "999" will return true
Which is a very powerful thing to know, because knowing this (two strings will be compared by alphabetical order of magnitude) you are able to compare time data without taking the burden of converting those values to numbers and directly go with:
"09:32:28" > "09:31:59" > true
And luckily "PM" > "AM" > true by pure (linguistic) chance.
It is attempting to cast the string to a number.
In the console, if you do
x = +''
then x will be set to 0. 1 > 0 is true.
For all the other ones, if you do something like
x = +'dfdf'
then x will be set to NaN (not a number), and any comparison with it will return false.
There are 2 types of comparison available when using JavaScript,
The standard equality operators (== and !=) use the Abstract Equality Comparison Algorithm to compare two operands. If the operands are of different types, it will attempt to convert them to the same type before making the comparison, e.g., in the expression 5 == '5', the string on the right is converted to Number before the comparison is made.
The strict equality operators (=== and !==) use the Strict Equality Comparison Algorithm and are intended for performing equality comparisons on operands of the same type. If the operands are of different types, the result is always false so 5 !== '5'.
So if you want to know what is happening there, JavaScript is trying to convert the string into a Number and then do comparison, however, since they are not a number, which is always converted to NaN, and comparison with NaN will be equal to false.
Link for details:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comparison_Operators
String Vs String
The comparison is done character by character when you are comparing strings. First different character found in both string will be compared using their char codes. (Note: Chars after that will be ignored.)
>> "a".charCodeAt(0)
97
>> "}".charCodeAt(0)
125
>> "}" > "a"
true
>> "-}" > "a"
false
String Vs Number
Any time a string is compared with a number the string is converted into an integer and then both are compared. If the string can't be converted into a number, then it returns false. (Note: NaN, Nothing can be compared against NaN. Any comparison with NaN will return false)
>> 'dfsdfadf' > 999999 // Can't be converted to integer, hence false
false
>> 'd' > 9999999999 // Can't be converted to integer, hence false
false
>> '' == false // '' is empty string which is 0 or false
true
>> 1 > '' // '' is false,0 explained in prev case
true
EDIT: I will rephrase my question, I type Number < String and it returns true, also works when I do typeof(2) < typeof("2").
Number < String => true
typeof(2) < typeof("2") => true
I'm guessing it is the value of ASCII characters of each letter in Number and String but I am not sure if that is the reason this is returning true, and I want to know why does this happens, what processes or how does the interpreter gets to this result?
First answer:
The charCodeAt() method returns the numeric Unicode value of the character at the given index. Read here
Now if you do not specify any index position then character at 0th index is considered. Now, S ASCII value is 83 and N ASCII value is 78. so, you are getting those number. Check here.
And 78 < 83 => true is obvious.
Try "String".charCodeAt(1) and you will get 116 which is ASCII value of t
Second answer based on OP's edited question:
Frankly speaking your comparison Number < String is "technically" incorrect because Less-than Operator < or any similar operator is for expressions, and Number and String are functions and not expressions. However #Pointy explained on how Number < String worked and gave you results.
More insight on comparison operators
Comparison operators like < works on expressions, read here. Typically, you should have a valid expression or resolved value for RHS and LHS.
Now this is the definition of expression, read more here - "An expression is any valid unit of code that resolves to a value. Conceptually, there are two types of expressions: those that assign a value to a variable and those that simply have a value."
So, (x = 7) < (x = 2) or new Number() < new String() is a "technically" valid/good comparison, even this Object.toString < Number.toString() but really not Object < Function.
Below are rules/features for comparisons, read more here
Two strings are strictly equal when they have the same sequence of characters, same length, and same characters in corresponding positions.
Two numbers are strictly equal when they are numerically equal (have the same number value). NaN is not equal to anything, including NaN. Positive and negative zeros are equal to one another.
Two Boolean operands are strictly equal if both are true or both are false.
Two distinct objects are never equal for either strict or abstract comparisons.
An expression comparing Objects is only true if the operands reference the same Object.
Null and Undefined Types are strictly equal to themselves and abstractly equal to each other.
The result of
Number < String
is not the result of comparing the strings "Number" and "String", or not exactly that. It's the result of comparing the strings returned from Number.toString() and String.toString(). Those strings will (in all the runtimes I know of) have more stuff in them than just the strings "Number" and "String", but those two substrings will be the first place that they're different.
You can see what those actual strings are by typing
Number.toString()
in your browser console.
JavaScript does the following thing:
"String".charCodeAt(); => 83
"S".charCodeAt(); => 83
"String".charCodeAt(0); => 83
The method charCodeAt(a) gets the char code from position a. The default value is 0
If you compare N > S you will get 78 > 83 => true
For the complete String Javascript calculates the sum of all ASCII char codes.
So I can answer your question with yes.
I was perusing the underscore.js library and I found something I haven't come across before:
if (obj.length === +obj.length) { ... }
What is that + operator doing there? For context, here is a direct link to that part of the file.
The unary + operator can be used to convert a value to a number in JavaScript. Underscore appears to be testing that the .length property is a number, otherwise it won't be equal to itself-converted-to-a-number.
According to MDN:
The unary plus operator precedes its operand and evaluates to its
operand but attempts to converts it into a number, if it isn't
already. For example, y = +x takes the value of x and assigns that to
y; that is, if x were 3, y would get the value 3 and x would retain
the value 3; but if x were the string "3", y would also get the value
3. Although unary negation (-) also can convert non-numbers, unary plus is the fastest and preferred way of converting something into a
number, because it does not perform any other operations on the
number. It can convert string representations of integers and floats,
as well as the non-string values true, false, and null. Integers in
both decimal and hexadecimal ("0x"-prefixed) formats are supported.
Negative numbers are supported (though not for hex). If it cannot
parse a particular value, it will evaluate to NaN.
It's a way of ensuring that obj.length is a number rather than a potential string. The reason for this is that the === will fail if the length (for whatever reason) is a string variable, e.g. "3".
It's a nice hack to check whether obj.length is of the type number or not. You see, the + operator can be used for string coercion. For example:
alert(+ "3" + 7); // alerts 10
This is possible because the + operator coerces the string "3" to the number 3. Hence the result is 10 and not "37".
In addition, JavaScript has two types of equality and inequality operators:
Strict equality and inequality (e.g. 3 === "3" expresses false).
Normal equality and inequality (e.g. 3 == "3" expresses true).
Strict equality and inequality doesn't coerce the value. Hence the number 3 is not equal to the string "3". Normal equality and inequality does coerce the value. Hence the number 3 is equal to the string "3".
Now, the above code simply coerces obj.length to a number using the + operator, and strictly checks whether the value before and after the coercion are the same (i.e. obj.length of the type number). It's logically equivalent to the following code (only more succinct):
if (typeof obj.length === "number") {
// code
}
As far as I know in JavaScript !! is supposed to normalize a boolean value converting it to true or false from some other type. This would mean that the "0" converts to boolean true. On the other hand if I compare it with false it turns out that it is in fact false (as the result of the comparison is true). What rule am I missing here. I have tested it in IE and Opera.
The == operator checks for loose equality, which has nothing to do with truthiness.
Specifically, it will convert to operands to numbers, then compare the numbers.
Strings containing numbers convert to the numbers that they contain; booleans convert to 0 and 1.
Objects are converted by calling valueOf, if defined.
Thus, all of the following are true:
"1" == 1
"0" == false
"1" == true
"2" != true
"2" != false
({ valueOf:function() { return 2; } }) == 2
({ valueOf:function() { return 1; } }) == true
In the first case, a non-empty string is equivalent to true.
In the second case, because one operand is a boolean, both operands are converted to numeric values. I believe false converts to the numeric value 0 and the string "0" also converts to a numeric 0, resulting in 0 == 0 which is true.
Check out the Mozilla reference for operator behavior.
For the first expression, section 9.2 of ECMA-262 defines an abstract operation ToBoolean internally used by the logical NOT operator. It says:
String
The result is false if the argument is the empty String (its length is zero); otherwise the result is true.
For the second expression, JavaScript will perform type coercion when it attempts to compare these values of different data types. Douglas Crockford says that this is a misfeature. It would be false if you had used === instead of ==. The rules are rather complex, so you should directly look in section 11.9.3 of ECMA-262 for the details.