In JavaScript on Chrome and Firefox:
isNaN( "\n" ) gives false
parseFloat ( "\n" ) gives NaN
The same is yielded for \t, \r and \f.'
\n is a number
Parsed \n gives you Not A Number.
Escaped characters such as the NULL byte \0, \\ and \" do work as expected.
We know that NaN is a number, just not representable by any other value
So \n is a number, that's not representable.
Why do browsers implement it this way?
Because the toNumber conversion of any string that is comprised only of white space (or if it's empty) results in 0.
console.log(Number("\n")); // 0
The parseInt/Float methods actually require some numeric content to be converted, though it'll allow leading spaces, and trailing garbage.
console.log(parseFloat(" 123.45odsifjj")); // 123.45
The toNumber conversion is defined in 9.3.1 ToNumber Applied to the String Type.
A StringNumericLiteral that is empty or contains only white space is converted to +0
This is due to the dynamic typing when you call isNaN. "\n" is not a NaN (a value specified for floats and doubles), "\n" is a string.
EDIT:
Apparently, when calling isNaN("\n"), "\n" is converted to a number first using ToNumber which does not have exact same behavior as parseFloat.
However, W3C w3schools says for parseFloat:
If the first character cannot be converted to a number, parseFloat() returns NaN.
This is what causes the asymmetry.
Related
parseFloat('10$5') evaluates to 10.
Why does javascript consider this valid?
parseFloat parses its argument, a string, and returns a floating point
number. If it encounters a character other than a sign (+ or -),
numeral (0-9), a decimal point, or an exponent, it returns the value
up to that point and ignores that character and all succeeding
characters. Leading and trailing spaces are allowed.
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/parseFloat
Because it stops evaluating as soon as it can no longer parse a number. If you did parseFloat('$105') it would evaluate to NaN.
I have already tried the following:
discval = 2.833423
discval = discval.toFixed(2).toString().replace("." , ",");
discval = parseFloat(discval);
The output is 2 and not 2,83
Any idea?
parseFloat("2,83") will return 2 because , is not recognized as decimal separator, while . is.
If you want to round the number to 2 decimal places just use parseFloat(discval.toFixed(2)) or Math.round(discval * 100) / 100;
If you need this jut for display purposes, then leave it as a string with a comma. You can also use Number.toLocaleString() to format numbers for display purposes. But you won't be able to use it in further calculations.
BTW .toFixed() returns a string, so no need to use .toString() after that.
From https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/parseFloat
parseFloat parses its argument, a string, and returns a floating point
number. If it encounters a character other than a sign (+ or -),
numeral (0-9), a decimal point, or an exponent, it returns the value
up to that point and ignores that character and all succeeding
characters. Leading and trailing spaces are allowed.
If the first character cannot be converted to a number, parseFloat
returns NaN.
, is not an expected character so the number is truncated to that.
It's not possible to change the representation of floating point numbers in Javascript, you will need to treat your number as a string if you want to separate decimals with a comma instead of dot.
Example 1 of the knockout extenders page describes a way of rounding user input and making sure it is only numeric.
It works great, but looking through the source they do a peculiar thing that i don't understand, that is on line 8 they do this:
parseFloat(+newValue)
newValue is a string.
When i initially asked this question I didn't know what + did - some further poking and a link to a different MDN page from one of the initial answers I got indicate it is a unary operator equivalent to number(str) and that there are some differences between +str and parseFloat(str) (treatment of strings ending in alpha characters and interpretation of hex seem to be the headlines).
I still don't understand why the + in this case needed to be wrapped in the parseFloat although I am starting to think it might be a typo...
Citing MDN docs for parseFloat:
parseFloat parses its argument, a string, and returns a floating point number. If it encounters a character other than a sign (+ or -), numeral (0-9), a decimal point, or an exponent, it returns the value up to that point and ignores that character and all succeeding characters. Leading and trailing spaces are allowed.
Using [unary plus operator][2] you may be sure that `parseFloat` operates on `Number`, which is only useful if you want to be more strict about results but still want to use a `parseFloat`
parseFloat('0.32abcd') // -> 0.32
parseFloat(+'0.32abcd') // -> NaN
**Update:**
After a bit of digging in docs and running some tests, seems there is no reason to use parseFloat other than parsing strings that may contain numbers with non numeric trails to number, eq:
parseFloat('31.5 miles') // -> 31.5
parseFloat('12.75em') // -> 12.75
For any other cases where your string contains number + is a fastest and prefered way (citing MDN docs for unary plus operator):
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.
See parseFloat versus unary test case for how faster it is.
Previous link broken so here is the new test that shows how unary is faster.
I have just observed that the parseInt function doesn't take care about the decimals in case of integers (numbers containing the e character).
Let's take an example: -3.67394039744206e-15
> parseInt(-3.67394039744206e-15)
-3
> -3.67394039744206e-15.toFixed(19)
-3.6739e-15
> -3.67394039744206e-15.toFixed(2)
-0
> Math.round(-3.67394039744206e-15)
0
I expected that the parseInt will also return 0. What's going on at lower level? Why does parseInt return 3 in this case (some snippets from the source code would be appreciated)?
In this example I'm using node v0.12.1, but I expect same to happen in browser and other JavaScript engines.
I think the reason is parseInt converts the passed value to string by calling ToString which will return "-3.67394039744206e-15", then parses it so it will consider -3 and will return it.
The mdn documentation
The parseInt function converts its first argument to a string, parses
it, and returns an integer or NaN
parseInt(-3.67394039744206e-15) === -3
The parseInt function expects a string as the first argument. JavaScript will call toString method behind the scene if the argument is not a string. So the expression is evaluated as follows:
(-3.67394039744206e-15).toString()
// "-3.67394039744206e-15"
parseInt("-3.67394039744206e-15")
// -3
-3.67394039744206e-15.toFixed(19) === -3.6739e-15
This expression is parsed as:
Unary - operator
The number literal 3.67394039744206e-15
.toFixed() -- property accessor, property name and function invocation
The way number literals are parsed is described here. Interestingly, +/- are not part of the number literal. So we have:
// property accessor has higher precedence than unary - operator
3.67394039744206e-15.toFixed(19)
// "0.0000000000000036739"
-"0.0000000000000036739"
// -3.6739e-15
Likewise for -3.67394039744206e-15.toFixed(2):
3.67394039744206e-15.toFixed(2)
// "0.00"
-"0.00"
// -0
If the parsed string (stripped of +/- sign) contains any character that is not a radix digit (10 in your case), then a substring is created containing all the other characters before such character discarding those unrecognized characters.
In the case of -3.67394039744206e-15, the conversion starts and the radix is determined as base 10 -> The conversion happens till it encounters '.' which is not a valid character in base 10 - Thus, effectively, the conversion happens for 3 which gives the value 3 and then the sign is applied, thus -3.
For implementation logic - http://www.ecma-international.org/ecma-262/5.1/#sec-15.1.2.2
More Examples -
alert(parseInt("2711e2", 16));
alert(parseInt("2711e2", 10));
TO note:
The radix starts out at base 10.
If the first character is a '0', it switches to base 8.
If the next character is an 'x', it switches to base 16.
It tries to parse strings to integers. My suspicion is that your floats are first getting casted to strings. Then rather than parsing the whole value then rounding, it uses a character by character parsing function and will stop when it gets to the first decimal point ignoring any decimal places or exponents.
Some examples here http://www.w3schools.com/jsref/jsref_parseint.asp
parseInt has the purpose of parsing a string and not a number:
The parseInt() function parses a string argument and returns an
integer of the specified radix (the base in mathematical numeral
systems).
And parseInt calls the function ToString wherein all the non numerical characters are ignored.
You can use Math.round, which also parses strings, and rounds a number to the nearest integer:
Math.round("12.2e-2") === 0 //true
Math.round("12.2e-2") may round up or down based on the value. Hence may cause issues.
new Number("3.2343e-10").toFixed(0) may solve the issue.
Looks like you try to calculate using parseFloat, this will give you the correct answer.
parseInt as it says, returns an integer, whereas parseFloat returns a floating-point number or exponential number:
parseInt(-3.67394039744206e-15) = -3
parseFloat(-3.67394039744206e-15) = -3.67394039744206e-15
console.log('parseInt(-3.67394039744206e-15) = ' , parseInt(-3.67394039744206e-15));
console.log('parseFloat(-3.67394039744206e-15) = ',parseFloat(-3.67394039744206e-15));
I'm having a problem when executing parseFloat() - I don't understand why it produces the following outputs:
document.write(parseFloat("6e2") + "<br />"); //output is 600 why?
document.write(parseFloat("6b2") + "<br />"); //output is 6 why?
document.write(parseFloat("6c2") + "<br />"); //output is 6 why?
Could you tell me how the script is working?
6e2 produces 600 because it's treating your input as scientific notation.
6e2 == 6 x 102 == 600
The other two produce 6 because parseFloat parses the 6, then gets to input it isn't able to convert to a number, so it stops, and returns the result found so far.
Per MDN:
parseFloat is a top-level function and is not associated with any
object.
parseFloat parses its argument, a string, and returns a floating point
number. If it encounters a character other than a sign (+ or -),
numeral (0-9), a decimal point, or an exponent, it returns the value
up to that point and ignores that character and all succeeding
characters. Leading and trailing spaces are allowed.
If the first character cannot be converted to a number, parseFloat
returns NaN.
For arithmetic purposes, the NaN value is not a number in any radix.
You can call the isNaN function to determine if the result of
parseFloat is NaN. If NaN is passed on to arithmetic operations, the
operation results will also be NaN.
parseFloat() function determines if the first character in the specified string is a number. If it is number then it parses the string until it reaches the end of the number, and it returns the number as a number, not as a string.
so parseFloat("6b2") returns 6.
so parseFloat("6c2") returns 6.
For the first one, it is because it treats e as an exponent symbol (^)
The other two are only 6 because it ignores the rest once the numbers have ended