Develop Reference

Transitivity in javascript

In mathematics, = is assumed to be a transitive relationship. Transitivity means precisely what you stated: A = B and B = C implies A = C.But, from what I can see, javascript does not respect this transitivity principle.
For all of the below expressions, the output is TRUE
[]==0
true
0==[]
true
"0" == 0
true
0 == "0"
true
But, this is false
"0" == []
false
What is the reason behind it, and how compiler treat this expression?

Check out this documentation on the non-strict Javascript equality operator. It attempts to convert objects which do not have the same type, and while it apparently supports [] and 0, it does not have coercion for "0" and [].
My guess at the reasoning behind this: 0 is commonly used to represent the Boolean value of False. [] has a value of False when converted to Boolean, so it is expedient to say that [] == 0 in Boolean terms. "0" == 0, however, is true for a different reason; the string "0" represents the integer 0. In logical terms, the equality operator is actually representing two different relations, so transitivity does not hold between them.

The right-hand value is being coerced to a string.
console.log("0" == []) // false
console.log([].toString()) // ""
console.log("" == [].toString()) // true
console.log("0" == [0].toString()) // true
console.log([0, 1, 2, 3].toString()) // 0,1,2,3
console.log("0,1,2,3" == [0, 1, 2, 3]) // true

JavaScript's aggressive type of coercion leads to odd results. The string equivalent of an empty array is an empty string, so that is why it works.
As well, converting an empty string to a number gives zero, so you can also convert Array to Number.
The string "0" is equal to 0 because calling 0.toString gives "0".
But we said earlier that an empty array becomes an empty string, so we can't have "0" as a converted version of an empty array.
All this happens in the first place due to "==", which coerces types. With "===", none of these equalities are true.

why do both if('0'==false) and if('0') evaluate to true in Javascript?

So for what I know is that the if statement in Javascript casts the result of its condition to a Boolean, and then executes it likes the following
if(true) {
// run this
}
if(false) {
// do not run this
}
And that works. But If I do this:
if('0' == false) {
// We get here, so '0' is a falsy value
}
Then I would expect this
if('0') {
// We don't get here, because '0' is falsy value
}
But instead I get
if('0') {
// We *DO* get here, even though '0' is falsy value
}
So what's happening? Apparently, if does not check if its condition a truthy or falsy value, but does some other conversion?

This is just one of those "gotchas" with the == rules which are rather complex.
The comparison x == y, where x and y are values, produces true or false. Such a comparison is performed as follows:
(4) If Type(x) is Number and Type(y) is String,
return the result of the comparison x == ToNumber(y).
(5) If Type(x) is String and Type(y) is Number,
return the result of the comparison ToNumber(x) == y.
(6) If Type(x) is Boolean, return the result of the comparison ToNumber(x) == y.
(7) If Type(y) is Boolean, return the result of the comparison x == ToNumber(y).
In this case that means that '0' == false is first coerced do '0' == 0 (by rule #7) and then on the second pass through, it is coerced to 0 == 0 (by rule #5) which results in true.
This particular case is somewhat tricky because of false ~> 0 instead of '0' ~> true (as what might be expected). However, '0' is itself a truth-y value and the behavior can be explained with the above rules. To have strict truthy-falsey equality in the test (which is different than a strict-equality) without implicit conversions during the equality, consider:
!!'0' == !!false
(For all values: !falsey -> true and !truthy -> false.)

This:
if('0') {
// We *DO* get here, even though '0' is falsy value
}
checks to see if the string is null or empty, not whether it's zero or not. Any non-empty string is truthy.
When you do this:
if('0' == false) {
// We get here, so '0' is a falsy value
}
you are asking the JS engine for an explicit type conversion to try to match the type of the two operands. That is different than just asking if one operand is truthy all by itself.
In general, you will find that you get fewer unexpected results if you nearly always use === and !== and only allow type coercion when you know exactly what is going to happen in all cases either because you fully understand the very complex coercion rules or because you know what types will be present and you understand those specific cases.

if ('0' == false):
Javascript is doing something called type coercion.
Following the rules in that link, we fall to rule 7:
If Type(y) is Boolean, return the result of the comparison x == ToNumber(y)
Calling ToNumber(false) gives us a numeric 0. The result now starts to make sense, but we're still not quite done, because we still have a string and a number. The process starts again, and this time we fall to rule 5:
If Type(x) is String and Type(y) is Number, return the result of the comparison ToNumber(x) == y: "2" == 2
This time, the left side '0' is converted to a number: 0. Now, at last, we can compare two Numbers, and since 0 equals 0, the result is true. However, it's important to note that this implies nothing at all about the truish/falsy nature of the '0' string, because it was coerced before it was compared.
if('0')
In this case, there is no comparison; you only want to know if a single value is "truish" or "falsy". No type coercion is used, because strings can be evaluated as truish or falsy on their own merits. Using the rules at the same link as before, we find this information:
In JavaScript, and not only JavaScript, we have so called falsy values. These are respectively: 0, null, undefined, false, "", NaN. Please note the empty string is empty, 'cause differently from php as example, "0" will be considered truish
The quote is especially helpful because it specifically calls out the '0' string, but that would not be necessary. It's enough to know that an empty string is falsy, and any other string is truish, because the content of the string is not evaluated and no coercion is performed. 0 may be a falsy value, but because we evaluate a string rather than coercing to a number, and '0' has a value of some kind, it is still truish.

Javascript operator == does type conversion and is basically useless. Just avoid it.
For example:
[] is truty but [] == false is true
1 == "1", [1] == "1", [[1]] == "1" are all true
[1] == [[1]] however is false
The rules are VERY weird. For example in the first case [] gets converted to "" that gets converted to a number and the value is 0. false is also converted to the number 0. So in the end they compare equal.
Note however that while the conversion from the empty string to a number gives 0, the result of parseInt("") is NaN.
PS: The real fun is when you discover that [30,20,10,3,2,1].sort() returns [1,10,2,20,3,30] (yes... numbers, yes in lexicographical order). No I'm not kidding.

Why javascript treats 0 equal to empty string? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Implied string comparison, 0='', but 1='1'
Executing the following case in javascript, I get 0 equal to '' (an empty string)
var a = 0;
var b = '';//empty string
if(a==b){
console.log('equal');//this is printed in console
}else{
console.log('not equal');
}
Could anyone guide that what is the reason behind this?

Quoting the doc (MDN):
Equal (==)
If the two operands are not of the same type, JavaScript converts the
operands then applies strict comparison. If either operand is a number
or a boolean, the operands are converted to numbers if possible; else
if either operand is a string, the other operand is converted to a
string if possible.
As a operand type here is Number, b gets converted to Number as well. And Number('') evaluates to 0.
This can be quite surprising sometimes. Consider this, for example:
console.log(0 == '0'); // true
console.log(0 == ''); // true
console.log('' == '0'); // O'RLY?
... or this:
console.log(false == undefined); // false
console.log(false == null); // false
console.log(null == undefined); // fal.... NO WAIT!
...and that's exactly why it's almost always recommended to use === (strict equality) operator instead.

0, "" (Empty String), false all technically have the same value, when typecasted. If you need to strictly treat them, you can use ===.
It is the same with similar programming languages, like PHP.
var a = 0;
var b = ''; //empty string
if(a == b){
console.log('equal'); //this is printed in console
}else{
console.log('not equal');
}
To make a strict comparison:
if(a === b){
console.log('equal');
}else{
console.log('not equal'); //this is printed in console
}

== operator in javascript don't compare types so 0=='' === true (because as a number string '' evaluates to 0) or 0==false === true (because bool false evaluates to 0) to compare types to you can use === operator.
Here you'll find useful information about comparison.

Javascript automatically converts variables of different types for comparison. That's a common feature in non-strictly typed languages.
If you need to compare variables and check the type, use the === operator.

In most programming language(including javascript) ""(string), 0(integer), \x0(null) losely mean the same thing: "empty". What's happening is your javascript engine finds "" == 0 false, due to the == it converts 0 to an integer. Again this is false, so it converts 0 to null which is false, so then it converts 0 to an empty string. (Not sure if this is the correct order of conversion). To make the condition "exact" match(no conversion) use === inplace of ==

== does typecasting. Always use ===.
In your example, the empty string of b is being converted to 0. So both a and b are the same.

Because empty string represented as number is zero. If you compare apples and oranges you should think of how your particular orange would look if it were an apple.

Because of coercion. It is usually a better idea to use === for comparisons in JavaScript.

Because == checks value equality so false, 0 and empty strings are equals. Use identity check ===.

Why does isNaN(" ") (string with spaces) equal false?

In JavaScript, why does isNaN(" ") evaluate to false, but isNaN(" x") evaluate to true?
I’m performing numerical operations on a text input field, and I’m checking if the field is null, "", or NaN. When someone types a handful of spaces into the field, my validation fails on all three, and I’m confused as to why it gets past the isNaN check.

JavaScript interprets an empty string as a 0, which then fails the isNAN test. You can use parseInt on the string first which won't convert the empty string to 0. The result should then fail isNAN.

You may find this surprising or maybe not, but here is some test code to show you the wackyness of the JavaScript engine.
document.write(isNaN("")) // false
document.write(isNaN(" ")) // false
document.write(isNaN(0)) // false
document.write(isNaN(null)) // false
document.write(isNaN(false)) // false
document.write("" == false) // true
document.write("" == 0) // true
document.write(" " == 0) // true
document.write(" " == false) // true
document.write(0 == false) // true
document.write(" " == "") // false
so this means that
" " == 0 == false
and
"" == 0 == false
but
"" != " "
Have fun :)

To understand it better, please open Ecma-Script spec pdf on page 43 "ToNumber Applied to the String Type"
if a string has a numerical syntax, which can contain any number of white-space characters, it can be converted to Number type. Empty string evaluates to 0. Also the string 'Infinity' should give
isNaN('Infinity'); // false

Try using:
alert(isNaN(parseInt(" ")));
Or
alert(isNaN(parseFloat(" ")));

From MDN reason for the issue you are facing
When the argument to the isNaN function is not of type Number, the value is first coerced to a Number. The resulting value is then tested to determine whether it is NaN.
You may want to check the following comprehensive answer which covers the NaN comparison for equality as well.
How to test if a JavaScript variable is NaN

I think it's because of Javascript's typing: ' ' is converted to zero, whereas 'x' isn't:
alert(' ' * 1); // 0
alert('x' * 1); // NaN

The Not-Entirely-Correct Answer
Antonio Haley's highly upvoted and accepted answer here makes a wrong assumption that this process goes through JavaScript's parseInt function:
You can use parseInt on the string ... The result should then fail isNAN.
We can easily disprove this statement with the string "123abc":
parseInt("123abc") // 123 (a number...
isNaN("123abc") // true ...which is not a number)
With this, we can see that JavaScript's parseInt function returns "123abc" as the number 123, yet its isNaN function tells us that "123abc" isn't a number.
The Correct Answer
ECMAScript-262 defines how the isNaN check works in section 18.2.3.
18.2.3 isNaN (Number)
The isNaN function is the %isNaN% intrinsic object. When the isNaN function is called with one argument number, the following steps are taken:
Let num be ? ToNumber(number).
If num is NaN, return true.
Otherwise, return false.
The ToNumber function it references is also defined in ECMAScript-262's section 7.1.3. In here, we get told how JavaScript handles Strings which are passed in to this function.
The first example given in the question is a string containing nothing but white space characters. This section states that:
A StringNumericLiteral that is empty or contains only white space is converted to +0.
The " " example string is therefore converted to +0, which is a number.
The same section also states:
If the grammar cannot interpret the String as an expansion of StringNumericLiteral, then the result of ToNumber is NaN.
Without quoting all of the checks contained within that section, the " x" example given in the question falls into the above condition as it cannot be interpreted as a StringNumericLiteral. " x" is therefore converted to NaN.

If you would like to implement an accurate isNumber function, here is one way to do it from Javascript: The Good Parts by Douglas Crockford [page 105]
var isNumber = function isNumber(value) {
return typeof value === 'number' &&
isFinite(value);
}

The function isNaN("") performs a String to Number type coercion
ECMAScript 3-5 defines the following return values for the typeof operator:
undefined
object (null, objects, arrays)
boolean
number
string
function
Better to wrap our test in a function body:
function isNumber (s) {
return typeof s == 'number'? true
: typeof s == 'string'? (s.trim() === ''? false : !isNaN(s))
: (typeof s).match(/object|function/)? false
: !isNaN(s)
}
This function is not intented to test variable type, instead it tests the coerced value. For instance, booleans and strings are coerced to numbers, so perhaps you may want to call this function as isNumberCoerced()
if there's no need to test for types other than string and number, then the following snippet might be used as part of some condition:
if (!isNaN(s) && s.toString().trim()!='') // 's' can be boolean, number or string
alert("s is a number")

NaN !== "not a number"
NaN is a value of Number Type
this is a definition of isNaN() in ECMAScript
1. Let num be ToNumber(number).
2. ReturnIfAbrupt(num).
3. If num is NaN, return true.
4. Otherwise, return false.
Try to convert any value to Number.
Number(" ") // 0
Number("x") // NaN
Number(null) // 0
If you want to determine if the value is NaN, you should try to convert it to a Number value firstly.

I suggest you to use the following function if you really want a proper check if it is an integer:
function isInteger(s)
{
return Math.ceil(s) == Math.floor(s);
}

That isNaN(" ") is false is part of the confusing behavior of the isNaN global function due to its coercion of non-numbers to a numeric type.
From MDN:
Since the very earliest versions of the isNaN function specification, its behavior for non-numeric arguments has been confusing. When the argument to the isNaN function is not of type Number, the value is first coerced to a Number. The resulting value is then tested to determine whether it is NaN. Thus for non-numbers that when coerced to numeric type result in a valid non-NaN numeric value (notably the empty string and boolean primitives, which when coerced give numeric values zero or one), the "false" returned value may be unexpected; the empty string, for example, is surely "not a number."
Note also that with ECMAScript 6, there is also now the Number.isNaN method, which according to MDN:
In comparison to the global isNaN() function, Number.isNaN() doesn't suffer the problem of forcefully converting the parameter to a number. This means it is now safe to pass values that would normally convert to NaN, but aren't actually the same value as NaN. This also means that only values of the type number, that are also NaN, return true.
Unfortunately:
Even the ECMAScript 6 Number.isNaN method has its own issues, as outlined in the blog post - Fixing the ugly JavaScript and ES6 NaN problem.

The isNaN function expects a Number as its argument, so arguments of any other type (in your case a string) will be converted to Number before the actual function logic is performed. (Be aware that NaN is also a value of type Number!)
Btw. this is common for all built-in functions - if they expect an argument of a certain type, the actual argument will be converted using the standard conversion functions. There are standard conversions between all the basic types (bool, string, number, object, date, null, undefined.)
The standard conversion for String to Number can be invoked explicit with Number(). So we can see that:
Number(" ") evaluates to 0
Number(" x") evaluates to NaN
Given this, the result of the isNaN function is completely logical!
The real question is why the standard String-to-Number conversion works like it does. The string-to-number conversion is really intended to convert numeric strings like "123" or "17.5e4" to the equivalent numbers. The conversion first skips initial whitespace (so " 123" is valid) and then tries to parse the rests as a number. If it is not parseable as a number ("x" isn't) then the result is NaN. But there is the explicit special rule that a string which is empty or only whitespace is converted to 0. So this explains the conversion.
Reference: http://www.ecma-international.org/ecma-262/5.1/#sec-9.3.1

I'm not sure why, but to get around the problem you could always trim whitespace before checking. You probably want to do that anyway.

I wrote this quick little function to help solve this problem.
function isNumber(val) {
return (val != undefined && val != null && val.toString().length > 0 && val.toString().match(/[^0-9\.\-]/g) == null);
};
It simply checks for any characters that aren't numeric (0-9), that aren't '-' or '.', and that aren't undefined, null or empty and returns true if there's no matches. :)

As other explained the isNaN function will coerce the empty string into a number before validating it, thus changing an empty string into 0 (which is a valid number).
However, I found that the parseInt function will return NaN when trying to parse an empty string or a string with only spaces. As such the following combination seems to be working well:
if ( isNaN(string) || isNaN(parseInt(string)) ) console.log('Not a number!');
This check will work for positive numbers, negative numbers and numbers with a decimal point, so I believe it covers all common numerical cases.

This function seemed to work in my tests
function isNumber(s) {
if (s === "" || s === null) {
return false;
} else {
var number = parseInt(s);
if (number == 'NaN') {
return false;
} else {
return true;
}
}
}

What about
function isNumberRegex(value) {
var pattern = /^[-+]?\d*\.?\d*$/i;
var match = value.match(pattern);
return value.length > 0 && match != null;
}

The JavaScript built-in isNaN function, is - as should be expected by default - a "Dynamic Type Operator".
Therefore all values which (during the DTC process) may yield a simple true | false such as "", " ", " 000", cannot be NaN.
Meaning that the argument supplied will first undergo a conversion as in:
function isNaNDemo(arg){
var x = new Number(arg).valueOf();
return x != x;
}
Explanation:
In the top line of the function body, we are (first) trying to successfully convert the argument into a number object. And (second), using the dot operator we are - for our own convenience - immediately stripping off, the primitive value of the created object.
In the second line, we are taking the value obtained in the previous step, and the advantage of the fact that NaN is not equal to anything in the universe, not even to itself, e.g.: NaN == NaN >> false to finally compare it (for inequality) with itself.
This way the function return will yield true only when, and only if, the supplied argument-return, is a failed attempt of conversion to a number object, i.e., a not-a-number number; e.g., NaN.
isNaNstatic( )
However, for a Static Type Operator - if needed and when needed - we can write a far simpler function such as:
function isNaNstatic(x){
return x != x;
}
And avoid the DTC altogether so that if the argument is not explicitly a NaN number, it will return false. Wherefore, testing against the following:
isNaNStatic(" x"); // will return false because it's still a string.
However:
isNaNStatic(1/"x"); // will of course return true. as will for instance isNaNStatic(NaN); >> true.
But contrary to isNaN, the isNaNStatic("NaN"); >> false because it (the argument) is an ordinary string.
p.s.:
The static version of isNaN can be very useful in modern coding scenarios. And it may very well be one of the main reasons I took my time for posting this.
Regards.

isNAN(<argument>) is a function to tell whether given argument is illegal number.
isNaN typecasts the arguments into Number type. If you want to check if argument is Numeric or not? Please use $.isNumeric() function in jQuery.
That is, isNaN(foo) is equivalent to isNaN(Number(foo))
It accepts any strings having all numerals as numbers for obvious reasons. For ex.
isNaN(123) //false
isNaN(-1.23) //false
isNaN(5-2) //false
isNaN(0) //false
isNaN('123') //false
isNaN('Hello') //true
isNaN('2005/12/12') //true
isNaN('') //false
isNaN(true) //false
isNaN(undefined) //true
isNaN('NaN') //true
isNaN(NaN) //true
isNaN(0 / 0) //true

I use this
function isNotANumeric(val) {
if(val.trim && val.trim() == "") {
return true;
} else {
return isNaN(parseFloat(val * 1));
}
}
alert(isNotANumeric("100")); // false
alert(isNotANumeric("1a")); // true
alert(isNotANumeric("")); // true
alert(isNotANumeric(" ")); // true

When checking if certain string value with whitespace or " "is isNaN maybe try to perform string validation, example :
// value = "123 "
if (value.match(/\s/) || isNaN(value)) {
// do something
}

I find it convenient to have a method specific to the Number class (since other functions that do conversions like parseInt have different outputs for some of these values) and use prototypal inheritance.
Object.assign(Number.prototype, {
isNumericallyValid(num) {
if (
num === null
|| typeof num === 'boolean'
|| num === ''
|| Number.isNaN(Number(num))
) {
return false;
}
return true;
}
});

I use the following.
x=(isNaN(parseFloat(x)))? 0.00 : parseFloat(x);

let isNotNumber = val => isNaN(val) || (val.trim && val.trim() === '');
console.log(isNotNumber(' '));
console.log(isNotNumber('1'));
console.log(isNotNumber('123x'));
console.log(isNotNumber('x123'));
console.log(isNotNumber('0'));
console.log(isNotNumber(3));
console.log(isNotNumber(' x'));
console.log(isNotNumber('1.23'));
console.log(isNotNumber('1.23.1.3'));
if(!isNotNumber(3)){
console.log('This is a number');
}

Implied string comparison, 0=='', but 1=='1'

I was debugging something and discovered some strangeness in JavaScript:
alert(1=='') ==> false
alert(0=='') ==> true
alert(-1=='') ==> false
It would make sense that an implied string comparison that 0 should = '0'. This is true for all non-zero values, but why not for zero?

According to the Mozilla documentation on Javascript Comparison Operators
If the two operands are not of the same type, JavaScript converts the
operands then applies strict
comparison. If either operand is a
number or a boolean, the operands are
converted to numbers; if either
operand is a string, the other one is
converted to a string
What's actually happening is that the strings are being converted to numbers.
For example:
1 == '1' becomes 1 == Number('1') becomes 1 == 1: true
Then try this one:
1 == '1.' becomes 1 == Number('1.') becomes 1 == 1: true
If they were becoming strings, then you'd get '1' == '1.', which would be false.
It just so happens that Number('') == 0, therefore 0 == '' is true

When javascript does implicit type conversions, the empty string literal will match the 0 integer. Do your comparison like this and you'll get your expected result:
alert(1==='') ==> false
alert(0==='') ==> false
alert(-1==='') ==> false

ECMA-262, 3rd edition, 11.9.3 regarding x == y, step 16:
If Type(x) is Number and Type(y) is String, return the result of the comparison x == ToNumber(y).
The empty string '' gets converted to 0 before the comparison.

This is just one of the truly hideous mangles that went into the JavaScript compromise. '' and 0 are both uninitialized values (equal to boolean false) and, therefore, equal.
To protect yourself from weird bugs like this, it's better to always use the === operator.

Javascript, like PHP, is weakly typed*. So when you compare 0 to '', the JS engine converts them to a similar datatype. Since 0 and '' both equate to boolean(false), "false == false" is true.
*Weakly typed languages do not require variables to be any specific data type, so you can set one variable as a string, change it to int, float, and back to string without the processor throwing errors.

In many languages, the empty string can be coerced to false.
Beware of doing comparisons with == instead of ===:
alert('' == '0'); //false
alert(0 == ''); // true
alert(0 =='0'); // true
== is not transitive.