There are a few expressions that are commonly seen in JavaScript, but which some programming purists will tell you are never a good idea. What these expressions share is their reliance on automatic type conversion — a core feature of JavaScript which is both a strength and a weakness, depending on the circumstances and your point of view.
Type coercion and type conversion are similar except type coercion is when JavaScript automatically converts a value from one type to another (such as strings to numbers). It's also different in that it will decide how to coerce with its own set or rules. I found this example useful because it shows some interesting output behavior illustrating this coercive behavior:
const value1 = '5';
const value2 = 9;
let sum = value1 + value2;
console.log(sum);
In the above example, JavaScript has coerced the 9 from a number into a string and then concatenated the two values together, resulting in a string of 59. JavaScript had a choice between a string or a number and decided to use a string.
The compiler could have coerced the 5 into a number and returned a sum of 14, but it did not. To return this result, you'd have to explicitly convert the 5 to a number using the Number() method:
sum = Number(value1) + value2;
From an MDN glossary entry I wrote here: https://developer.mozilla.org/en-US/docs/Glossary/Type_coercion edited by chrisdavidmills
Does JavaScript support automatic type conversion?
Yes. It's usually called type coercion, but conversion is perfectly accurate.
For instance:
console.log("Example " + 42);
"automatically" converts 42 (a number) to string. I put "automatically" in quotes because it's done by the + operator, in a clearly-defined way.
Another example is that various operations expecting numbers will convert from string (or even from object). For instance:
const obj = {
valueOf() {
return 2;
}
};
const str = "10";
console.log(Math.max(obj, str)); // 10
console.log(Math.min(obj, str)); // 2
The rules JavaScript uses are clearly and completely defined in the specification. That doesn't prevent people from frequently being surprised by some of them, such as that +"" is 0.
In my code, the value of a particular var can originate from any one of a number of different json sources. For some of those sources, the json element concerned will be a string (e.g. "temp": "10.2"), while for other sources the json element will already be a float (e.g. "temp": 10.2).
Does it do any harm (is anything likely to break) if I just pass the json element (from whatever source) through a parseFloat(), even if it's already a float? It seems to work; I'm just thinking about good/bad practice and possible breakage in future or on a different platform.
Thanks.
You should be able to call parseFloat() on a float or a string without any problems. If it is a float already, it's converted to a string first, and then to a float again, so it's a little less efficient, but it shouldn't matter too much.
You should still check the result for NaN, in case there's something unexpected in the data.
The most appropriate method to convert any datatype to a number is to use the Number function:
In a non-constructor context (i.e., without the new operator),
Number can be used to perform a type conversion.
Number("1234") // 1234
Number(1234) // 1234
This method differs from parseFloat in these ways at least:
Number function does not perform "double-conversion" if the input is already a number (ref)
Parse float converts the input to a string then extracts the number (ref)
Number function returns common sense values for most datatypes e.g. Number(true) yields 1
Parse float uses the string value of input so parseFloat(true) tries to parse number from "true" and yields NaN
Number function fails when input string is an invalid number e.g. Number("123abc") yields NaN
Parse float tries to parse as much of a number as possible e.g. parseFloat("123abc") yields 123
If you are sure the value is always a valid number, you should use Number(stringOrNumber).
If you need some additional safety using parseFloat() you could also write your own function which is also performance optimized:
function toFloat(value) {
return typeof value === 'number' ? value : parseFloat(value);
}
I also created a jsPerf test case that shows the performance is >30% better than the plain parseFloat() for a 1:1 ratio between strings and numbers as input values.
Nope there is no problem with passing a number to it
MDN says as long as it can be converted to a number, nothing breaking should happen.
If the first character cannot be converted to a number, parseFloat returns NaN.
As an alternative, you could use the unary operator + which does basically the same thing as parseFloat and also returns NaN if it didn't work.
For instance:
var myFloat = +('10.5');
var myOtherFloat = parseFloat('10.5', 10);
var alreadyAFloat = parseFloat(10.5, 10);
console.log(myFloat === myOtherFloat && myOtherFloat === alreadyAFloat); // true
Wether it's a float or a String using parseFloat() is much safer to avoid all kind of errors.
As you said it will always work, but if you enforce it to be a float you will avoid getting any Exception.
For Example:
Both parseFloat('10.2', 10) and parseFloat(10.2, 10) will work
perfectly and will give you the same result which is 10.2.
Personally I can't see this being a problem what so ever, to be honest I would always use the parsefloat() for one reason, and that is safety. You can never be to sure what may happen, so always predict the worse :D
Just out of curiosity.
It doesn't seem very logical that typeof NaN is number. Just like NaN === NaN or NaN == NaN returning false, by the way. Is this one of the peculiarities of JavaScript, or would there be a reason for this?
Edit: thanks for your answers. It's not an easy thing to get ones head around though. Reading answers and the wiki I understood more, but still, a sentence like
A comparison with a NaN always returns an unordered result even when comparing with itself. The comparison predicates are either signaling or non-signaling, the signaling versions signal an invalid exception for such comparisons. The equality and inequality predicates are non-signaling so x = x returning false can be used to test if x is a quiet NaN.
just keeps my head spinning. If someone can translate this in human (as opposed to, say, mathematician) readable language, I would be grateful.
Well, it may seem a little strange that something called "not a number" is considered a number, but NaN is still a numeric type, despite that fact :-)
NaN just means the specific value cannot be represented within the limitations of the numeric type (although that could be said for all numbers that have to be rounded to fit, but NaN is a special case).
A specific NaN is not considered equal to another NaN because they may be different values. However, NaN is still a number type, just like 2718 or 31415.
As to your updated question to explain in layman's terms:
A comparison with a NaN always returns an unordered result even when comparing with itself. The comparison predicates are either signalling or non-signalling, the signalling versions signal an invalid exception for such comparisons. The equality and inequality predicates are non-signalling so x = x returning false can be used to test if x is a quiet NaN.
All this means is (broken down into parts):
A comparison with a NaN always returns an unordered result even when comparing with itself.
Basically, a NaN is not equal to any other number, including another NaN, and even including itself.
The comparison predicates are either signalling or non-signalling, the signalling versions signal an invalid exception for such comparisons.
Attempting to do comparison (less than, greater than, and so on) operations between a NaN and another number can either result in an exception being thrown (signalling) or just getting false as the result (non-signalling or quiet).
The equality and inequality predicates are non-signalling so x = x returning false can be used to test if x is a quiet NaN.
Tests for equality (equal to, not equal to) are never signalling so using them will not cause an exception. If you have a regular number x, then x == x will always be true. If x is a NaN, then x == x will always be false. It's giving you a way to detect NaN easily (quietly).
It means Not a Number. It is not a peculiarity of javascript but common computer science principle.
From http://en.wikipedia.org/wiki/NaN:
There are three kinds of operation
which return NaN:
Operations with a NaN as at least one operand
Indeterminate forms
The divisions 0/0, ∞/∞, ∞/−∞, −∞/∞, and −∞/−∞
The multiplications 0×∞ and 0×−∞
The power 1^∞
The additions ∞ + (−∞), (−∞) + ∞ and equivalent subtractions.
Real operations with complex results:
The square root of a negative number
The logarithm of a negative number
The tangent of an odd multiple of 90 degrees (or π/2 radians)
The inverse sine or cosine of a number which is less than −1 or
greater than +1.
All these values may not be the same. A simple test for a NaN is to test value == value is false.
The ECMAScript (JavaScript) standard specifies that Numbers are IEEE 754 floats, which include NaN as a possible value.
ECMA 262 5e Section 4.3.19: Number value
primitive value corresponding to a double-precision 64-bit binary format IEEE 754 value.
ECMA 262 5e Section 4.3.23: NaN
Number value that is a IEEE 754 "Not-a-Number" value.
IEEE 754 on Wikipedia
The IEEE Standard for Floating-Point Arithmetic is a technical standard established by the Institute of Electrical and Electronics Engineers and the most widely used standard for floating-point computation [...]
The standard defines
arithmetic formats: sets of binary and decimal floating-point data, which consist of finite numbers (including signed zeros and subnormal numbers), infinities, and special "not a number" values (NaNs)
[...]
typeof NaN returns 'number' because:
ECMAScript spec says the Number type includes NaN:
4.3.20 Number type
set of all possible Number values including the special “Not-a-Number”
(NaN) values, positive infinity, and negative infinity
So typeof returns accordingly:
11.4.3 The typeof Operator
The production UnaryExpression : typeof UnaryExpression is
evaluated as follows:
Let val be the result of evaluating UnaryExpression.
If Type(val) is Reference, then
If IsUnresolvableReference(val) is true, return "undefined".
Let val be GetValue(val).
Return a String determined by Type(val) according to Table 20.
Table 20 — typeof Operator Results
==================================================================
| Type of val | Result |
==================================================================
| Undefined | "undefined" |
|----------------------------------------------------------------|
| Null | "object" |
|----------------------------------------------------------------|
| Boolean | "boolean" |
|----------------------------------------------------------------|
| Number | "number" |
|----------------------------------------------------------------|
| String | "string" |
|----------------------------------------------------------------|
| Object (native and does | "object" |
| not implement [[Call]]) | |
|----------------------------------------------------------------|
| Object (native or host and | "function" |
| does implement [[Call]]) | |
|----------------------------------------------------------------|
| Object (host and does not | Implementation-defined except may |
| implement [[Call]]) | not be "undefined", "boolean", |
| | "number", or "string". |
------------------------------------------------------------------
This behavior is in accordance with IEEE Standard for Floating-Point Arithmetic (IEEE 754):
4.3.19 Number value
primitive value corresponding to a double-precision 64-bit binary
format IEEE 754 value
4.3.23 NaN
number value that is a IEEE 754 “Not-a-Number” value
8.5 The Number Type
The Number type has exactly 18437736874454810627 (that is, 253−264+3)
values, representing the double-precision 64-bit format IEEE 754
values as specified in the IEEE Standard for Binary Floating-Point
Arithmetic, except that the 9007199254740990 (that is, 253−2) distinct
“Not-a-Number” values of the IEEE Standard are represented in
ECMAScript as a single special NaN value. (Note that the NaN value
is produced by the program expression NaN.)
NaN != NaN because they are not necessary the SAME non-number. Thus it makes a lot of sense...
Also why floats have both +0.00 and -0.00 that are not the same. Rounding may do that they are actually not zero.
As for typeof, that depends on the language. And most languages will say that NaN is a float, double or number depending on how they classify it... I know of no languages that will say this is an unknown type or null.
NaN is a valid floating point value (http://en.wikipedia.org/wiki/NaN)
and NaN === NaN is false because they're not necessarily the same non-number
NaN stands for Not a Number. It is a value of numeric data types (usually floating point types, but not always) that represents the result of an invalid operation such as dividing by zero.
Although its names says that it's not a number, the data type used to hold it is a numeric type. So in JavaScript, asking for the datatype of NaN will return number (as alert(typeof(NaN)) clearly demonstrates).
A better name for NaN, describing its meaning more precisely and less confusingly, would be a numerical exception. It is really another kind of exception object disguised as having primitive type (by the language design), where at the same it is not treated as primitive in its false self-comparison. Whence the confusion. And as long as the language "will not make its mind" to choose between proper exception object and primitive numeral, the confusion will stay.
The infamous non-equality of NaN to itself, both == and === is a manifestation of the confusing design forcing this exception object into being a primitive type. This breaks the fundamental principle that a primitive is uniquely determined by its value. If NaN is preferred to be seen as exception (of which there can be different kinds), then it should not be "sold" as primitive. And if it is wanted to be primitive, that principle must hold. As long as it is broken, as we have in JavaScript, and we can't really decide between the two, the confusion leading to unnecessary cognitive load for everyone involved will remain. Which, however, is really easy to fix by simply making the choice between the two:
either make NaN a special exception object containing the useful information about how the exception arose, as opposed to throwing that information away as what is currently implemented, leading to harder-to-debug code;
or make NaN an entity of the primitive type number (that could be less confusingly called "numeric"), in which case it should be equal to itself and cannot contain any other information; the latter is clearly an inferior choice.
The only conceivable advantage of forcing NaN into number type is being able to throw it back into any numerical expression. Which, however, makes it brittle choice, because the result of any numerical expression containing NaN will either be NaN, or leading to unpredictable results such as NaN < 0 evaluating to false, i.e. returning boolean instead of keeping the exception.
And even if "things are the way they are", nothing prevents us from making that clear distinction for ourselves, to help make our code more predictable and easierly debuggable. In practice, that means identifying those exceptions and dealing with them as exceptions. Which, unfortunately, means more code but hopefully will be mitigated by tools such as TypeScript of Flowtype.
And then we have the messy quiet vs noisy aka signalling NaN distinction. Which really is about how exceptions are handled, not the exceptions themselves, and nothing different from other exceptions.
Similarly, Infinity and +Infinity are elements of numeric type arising in the extension of the real line but they are not real numbers. Mathematically, they can be represented by sequences of real numbers converging to either + or -Infinity.
Javascript uses NaN to represent anything it encounters that can't be represented any other way by its specifications. It does not mean it is not a number. It's just the easiest way to describe the encounter. NaN means that it or an object that refers to it could not be represented in any other way by javascript. For all practical purposes, it is 'unknown'. Being 'unknown' it cannot tell you what it is nor even if it is itself. It is not even the object it is assigned to. It can only tell you what it is not, and not-ness or nothingness can only be described mathematically in a programming language. Since mathematics is about numbers, javascript represents nothingness as NaN. That doesn't mean it's not a number. It means we can't read it any other way that makes sense. That's why it can't even equal itself. Because it doesn't.
This is simply because NaN is a property of the Number object in JS, It has nothing to do with it being a number.
The best way to think of NAN is that its not a known number. Thats why NAN != NAN because each NAN value represents some unique unknown number. NANs are necessary because floating point numbers have a limited range of values. In some cases rounding occurs where the lower bits are lost which leads to what appears to be nonsense like 1.0/11*11 != 1.0. Really large values which are greater are NANs with infinity being a perfect example.
Given we only have ten fingers any attempt to show values greater than 10 are impossible, which means such values must be NANs because we have lost the true value of this greater than 10 value. The same is true of floating point values, where the value exceeds the limits of what can be held in a float.
NaN is still a numeric type, but it represents value that could not represent a valid number.
Because NaN is a numeric data type.
NaN is a number from a type point of view, but is not a normal number like 1, 2 or 329131. The name "Not A Number" refers to the fact that the value represented is special and is about the IEEE format spec domain, not javascript language domain.
If using jQuery, I prefer isNumeric over checking the type:
console.log($.isNumeric(NaN)); // returns false
console.log($.type(NaN)); // returns number
http://api.jquery.com/jQuery.isNumeric/
Javascript has only one numeric data type, which is the standard 64-bit double-precision float. Everything is a double. NaN is a special value of double, but it's a double nonetheless.
All that parseInt does is to "cast" your string into a numeric data type, so the result is always "number"; only if the original string wasn't parseable, its value will be NaN.
We could argue that NaN is a special case object. In this case, NaN's object represents a number that makes no mathematical sense. There are some other special case objects in math like INFINITE and so on.
You can still do some calculations with it, but that will yield strange behaviours.
More info here: http://www.concentric.net/~ttwang/tech/javafloat.htm (java based, not javascript)
You've got to love Javascript. It has some interesting little quirks.
http://wtfjs.com/page/13
Most of those quirks can be explained if you stop to work them out logically, or if you know a bit about number theory, but nevertheless they can still catch you out if you don't know about them.
By the way, I recommend reading the rest of http://wtfjs.com/ -- there's a lot more interesting quirks than this one to be found!
The value NaN is really the Number.NaN hence when you ask if it is a number it will say yes. You did the correct thing by using the isNaN() call.
For information, NaN can also be returned by operations on Numbers that are not defined like divisions by zero or square root of a negative number.
It is special value of Number type as POSITIVE_INFINITY
Why? By design
An example
Imagine We are converting a string to a number:
Number("string"); // returns NaN
We changed the data type to number but its value is not a number!
I found these examples in another thread but I don't get it.
0 == '0' // true
0 to the left I converted to false(the only number that does that). The right is a non empty string which converts to true.
So how can
false == true --> true
What have I missed?
Here is an official answer to your question (the quoted parts, link at the bottom) and analysis:
Equality (==)
The equality operator converts the operands if they are not of the same type, 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 string operand is converted to a number if possible. If both operands are objects, then JavaScript compares internal references which are equal when operands refer to the same object in memory.
Syntax
x == y
Examples
3 == 3 // true
"3" == 3 // true
3 == '3' // true
This means, as I read it, that the first 3 (integer) is converted to string to satisfy the comparison, so it becomes '3' == '3', which is true, same as in your case with zeroes.
NOTE: I assume that the converion may vary in different JS engines, although they have to be unified under ECMAScript specifiction - http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3 (quoted #Derek朕會功夫). This assumption is made on a subjective and imperative opinion that not all browsers and JavaScript engines out there are ECMAScript compliant.
Identity / strict equality (===)
The identity operator returns true if the operands are strictly equal (see above) with no type conversion.
The Identity / strict equality (===) found on the same resource at the end of the answer will skip the automatic type conversion (as written above) and will perform type checking as well, to ensure that we have exact match, i.e. the expression above will fail on something like:
typeof(int) == typeof(string)
This is common operator in most languages with weak typing:
http://en.wikipedia.org/wiki/Strong_and_weak_typing
I would say that one should be certain what a function/method will return, if such function/method is about to return numbers (integers/floating point numbers) it should stick to that to the very end, otherwise opposite practices may cut your head off by many reasons and one lays in this question as well.
The above is valid for other languages with weak typing, too, like PHP for example.
Read more of this, refer second head (Equality operators):
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comparison_Operators
When you use == JavaScript will try very hard to convert the two things you are trying to compare to the same type. In this case 0 is converted to '0' to do the comparison, which then results in true.
You can use ===, which will not do any type coercion and is best practice, to get the desired result.
Equality operator
The equality operator converts the operands if they are not of the same type, 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 string operand is converted to a number if possible. If both operands are objects, then JavaScript compares internal references which are equal when operands refer to the same object in memory.
Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comparison_Operators
JavaScirpt Table Equality: http://dorey.github.io/JavaScript-Equality-Table/
Which rule do I have to follow when extracting numbers out of DOM and calcluation with them? How does javascript knows that a value is a number or not? Should I always use parseInt?
Given following Code:
HTML
<div id="myvalue">5</div>
<div id="withParseInt"></div>
<div id="withoutParseInt"></div>
<div id="withoutParseIntButIncrement"></div>
JS & jQuery:
var value = $('#myvalue').text();
$('#withParseInt').text(parseInt(value) + 1);
$('#withoutParseInt').text(value + 1);
$('#withoutParseIntButIncrement').text(value++);
Gives following output:
5
6
51
5
Fiddle: http://jsfiddle.net/ytxKU/3/
The .text() method will always return a string. Some operators, like the + operator, are overloaded to perform both arithmetic and string operations. In the case of strings, it performs concatenation, hence the "51" result.
If you have a string and need to use a non-coercing operator, you will have to use parseInt (or some other method of converting to a number).
However, the * operator for example implicity performs this coercion, so you wouldn't need the parseInt call in that situation (see an updated fiddle for example).
Note that the increment ++ operator does coerce its operand, but you've used the postfix operator so it won't have any effect. Use the prefix operator and you can see it working:
$('#withoutParseIntButIncrement').text(++value);
So, to summarise:
// Parses string to number and adds 1
$('#withParseInt').text(parseInt(value) + 1);
// Coerces number 1 to string "1" and concatenates
$('#withoutParseInt').text(value + 1);
// Implicity coerces string to number, but after it's been inserted into the DOM
$('#withoutParseIntButIncrement').text(value++);
// Implicity coerces string to number, before it's been inserted into the DOM
$('#withoutParseIntButIncrement').text(++value);
// Implicity coerces to number
$('#withoutParseIntButMultiply').text(value * 2);
Side note: it's considered good practice to always pass the second argument (the radix) to parseInt. This ensures the number is parsed in the correct base:
parseInt(value, 10); // For base 10
One and only rule:
Every value that you retrieve from the DOM is a string.
Yes, you should always use parseInt() or Number() to be on the safe side. Otherwise Javascript will decide what to do with it
The value itself is a string
Using operator + will concatenate two strings
Using operator - will calculate the numerical difference
...
It's always good to use parseInt just to be on the safe side, especially as you can supply a second parameter for the numerical system to use.
By the way, in your final example it should be ++value if you want it to equal 6.