This question already has answers here:
JSLint says "missing radix parameter"
(11 answers)
Closed 9 years ago.
I have the following code that gives the warning described in the title:
year: parseInt(dateParts[0]),
......................^
Any help is much appreciated
See the manual for parseInt; it takes 2 arguments. The second one tells it which number base you want to use. This is almost always going to be 10 (decimal).
parseInt(dateParts[0],10)
If you don't specify it, then it will be inferred from the data.
If radix is undefined or 0 (or absent), JavaScript assumes the following:
If the input string begins with "0x" or "0X", radix is 16
(hexadecimal) and the remainder of the string is parsed.
If the input string begins with "0", radix is eight (octal) or 10
(decimal). Exactly which radix is chosen is implementation-dependent.
ECMAScript 5 specifies that 10 (decimal) is used, but not all browsers
support this yet. For this reason always specify a radix when using
parseInt.
If the input string begins with any other value, the radix is 10
(decimal).
Some years after I wrote the above, things have changed. Now:
The ECMAScript 5 specification of the function parseInt no longer allows implementations to treat Strings beginning with a 0 character as octal values. Many implementations have adopted this behavior as of 2021.
… but you still should use a radix, at least for browser side code, because not all implementations have caught up.
Related
This question already has answers here:
Why does floating-point arithmetic not give exact results when adding decimal fractions?
(31 answers)
Closed 10 years ago.
Here i have a problem in my web application(tested on chrome and firefox and nodejs):
when i run (1.2 - 1) it returns 0.19999999999999996 as result.
does anyone know why?
you can solve your problem:
(1.2 - 1).toFixed(1) * 1 // 0.2
you can use toFixed method of javascript more detail:
Method of Number
Implemented in JavaScript 1.5
ECMAScript Edition ECMAScript 3rd Edition
Syntax
number.toFixed( [digits] )
Parameter
digits
The number of digits to appear after the decimal point; this may be a value between 0 and 20, inclusive, and implementations may optionally support a larger range of values. If this argument is omitted, it is treated as 0.
Returns
A string representation of number that does not use exponential notation and has exactly digits digits after the decimal place. The number is rounded if necessary, and the fractional part is padded with zeros if necessary so that it has the specified length. If number is greater than 1e+21, this method simply calls Number.toString() and returns a string in exponential notation.
Throws
RangeError
If digits is too small or too large. Values between 0 and 20, inclusive, will not cause a RangeError. Implementations are allowed to support larger and smaller values as well. TypeError
If this method is invoked on an object that is not a Number.
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Number/toFixed
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Workarounds for JavaScript parseInt octal bug
I would think it has something to do with octal parsing, since it only happens on 8 or 9. There was also the thought that this was a Chrome bug, but it replicates in Firefox as well.
Is this intentional behavior? If so, why?
The solution here is simple. NEVER call parseInt() without specifying the desired radix. When you don't pass that second parameter, parseInt() tries to guess what the radix is based on the format of the number. When it guesses, it often gets it wrong.
Specify the radix like this and you will get the desired result:
parseInt("08", 10) == 8;
As to what rules it uses for guessing, you can refer to the MDN doc page for parseInt().
If radix is undefined or 0, JavaScript assumes the following:
If the input string begins with "0x" or "0X", radix is 16
(hexadecimal).
If the input string begins with "0", radix is eight
(octal). This feature is non-standard, and some implementations
deliberately do not support it (instead using the radix 10). For this
reason always specify a radix when using parseInt.
If the input string
begins with any other value, the radix is 10 (decimal). If the first
character cannot be converted to a number, parseInt returns NaN.
So, according to these rules, parseInt() will guess that "08" is octal, but then it encounters a digit that isn't allowed in octal so it returns 0.
When you pass a number to parseInt(), it has nothing to do because the value is already a number so it doesn't try to change it.
"Is this intentional behavior?"
Yes.
"If so, why?"
A leading 0 is the notation used for denoting an octal number as defined in the specification. The symbols 8 and 9 don't exist in octal numbering, so parseInt uses the first valid number it finds, which is 0.
If you do...
parseInt('123#xq$_.f(--_!2*')
...the result will be...
123
...because a valid number was found at the beginning of the string. Anything invalid beyond that is discarded.
You can fix this like that :
parseInt("080".replace(/^[0]+/g,""));
This question already has answers here:
Javascript parseInt() with leading zeros
(7 answers)
Closed 4 years ago.
Why is this behavior difference between parseInt() and parseFloat()?
I have a string that contains 08 in it.
When I write this code:
alert(hfrom[0]);
alert(parseInt(hfrom[0]));
alert(parseFloat(hfrom[0]));
The following output is generated:
08
0
8
Why does parseInt and parseFloat return two different results in this case?
parseInt() assumes the base of your number according to the first characters in the string. If it begins with 0x it assumes base 16 (hexadecimal). Otherwise, if it begins with 0 it assumes base 8 (octal). Otherwise it assumes base 10.
You can specify the base as a second argument:
alert(parseInt(hfrom[0], 10)); // 8
From MDN (linked above):
If radix is undefined or 0, JavaScript assumes the following:
If the input string begins with "0x" or "0X", radix is 16
(hexadecimal). If the input string begins with "0", radix is eight
(octal). This feature is non-standard, and some implementations
deliberately do not support it (instead using the radix 10). For this
reason always specify a radix when using parseInt. If the input string
begins with any other value, the radix is 10 (decimal).
you should always include the radix param with parseInt() ex parseInt('013', 10) otherwise it can convert it to a different numeric base:
parseInt('013') === 11
parseInt('013', 10) === 13
parseInt('0x13') === 19
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Workarounds for JavaScript parseInt octal bug
I was learning the parseInt() function of javascript and was just trying out, and out of nowhere
parseInt('08') returns 0
moreover,
parseInt('07') returns 7 //which is correct
but again
parseInt('09') returns 0 // really, are you kidding me.?
Either I am crazy or I am missing something?
Its because its doing octal when the string starts with 0.
You should pass the radix of 10 as the second parameter.
You need to specify the radix:
parseInt('08', 10); // base 10 radix
Running your javascript thru JSLint will call this out as well.
From the documentation, parseInt parses the string as octal when the string starts with a 0, if no radix is specified.
No, you're. Only parseInt obeys rules for octal numbers and applies them when the string begins with 0.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Workarounds for JavaScript parseInt octal bug
Surprisingly it returns 0. Why? and what's the (proper) solution to get correct results?
Use a radix:
var x = parseInt("08", 10);
Some JavaScript implementations add a third numeral system to the two defined by the standard (decimal, the default; and hex, prefixed with 0x): Octal, prefixed with 0. This is non-standard but acknowledged as common in the latest spec.
Since 8 is not a valid octal digit, parseInt stops there, returning the value 0.
By explicitly using a radix, you tell parseInt not to try to figure out what numeral system is being used but instead to use the one you specify. Your instinct when typing parseInt should always be to specify the radix; not doing so leaves you open to oddities.
"08" mean 8 based number. You should specify second argument.
parseInt("08", 10)
#T.J. gave a great explanation for the behaviour you see. Another way to parse a number string is to use unary +:
var num = +"08";
From http://www.bennadel.com/blog/2012-Exploring-Javascript-s-parseInt-And-parseFloat-Functions.htm:
Strings that start with "0" are assumed to be base8 (octal).
From MDC - parseInt:
If the input string begins with "0", radix is eight (octal). This feature is non-standard, and some implementations deliberately do not support it (instead using the radix 10). For this reason always specify a radix when using parseInt.
And the example:
parseInt("08"); // 0, '8' is not an octal digit.
That is, since no radix was passed in and the string begins with 0 octal is assumed. Since 8 is not an octal digit it cannot be parsed.
Solution? Always provide a radix parameter:
parseInt("08", 10);
If you run it through jslint, it'll squawk at you for not including the radix parameter. Yes, the radix is optional, but probably should be included every time. A number starting with 0 is assumed to be octal unless otherwise specified.
var foo = parseInt("08", 10);
Number prefixed with "0" is octal number. 8 is invalid octal number. so the result is 0