I ran JSLint on this JavaScript code and it said:
Problem at line 32 character 30: Missing radix parameter.
This is the code in question:
imageIndex = parseInt(id.substring(id.length - 1))-1;
What is wrong here?
It always a good practice to pass radix with parseInt -
parseInt(string, radix)
For decimal -
parseInt(id.substring(id.length - 1), 10)
If the radix parameter is omitted, JavaScript assumes the following:
If the string begins with "0x", the radix is 16 (hexadecimal)
If the string begins with "0", the radix is 8 (octal). This feature is deprecated
If the string begins with any other value, the radix is 10 (decimal)
(Reference)
To avoid this warning, instead of using:
parseInt("999", 10);
You may replace it by:
Number("999");
Note that parseInt and Number have different behaviors, but in some cases, one can replace the other.
I'm not properly answering the question but, I think it makes sense to clear why we should specify the radix.
On MDN documentation we can read that:
If radix is undefined or 0 (or absent), JavaScript assumes the
following:
[...]
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.
[...]
Source: MDN parseInt()
You can turn off this rule if you wish to skip that test.
Insert:
radix: false
Under the "rules" property in the tslint.json file.
It's not recommended to do that if you don't understand this exception.
Adding the following on top of your JS file will tell JSHint to supress the radix warning:
/*jshint -W065 */
See also: http://jshint.com/docs/#options
Prior to ECMAScript 5, parseInt() also autodetected octal literals, which caused problems because many developers assumed a leading 0 would be ignored.
So Instead of :
var num = parseInt("071"); // 57
Do this:
var num = parseInt("071", 10); // 71
var num = parseInt("071", 8);
var num = parseFloat(someValue);
Reference
Simply add your custom rule in .eslintrc which looks like that
"radix": "off"
and you will be free of this eslint unnesesery warning.
This is for the eslint linter.
I solved it with just using the +foo, to convert the string.
Keep in mind it's not great for readability (dirty fix).
console.log( +'1' )
// 1 (int)
You can also simply add this line right above your parseInt line:
// eslint-disable-next-line
This will disable eslint check for the next line. Use this if you only need to skip one or two lines.
Just put an empty string in the radix place, because parseInt() take two arguments:
parseInt(string, radix);
string
The value to parse. If the string argument is not a string, then it is converted to a string (using the ToString abstract operation). Leading whitespace in the string argument is ignored.
radix
An integer between 2 and 36 that represents the radix (the base in mathematical numeral systems) of the above-mentioned string. Specify 10 for the decimal numeral system commonly used by humans. Always specify this parameter to eliminate reader confusion and to guarantee predictable behavior. Different implementations produce different results when a radix is not specified, usually defaulting the value to 10.
imageIndex = parseInt(id.substring(id.length - 1))-1;
imageIndex = parseInt(id.substring(id.length - 1), '')-1;
Instead of calling the substring function you could use .slice()
imageIndex = parseInt(id.slice(-1)) - 1;
Here, -1 in slice indicates that to start slice from the last index.
Thanks.
Related
I've always used the parseInt() function in Javascript without passing the radix parameter. As per the MDN documentation here, it's stated that not providing this parameter may result in unpredictable behaviour.
Always specify this parameter to eliminate reader confusion and to
guarantee predictable behavior.
Could somebody clarify what does this unpredictable behavior mean with some code examples?
In older versions of the language, parseInt() would cause the function to obey the normal JavaScript numeric constant syntax rules, including the recognition of a leading zero to denote octal constants, and a leading 0x to denote hex constants. Thus, if your code didn't explicitly insist on base 10, stray (possibly user-supplied) numbers with leading zeros would be interpreted as base-8 values, and leading 0x as hex.
The base-8 behavior is gone since ES5.1 (I think; might have been earlier), but the base 16 behavior is still there. (Probably a leading 0x is a little more rare as an accidental prefix than a simple leading 0.)
My experience looking at code here on Stack Overflow is that parseInt() is overused anyway. It's usually cleaner to convert strings (often, strings taken from DOM element .value properties) to numbers with the unary + operator:
var count = +document.getElementById("count").value;
That won't necessarily give you an integer, of course. However, what it will do is notice that the input string has trailing non-numeric garbage. The parseInt() function will simply stop parsing a string like "123abc" and give you 123 as the numeric value. The leading + will however give you a NaN.
If you need integers, you can always use Math.floor() or Math.round().
edit — a comment notes that ES2015 requires a leading 0o or 0O in "strict" mode for octal literals, but that doesn't apply to parseInt() which (in ES2015) only overrides the default radix for hex strings.
For some reason best known to themselves, the folk specifying the behaviour of this function set the radix to be a defaultable parameter but then decided to leave the default value up to the implementation! (Perhaps it would have been sensible to insist on a value of 10 but maybe that would have upset folk progamming in the 1970s who still consider octal literals to be useful.)
So for robust progamming, you need to supply the radix parameter yourself.
Without supplying the radix, parseInt tries to determine what the right radix is by the value you pass in, for example if the value starts 0x then it determines you must be passing in hex values. Same applies with 0 (octal).
This becomes problematic when your input is zero-padded but no radix is supplied. Where the result will (possibly) not be as expected
console.log(parseInt(015))
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));
parseInt(123123123123123123123123); //return 1
parseInt(123123123123123123123123123); //return 1
parseInt(123123123123123123123123123123);//return 1
Test in chrome!
A little creative reading of the documentation for parseInt() provides an answer for this. Here's what's happening:
parseInt expects its first argument to be a string. If it isn't, it converts it to a string. This is actually hilarious, because it appears to do that by...wrapping it in quotes and passing it through .toString(), which is more or less the converse of parseInt() in this case. In your example, parseInt(123123123123123123123123); becomes parseInt("1.2312312312312312e+29").
THEN it takes the converted-to-string value and passes it through parseInt(). As the documentation tells us, if it encounters a non-numeric character, it aborts and goes with what it has so far...and it truncates to an integer. So it's taking "1.2312312312312312e+29", reaching the +, aborting, parsing "1.2312312312312312" instead, and coming up with 1.
Unintended consequences!
You'll only see this problem with ints large enough that when converted to strings, they render in exponential notation. The underlying problem is that even though you'd think parseInt() and Number.toString() would mirror each other...they don't, quite, because int values passed through toString() can generate strings that parseInt() doesn't understand.
First, always specify the radix (second parameter) to avoid guessing.
Second, parseInt expects a string, so add quotes around your number.
parseInt("123123123123123123123123123123", 10)
1.2312312312312312e+29
Mozilla developer reference has good documentation of this function and examples. Regarding the radix, they say:
Always specify this parameter to eliminate reader confusion and to guarantee predictable behavior. Different implementations produce different results when a radix is not specified.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why parseInt() works like this?
I have an issue with parseInt() returning 0 unexpectedly, here's a sample:
parseInt('-06') = -6
parseInt('-07') = -7
parseInt('-08') = 0
Why is the result 0? Same if I keep going down (-09, -10, ect). The format of the string comes from my framework so I need to deal with it. Thanks!
You need to pass a radix parameter when you use parseInt
parseInt('-08', 10);
When you don't, and when the string you're parsing has a leading zero, parseInt produces different results depending on your browser. The most common issue is that the string will be treated as a base-8 number, which is what you're seeing.
That's why this worked for '-06' and '-07'—those are both valid base-8 numbers. Since '-08' isn't a valid base-8 number, the parse failed, and 0 was returned.
From MDN
radix
An integer that represents the radix of the above mentioned
string. While this parameter is optional, always specify it to
eliminate reader confusion and to guarantee predictable behavior.
Different implementations produce different results when a radix is
not specified.
Also note that you can use the unary + operator to convert these strings to numbers:
var str = '-08';
var num = +str;
console.log(num);
//logs -8
DEMO
You could also try this:
'-06' * 1 = -6
'-07' * 1 = -7
'-08' * 1 = -8
this is a bug in firefox, use parseFloat instead .get more detaile about this bug here.
check parseFloat result HERE.
I'm passing as parameter an id to a javascript function, because it comes from UI, it's left zero padded. but it seems to have (maybe) "strange" behaviour?
console.log(0000020948); //20948
console.log(0000022115); //9293 which is 22115's octal
console.log(parseInt(0000022115, 10)); // 9293 which is 22115's octal
console.log(0000033959); //33959
console.log(20948); //20948
console.log(22115); //22115
console.log(33959); //33959
how can I make sure they are parsing to right numebr they are? (decimal)
EDIT:
just make it clearer:
those numbers come from the server and are zero padded strings. and I'm making a delete button for each one.
like:
function printDelButton(value){
console.log(typeof value); //output string
return '<img src="images/del.png">'
}
and
function printDelButton(value){
console.log(typeof value); //output numeric
console.log(value); //here output as octal .... :S
}
I tried :
console.log(parseInt(0000022115, 10)); // 9293 which is 22115's octal
and still parsing as Octal
If you receive your parameters as string objects, it should work to use
parseInt(string, 10)
to interpret strings as decimal, even if they are beginning with 0.
In your test, you pass the parseInt method a number, not a string, maybe that's why it doesn't return the expected result.
Try
parseInt('0000022115', 10)
instead of
parseInt(0000022115, 10)
that does return 221115 for me.
If you start it with a 0, it's interpreted as an Octal number.
See http://www.hunlock.com/blogs/The_Complete_Javascript_Number_Reference#quickIDX2
Note the article's warning here:
You should never precede a number with a zero unless you are
specifically looking for an octal conversion!
Consider looking here for ideas on removing the leadings 0s:
Truncate leading zeros of a string in Javascript
Leading 0s indicate that the number is octal.
parseInt parses a string containing a number.
parseInt(0000022115, 10) passes a numeric literal. The literal is parsed in octal by the JS interpreter, so you're passing a raw numeric value to parseInt.
Unless you can intercept a string version of this number, you're out of luck.
That being said, if you can get a string version of your octal (calling toString() won't help), this will work:
parseInt(variable_string.replace(/^0+/, ''), 10);
Try
/^[0]*([1-9]\d)/.exec(numberFromUI)[0]
That should give you just the numbers stripping the zeros (if you have to support decimals, you'll need to edit to account for the '.', and of course ',' is fun too... and I really hope you don't have to handle all the crazy different ways Europeans write numbers! )
If number came from server as zero padded string then use +"0000022115"
console.log(+"0000022115")
if (021 < 019) console.log('Paradox');
JS treat zero padded numbers like octal only if they are valid octal - if not then it treat it as decimal. To not allow paradox 'use strict' mode
'use strict'
if (021 < 019) console.log('Paradox');